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
getSymbolAtLocation now supports class expressions #51049
Conversation
And accept baselines for later inspection. One fourslash test changes, indicating that quick info relied on getTypeAtLocation not returning anything for class expressions to distinguish named from anonymous class expressions. This predicate will have to be improved.
1. Some special-case code in find-all-refs is no longer relevant. 2. Using the real symbol gives names to more class expressions, so I made the expression more complex to keep the class truly anonymous in goToImplementationInterface_07. The quick info display also changes, from ``` (anonymous local class) ``` to ``` (local class) (Anonymous class) ``` This is more consistent internally and externally, so I think it's a good change.
@amcasey and @andrewbranch I think you know the most about how this will affect language service results. |
Only display `(local class)` if the class expression is named and has no alias. Other named classes use the normal `class C` format; anonymous classes display `(Anonymous class)`.
@typescript-bot test tsserver top100 |
Heya @amcasey, I've started to run the diff-based user code test suite (tsserver) on this PR at aaa3240. You can monitor the build here. Update: The results are in! |
Heya @amcasey, I've started to run the diff-based top-repos suite (tsserver) on this PR at aaa3240. You can monitor the build here. Update: The results are in! |
@amcasey Here are the results of running the user test suite comparing Everything looks good! |
So, I have basically no idea what impact this will have but, superficially, it looks completely out of place in the list of pre-existing syntax kind checks. If it was always an oversight (doesn't really look like it?), why wouldn't we do the same for function expressions? |
@amcasey Here are the results of running the top-repos suite comparing Something interesting changed - please have a look. Detailsfelixrieseberg/windows95
|
@sandersn The new server errors aren't related or interesting. |
From discussion on teams, getSymbolAtLocation currently only handles identifiers and some other keywords -- all single tokens. It seems likely that some other entrypoint handles symbols of other things like expressions, and that that's the right place for class expressions. |
I’d be interested to read the discussion on Teams I missed, because my assumption would have been that this:
is just an artifact of its usage in the services for things like quick info, where the cursor is necessarily confined to a single token. As an API entrypoint, I always understood its failure on higher nodes to be undesirable. |
@andrewbranch We just spoke 1:1. Neither of us had any context on what the function was supposed to do, but I observed that all the existing checks were for tokens, suggesting that expressions were handled elsewhere (or, alternatively, that several kinds of expressions needed to be supported). |
Overall, the benefit of getting rid of a couple of special cases in the services vs. changing the way getSymbolAtLocation works isn't justified. I'm going to close this for now. |
Overall, the benefit of getting rid of a couple of special cases in the services vs. changing the way getSymbolAtLocation works isn't justified. I'm going to close this for now. |
Discovered while writing #51016; after that merges I'll update this PR to remove its special-case code.
@override
#51016 will be when that merges.)goToImplementationInterface_07. The quick info display also changes, from
to
This is more consistent with named class expressions (
(local class) C
), so I think it's a good change.