5679: Account for static mut in missing unsafe diagnostic r=jonas-schievink a=Nashenas88
Accessing or modifying a static mut is an unsafe operation. The "missing unsafe" diagnostic now tracks this.
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5678: Static mut unsafe semantic highlighting r=jonas-schievink a=Nashenas88
This marks static mutable names as unsafe, since accessing or modifying a static mut is an unsafe operation.
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5526: Handle semantic token deltas r=kjeremy a=kjeremy
This basically takes the naive approach where we always compute the tokens but save space sending over the wire which apparently solves some GC problems with vscode.
This is waiting for https://github.com/gluon-lang/lsp-types/pull/174 to be merged. I am also unsure of the best way to stash the tokens into `DocumentData` in a safe manner.
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
5639: SSR: Allow `self` in patterns. r=jonas-schievink a=davidlattimore
It's now consistent with other variables in that if the pattern references self, only the `self` in scope where the rule is invoked will be accepted. Since `self` doesn't work the same as other paths, this is implemented by restricting the search to just the current function. Prior to this change (since path resolution was implemented), having self in a pattern would just result in no matches.
Co-authored-by: David Lattimore <dml@google.com>
5664: Fix renamed self module. r=jonas-schievink a=Nashenas88
Fixes#5663
Now `inner_mod` below is properly marked as a `module`.
```rust
use crate::inner::{self as inner_mod};
mod inner {}
```
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
`current_dir` and relative paths to executables works differently on
unix and windows (unix behavior does not make sense), see:
17e30e83a1/src/lib.rs (L295-L324)
The original motivation to set cwd was to make rustfmt read the
correct rustfmt.toml, but that was future proofing, rather than a bug
fix.
So, let's just remove this and see if breaks or fixes more use-cases.
If support for per-file config is needed, we could use `--config-path`
flag.
5658: do not add to `pub use` in assists that insert a use statement r=jonas-schievink a=jbr
closes#5657 , see issue for rationale
Initially I wrote a version of this that changed the signature of `insert_use_statement` to take an `Option<VisibilityKind>` and only add to use statements with the same visibility, but that didn't make sense for any of the current uses of `insert_use_statement` (they all expected private visibility).
Co-authored-by: Jacob Rothstein <hi@jbr.me>
It's now consistent with other variables in that if the pattern
references self, only the `self` in scope where the rule is invoked will
be accepted. Since `self` doesn't work the same as other paths, this is
implemented by restricting the search to just the current function.
Prior to this change (since path resolution was implemented), having
self in a pattern would just result in no matches.
This fixes matching of things like `HashMap::default()` by resolving
`HashMap` instead of `default` (which resolves to `Default::default`).
Same for associated constants and types that are part of a trait
implementation.
However, we still don't support matching calls to trait methods.
Note that `for` type is rust-analyzer's own invention.
Both the reference and syn allow `for` only for fnptr types, and we
allow them everywhere. This needs to be checked with respect to type
bounds grammar...
The TypeRef name comes from IntelliJ days, where you often have both
type *syntax* as well as *semantical* representation of types in
scope. And naming both Type is confusing.
In rust-analyzer however, we use ast types as `ast::Type`, and have
many more semantic counterparts to ast types, so avoiding name clash
here is just confusing.
5596: Add checkOnSave.noDefaultFeatures and correct, how we handle some cargo flags. r=clemenswasser a=clemenswasser
This PR adds the `rust-analyzer.checkOnSave.noDefaultFeatures` option
and fixes the handling of `cargo.allFeatures`, `cargo.noDefaultFeatures` and `cargo.features`.
Fixes: #5550
Co-authored-by: Clemens Wasser <clemens.wasser@gmail.com>
This commit fixes the handling of user-defined configuration
of some cargo options. Previously you could either specify
`--all-features`, `--no-default-features` or `--features`.
Now you can specify either `--all-features` or `--no-default-features`
and `--features`. This commit also corrects the `--features`
command-line argument creation inside of `load_extern_resources`.
5567: SSR: Wrap placeholder expansions in parenthesis when necessary r=matklad a=davidlattimore
e.g. `foo($a) ==> $a.to_string()` should produce `(1 + 2).to_string()` not `1 + 2.to_string()`
We don't yet try to determine if the whole replacement needs to be wrapped in parenthesis. That's harder and I think perhaps less often an issue.
Co-authored-by: David Lattimore <dml@google.com>
e.g. `foo($a) ==> $a.to_string()` should produce `(1 + 2).to_string()`
not `1 + 2.to_string()`
We don't yet try to determine if the whole replacement needs to be
wrapped in parenthesis. That's harder and I think perhaps less often an
issue.
5554: Fix remove_dbg r=matklad a=petr-tik
Closes#5129
Addresses two issues:
- keep the parens from dbg!() in case the call is chained or there is
semantic difference if parens are excluded
- Exclude the semicolon after the dbg!(); by checking if it was
accidentally included in the macro_call
investigated, but decided against:
fix ast::MacroCall extraction to never include semicolons at the end -
this logic lives in rowan.
Defensively shorten the macro_range if there is a semicolon token.
Deleted unneccessary temp variable macro_args
Renamed macro_content to "paste_instead_of_dbg", because it isn't a
simple extraction of text inside dbg!() anymore
Co-authored-by: petr-tik <petr-tik@users.noreply.github.com>
5563: Check all targets for package-level tasks r=matklad a=SomeoneToIgnore
When invoking "Select Runnable" with the caret on a runnable with a specific target (test, bench, binary), append the corresponding argument for the `cargo check -p` module runnable.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
replaced match with let-if variable assignment
removed the unnecessary semicolon_on_end variable
converted all code and expected test variables to raw strings
and inlined them in asserts
The primary advantage of ungrammar is that it (eventually) allows one
to describe concrete syntax tree structure -- with alternatives and
specific sequence of tokens & nodes.
That should be re-usable for:
* generate `make` calls
* Rust reference
* Hypothetical parser's evented API
We loose doc comments for the time being unfortunately. I don't think
we should add support for doc comments to ungrammar -- they'll make
grammar file hard to read. We might supply docs as out-of band info,
or maybe just via a reference, but we'll think about that once things
are no longer in flux
5564: SSR: Restrict to current selection if any r=davidlattimore a=davidlattimore
The selection is also used to avoid unnecessary work, but only to the file level. Further restricting unnecessary work is left for later.
Co-authored-by: David Lattimore <dml@google.com>
5565: SSR: Don't mix non-path-based rules with path-based r=matklad a=davidlattimore
If any rules contain paths, then we reject any rules that don't contain paths. Allowing a mix leads to strange semantics, since the path-based rules only match things where the path refers to semantically the same thing, whereas the non-path-based rules could match anything. Specifically, if we have a rule like `foo ==>> bar` we only want to match the `foo` that is in the current scope, not any `foo`. However "foo" can be parsed as a pattern (BIND_PAT -> NAME -> IDENT). Allowing such a rule through would result in renaming everything called `foo` to `bar`. It'd also be slow, since without a path, we'd have to use the slow-scan search mechanism.
Co-authored-by: David Lattimore <dml@google.com>
If any rules contain paths, then we reject any rules that don't contain paths. Allowing a mix leads to strange semantics, since the path-based rules only match things where the path refers to semantically the same thing, whereas the non-path-based rules could match anything. Specifically, if we have a rule like `foo ==>> bar` we only want to match the `foo` that is in the current scope, not any `foo`. However "foo" can be parsed as a pattern (BIND_PAT -> NAME -> IDENT). Allowing such a rule through would result in renaming everything called `foo` to `bar`. It'd also be slow, since without a path, we'd have to use the slow-scan search mechanism.
Addresses two issues:
- keep the parens from dbg!() in case the call is chained or there is
semantic difference if parens are excluded
- Exclude the semicolon after the dbg!(); by checking if it was
accidentally included in the macro_call
investigated, but decided against:
fix ast::MacroCall extraction to never include semicolons at the end -
this logic lives in rowan.
Defensively shorten the macro_range if there is a semicolon token.
Deleted unneccessary temp variable macro_args
Renamed macro_content to "paste_instead_of_dbg", because it isn't a
simple extraction of text inside dbg!() anymore
It seems that Semantics::scope, if given a statement node, won't resolve
locals that were defined in the current scope, only in parent scopes.
Not sure if this is intended / expected behavior, but we work around it
for now by finding another nearby node to use as the scope (e.g. the
expression inside the EXPR_STMT).
5520: Add DocumentData to represent in-memory document with LSP info r=matklad a=kjeremy
At the moment this only holds document version information but in the near-future it will hold other things like semantic token delta info.
Co-authored-by: kjeremy <kjeremy@gmail.com>
5522: Increace tracing-tree version from 0.1.3 to 0.1.4 r=kjeremy a=vandenheuvel
Co-authored-by: Bram van den Heuvel <b.vandenheuvel@student.tudelft.nl>
5516: Better LSP conformance r=matklad a=vsrs
At the moment rust-analyzer does not fully conform to the LSP. This PR fixes two LSP related issues:
1) rust-analyzer sends predefined server capabilities and does not take supplied client capabilities in mind.
2) rust-analyzer uses dynamic `textDocument/didSave` registration even if the client does not support it.
Co-authored-by: vsrs <vit@conrlab.com>
5518: Use resolved paths in SSR rules r=matklad a=davidlattimore
The main user-visible changes are:
* SSR now matches paths based on whether they resolve to the same thing instead of whether they're written the same.
* So `foo()` won't match `foo()` if it's a different function `foo()`, but will match `bar::foo()` if it's the same `foo`.
* Paths in the replacement will now be rendered with appropriate qualification for their context.
* For example `foo::Bar` will render as just `Bar` inside the module `foo`, but might render as `baz::foo::Bar` from elsewhere.
* This means that all paths in the search pattern and replacement template must be able to be resolved.
* It now also matters where you invoke SSR from, since paths are resolved relative to wherever that is.
* Search now uses find-uses on paths to locate places to try matching. This means that when a path is present in the pattern, search will generally be pretty fast.
* Function calls can now match method calls again, but this time only if they resolve to the same function.
Co-authored-by: David Lattimore <dml@google.com>
This differs from how this used to work before I removed it in that:
a) It's only one direction. Function calls in the pattern can match
method calls in the code, but not the other way around.
b) We now check that the function call in the pattern resolves to the
same function as the method call in the code.
The lack of (b) was the reason I felt the need to remove the feature
before.
Previously, submatches were handled simply by searching in placeholders
for more matches. That only works if we search all nodes in the tree
recursively. In a subsequent commit, I intend to make search not always
be recursive recursive. This commit prepares for that by finding all
matches, even if they overlap, then nesting them and removing
overlapping matches.
In a later commit, paths in templates will be resolved. This allows us
to render the path with appropriate qualifiers for its context. Here we
prepare for that change by updating existing tests where I'd previously
not bothered to define the items that the template referred to.
The methods `edits_for_file` and `find_matches_in_file` are replaced with just `edits` and `matches`. This simplifies the API a bit, but more importantly it makes it possible in a subsequent commit for SSR to decide to not search all files.
Also renamed find_matches to slow_scan_node to reflect that it's a slow
way to do things. Actually the name came from a later commit and
probably makes more sense once there's an alternative.
This is in preparation for a subsequent commit where we add special
handling for paths in the template, allowing them to be qualified
differently in different contexts.
Previously we had:
- Multiple rules
- Each rule had its pattern parsed as an expression, path etc
This meant that there were two levels at which there could be multiple
rules.
Now we just have multiple rules. If a pattern can parse as more than one
kind of thing, then they get stored as multiple separate rules.
We also now don't have separate fields for the different kinds of things
that a pattern can parse as. This makes adding new kinds of things
simpler.
Previously, add_search_pattern would construct a rule with a dummy
replacement. Now the replacement is an Option. This is slightly cleaner
and also opens the way for parsing the replacement template as the same
kind of thing as the search pattern.
5498: assists: change_return_type_to_result: clarify assist description r=matklad a=matthiaskrgr
I had a -> Option<PathBuf> fn, which I wanted to change to Result<PathBuf, _>, but despite advertising to do so, the assist did not change the result type to Result<PathBuf, _> but instead just wrapped it in a Result: <Result<Option<PathBuf>, _>.
I changed the assist description to "Wrap return type in Result" to clarify that the assist only wraps the preexisting type and does not do any actual Option-to-Result refactoring.
Co-authored-by: Matthias Krüger <matthias.krueger@famsik.de>
5497: Store macro invocation parameters as text instead of tt r=jonas-schievink a=lnicola
We don't want to expand macros on every source change because it can be arbitrarily slow, but the token trees can be rather large. So instead we can cache the invocation parameters (as text).
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
I had a -> Option<PathBuf> fn, which I wanted to change to Result<PathBuf, _>, but despite advertising to do so, the assist did not
change the result type to Result<PathBuf, _> but instead just wrapped it in a Result: <Result<Option<PathBuf>, _>.
I changed the assist description to "Wrap return type in Result" to clarify that the assist only wraps the preexisting type and does
not do any deep Option-to-Result refactoring.
5481: Track document versions in the server r=kjeremy a=kjeremy
This also pushes diagnostics for the correct file version on close so that when it is reopened stale diagnostics are not shown.
Closes#5452
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
5478: Replace existing visibility modifier in fix_visibility r=matklad a=TimoFreiberg
Fixes#4636
I would have liked to do something about the `// FIXME: this really should be a fix for diagnostic, rather than an assist.`, but that would take a while and there's no reason not to fix this immediately.
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
