Is there a reason for computing wholeRange prior to the errorcheck?

Since we're doing a recovery for the error it doesn't really matter which order is used. I can change it if you really want it but I find it just a matter of style.

If the work is not necessary for evaluating the error, then it probably makes sense to move it. :-)

I notice the last set of changes, also had this pattern. So, I guess there is precedent in the codebase :-)

Yea, there is already precedent, so it's fair to keep it as is.

If the work is not necessary for evaluating the error, then it probably makes sense to move it. :-)

We are also including the opt_attributes range as well. When there is an error on the val field, will the error range extend itself to include the attributes? If so, I don't know if that would be desirable because attributes can be on the previous line; would mean the error squiggle would show on whitespace.

Seems that it will:

// TypeChecker.fs
let TcAndPublishMemberSpec cenv env containerInfo declKind tpenv memb = 
    match memb with 
    | SynMemberSig.ValField(_, m) -> error(Error(FSComp.SR.tcFieldValIllegalHere(), m))
....

But only in this instance and doesn't seem like a common thing.

Yes, including attributes to the declaration range is one of the motivating reasons for these changes.

@TIHan this is how it looks in the previous PR for members:

compared to the current highlighting:

The error of course is that member val definitions aren't allowed in classes without constructors, so underlining the whole member definition is probably quite appropriate.

We could improve the rendering of the squiggle to not display on leading whitespace.

Same as before, looks like we are going to include attributes range as well since wholeRange is being passed from the rules above.
I would check to make sure an actual error range doesn't look bad when the field has attributes on the previous line.

The errors usually look OK since in many cases they're not covering the whole range, taking a relevant part like an id instead.