The 'not' in 'not struct' and 'enum' are considered in tooltip as a function, and unmanaged, not, enum are not colored

[abelbraaksma]

Basically, just this (true for enum and not struct constraints):

(found it while playing with @cartermp's impossibility challenge)

Also, unmanaged, equality, comparison and enum constraints do not get colored correctly:

[cartermp]

This is ultimately in a weird place between a bug and a feature request.

For semantic classification (editor colors), the data being operated on doesn't have the concept of constraint information. The reason why struct is colored in the editor is because it's actually syntax classification doing the work, coloring known reserved keywords. The others aren't reserved keywords, e.g. let unamanged x = x is a valid F# function. To color things appropriate in the editor here, the data that comes from name resolution would have to be adjusted to account for constraint info.

For tooltips, it's a similar problem. We ask the compiler to resolve the symbol, which ultimately hits a set of symbols that were resolved from name resolution. This contains certain information and may lack other information. In the case of not, it the not symbol is resolved as the not function. That's a bug for sure. But since not can mean either that function or be a kind of keyword in a constraint, it's not quite straightforward.

[abelbraaksma]

@cartermp Does, at the moment of coloring or tooltips, contextual information exist, like "inside a type constraint specification"? If so, than an approach could be taken to designate these "contextual keywords", and give different tooltips and coloring.

(I wouldn't mind taking a shot at this, provided such info is available)

[cartermp]

I'm not sure, I don't think so. In theory it could, since the call ultimately goes here: https://github.com/dotnet/fsharp/blob/master/src/fsharp/service/FSharpCheckerResults.fs#L1063

This will call name resolution and ask for a list of Item declarations for the current position we're in. I don't think these return any information about these things. Name resolution would need to be adjusted for that. But it could also be that the information is there, it's just not getting exposed in the calls that are made.