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.

Sign up for GitHub

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

Jump to bottom

Use builtin scopes more #6496

Merged
merged 2 commits into from
Nov 26, 2020
Merged

Use builtin scopes more #6496

merged 2 commits into from
Nov 26, 2020

Conversation

georgewfraser
Copy link
Contributor

VSCode has added more builtin fallback scopes, so we can remove some of our fallback scopes by aligning with their conventions.

Note that the macro scope doesn't seem to actually work at the moment. I have filed a bug with VSCode: microsoft/vscode#110150

@georgewfraser georgewfraser mentioned this pull request Nov 7, 2020
Merged
matklad
matklad reviewed Nov 9, 2020
View reviewed changes
crates/rust-analyzer/src/semantic_tokens.rs Outdated
@@ -40,7 +40,7 @@ macro_rules! define_semantic_token_types {
define_semantic_token_types![
(ATTRIBUTE, "attribute"),
(BOOLEAN, "boolean"),
(BUILTIN_TYPE, "builtinType"),
(BUILTIN_TYPE, "type.defaultLibrary"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, did they ship nested.types in LSP/VS Code? I thought that that's only planned?

Or does it work by some coincidence, where VS Code uses textmate scope for this semantic token, without anything establishing the mapping explicitly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm. I didn't think about this, I wonder if I should really be adding an attribute "defaultLibrary" rather than sending both "type" and "defaultLibrary" in one token "type.defaultLibrary".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yeah, indeed, it is standard token modifier: https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#semantic-token-classification

SO, I think when we lower BUITIN_TYPE to lsp, we should snap this builtin modifier on top (there's a chance that lsp_types even has it as a constant)

crates/rust-analyzer/src/semantic_tokens.rs Outdated
@@ -70,7 +70,7 @@ macro_rules! define_semantic_token_modifiers {
}

define_semantic_token_modifiers![
(CONSTANT, "constant"),
(CONSTANT, "readonly"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I guess this is "practicality beats purity"? const & readonly are pretty different things, but I guess we can re-purpose readonly as const and just use mutable for (complement of) cases where we'd use readonly otherwise?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is debatable. It's not like we can match the builtin scopes 100%, and constant is more semantically correct, so we could just decide to do our own thing. It does seem like the builtins are basically "whatever typescript needs."

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am inclined to stick to semantically-correct constant, unless readonly significantly improves theme support.

@georgewfraser
Copy link
Contributor Author

OK, I've cut this down to just remove the macro fallback, now that VSCode has implemented a builtin fallback: microsoft/vscode#110150

@matklad
Copy link
Member

matklad commented Nov 26, 2020

Ah, perfect!

bors r+

@bors
Copy link
Contributor

bors bot commented Nov 26, 2020

Build succeeded:

@bors bors bot merged commit ed5c175 into rust-lang:master Nov 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@matklad matklad matklad left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@georgewfraser @matklad