bors[bot] [Wed, 13 May 2020 09:09:46 +0000 (09:09 +0000)]
Merge #4083
4083: Smol documentation for ast nodes r=matklad a=Veetaha
There is a tremendous amount of TODOs to clarify the topics I am not certain about.
Please @matklad, @edwin0cheng review carefully, I even left some mentions of your names in todos to put your attention where you most probably can give comments.
In order to simplify the review, I separated the codegen (i.e. changes in `ast/generated/nodes.rs`) from `ast_src` changes (they in fact just duplicate one another) into two commits.
Also, I had to hack a little bit to let the docs be generated as doc comments and not as doc attributes because it's easier to read them this way and IIRC we don't support hints for `#[doc = ""]` attributes for now...
veetaha [Tue, 12 May 2020 20:33:56 +0000 (23:33 +0300)]
Revert "Remove MacroStmts as per edwin0cheng" (cc @edwin0cheng) and add a fixme to document it.
This reverts commit 7a49165f5d5c8186edd04f874eae8a98e39d3df6.
MacroStmts ast node is not used by itself, but it pertains
to SyntaxNodeKind MACRO_STMTS that is used by ra_paser, so
even tho the node itself is not used, it is better to keep it
with a FIXME to actually add a doc comment when it becomes useful.
bors[bot] [Tue, 12 May 2020 15:36:39 +0000 (15:36 +0000)]
Merge #4436
4436: Use .rust suffix on scopes r=matklad a=georgewfraser
This PR should have no effect on people using any of the default themes, but it is possible there are people with custom themes that rely on the .rust suffix on textmate scopes, which I neglected to use consistently in #4397.
Co-authored-by: George Fraser <george@fivetran.com>
This PR tweaks the fallback TextMate scopes to make them more consistent with the existing grammar and other languages, and edits the builtin TextMate grammar to align with semantic coloring. Before is on the left, after is on the right:
**Use keyword.other for regular keywords instead of keyword**. This is a really peculiar quirk of TextMate conventions, but virtually *all* TextMate grammars use `keyword.other` (colored blue in VSCode Dark+) for regular keywords and `keyword.control` (colored purple in VSCode Dark+) for control keywords. The TextMate scope `keyword` is colored like control keywords, not regular keywords. It may seem strange that the `keyword` scope is not the right fallback for the `keyword` semantic token, but TextMate has a long and weird history. Note how keywords change from purple back to blue (what they were before semantic coloring was added):
**(1) Use punctuation.section.embedded for format specifiers**. This aligns with how Typescript colors formatting directives:
**(2) Consistently use `entity.name.type.*` scopes for type names**. Avoid using `entity.name.*` which gets colored like a keyword.
**(3) Use Property instead of Member for fields**. Property and Member are very similar, but if you look at the TextMate fallback scopes, it's clear that Member is intended for function-like-things (methods?) and Property is intended for variable-like-things.
**(4) Color `for` as a regular keyword when it's part of `impl Trait for Struct`**.
**(5) Use `variable.other.constant` for constants instead of `entity.name.constant`**. In the latest VSCode insiders, variable.other.constant has a subtly different color that differentiates constants from ordinary variables. It looks close to the green of types but it's not the same---it's a new color recently added to take advantage of semantic coloring.
I also made some minor changes that make the TextMate scopes better match the semantic scopes. The effect of this for the user is you observe less of a change when semantic coloring "activates". You can see the changes I made relative to the built-in TextMate grammar here:
bors[bot] [Mon, 11 May 2020 12:21:08 +0000 (12:21 +0000)]
Merge #4421
4421: Find references to a function outside module r=flodiebold a=montekki
Fixes #4188
Yet again, it looks like although the code in
https://github.com/rust-analyzer/rust-analyzer/blob/da1f316b0246ce41d7cb8560181e294089f06ef3/crates/ra_ide_db/src/search.rs#L128-L132
may be wrong, it is not hit since the `vis` is `None` at this point. The fix is similar to the #4237 case: just add another special case to `Definition::visibility()`.
bors[bot] [Sun, 10 May 2020 14:48:04 +0000 (14:48 +0000)]
Merge #4412
4412: infer: Make expected rhs type for plain assign the lhs type r=flodiebold a=kiljacken
This fixes an issue where the following code sample would fail to infer
the type contained in the option:
```rust
fn main() {
let mut end = None; // Was Option<{unknown}>, is now Option<bool>
loop {
end = Some(true);
}
}
```
Co-authored-by: Emil Lauridsen <mine809@gmail.com>
Emil Lauridsen [Sun, 10 May 2020 14:20:13 +0000 (16:20 +0200)]
infer: Make expected rhs type for plain assign the lhs type
This fixes an issue where the following code sample would fail to infer
the type contained in the option:
```rust
fn main() {
let mut end = None; // TODO: Fix inference for this in RA
loop {
end = Some(true);
}
}
```
projects / rust.git / log