Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
abelbraaksma opened this issue Jul 24, 2020 · 3 comments
Labels
Milestone

Comments

@abelbraaksma
Copy link
Contributor

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

image

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

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

image

@cartermp
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: New
Development

No branches or pull requests

4 participants