| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
7538: Make sure normal dependencies always have version r=edwin0cheng a=pksunkara
How do I prevent this happening in the future by doing something in the CI? IIRC this is the second time.
Co-authored-by: Pavan Kumar Sunkara <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
7537: Fix spelling mistakes in docs/dev r=Veykril a=Veykril
Also adds a line for `crates/cfg` and `crates/stdx` to the architecture.
bors r+
Co-authored-by: Lukas Wirth <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
7536: Make architecture more informative r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| |
| | |
Call out boundaries and invariants
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
7528: Update mimalloc r=kjeremy a=kjeremy
Co-authored-by: kjeremy <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7525: Fix resolution of `crate` paths from within blocks r=jonas-schievink a=jonas-schievink
They resolve to the crate root, not the DefMap's root module (which
can be a block)
bors r+
Co-authored-by: Jonas Schievink <[email protected]>
|
|/
|
|
|
| |
They resolve to the crate root, not the DefMap's root module (which
can be a block)
|
|\
| |
| |
| |
| |
| |
| |
| | |
7523: Bump chalk and rustc_lexer r=lnicola a=lnicola
bors r+
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7522: Use non-deprecated memmap2 crate r=kjeremy a=kjeremy
`cargo audit` complains that `memmap` is unmaintained so switch to
RazrFalcon's maintained version.
Removes yet another edge on winapi
Co-authored-by: kjeremy <[email protected]>
|
|/
|
|
|
|
|
| |
`cargo audit` complains that `memmap` is unmaintained so switch to
RazrFalcon's maintained version.
Removes yet another edge on winapi
|
|\
| |
| |
| |
| |
| |
| |
| | |
7521: cargo update r=kjeremy a=kjeremy
Pulls in soundness fix from rowan.
Co-authored-by: kjeremy <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7520: Show alias underlying type r=lnicola a=lumenian
Closes #7511
Display underlying type in the tooltip:
```rust
pub type SomeAlias = f64
```
instead of:
```rust
pub type SomeAlias
```
Co-authored-by: lumenian <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
7519: add useless types to the styleguide r=matklad a=matklad
bors r+
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7518: Use the right `DefMap` when looking up modules r=jonas-schievink a=jonas-schievink
Fixes the bugs encountered in https://github.com/rust-analyzer/rust-analyzer/pull/7506#issuecomment-771417467
bors r+
Co-authored-by: Jonas Schievink <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7516: Revert "Use block_def_map in body lowering" r=jonas-schievink a=jonas-schievink
Reverts rust-analyzer/rust-analyzer#7506
bors r+
Co-authored-by: Jonas Schievink <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7514: Only allow one proc-macro process r=edwin0cheng a=edwin0cheng
cc @lnicola
bors r+
Co-authored-by: Edwin Cheng <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
7512: Reap proc macro server instances r=lnicola a=lnicola
Fixes #7510, but not the root cause.
Co-authored-by: Laurențiu Nicola <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
7509: Improve nvim-lsp setup instructions r=lnicola a=lnicola
bors r+
Co-authored-by: Laurențiu Nicola <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7508: Don't filter code suggestions on Applicability r=lnicola a=CryZe
I've noticed that there are various suggestions that rust-analyzer seems to filter out, even if they make sense.
Here's an example of where it seems like there should be a suggestion, but there isn't:
![https://i.imgur.com/wsjM6iz.png](https://i.imgur.com/wsjM6iz.png)
It turns out that this specific suggestion is not considered `MachineApplicable`, which are the only suggestions that rust-analyzer accepts. However if you read the documentation for `MachineApplicable`,
[Source](https://github.com/rust-lang/rust/blob/b3897e3d1302391ed02efbac1dce8073646b8173/compiler/rustc_lint_defs/src/lib.rs#L27-L29)
```rust
/// The suggestion is definitely what the user intended. This suggestion should be
/// automatically applied.
MachineApplicable,
```
then you realize that these are specifically only those suggestions that rust-analyzer could even automatically apply (in some distant future, behind some setting or command or so). Other suggestions that may have some semantic impact do not use `MachineApplicable`. So all other suggestions are still intended to be suggested to the user, just not automatically applied without the user being consulted.
[Source](https://github.com/rust-lang/rust/blob/b3897e3d1302391ed02efbac1dce8073646b8173/compiler/rustc_lint_defs/src/lib.rs#L22-L24)
```rust
/// All suggestions are marked with an `Applicability`. Tools use the applicability of a suggestion
/// to determine whether it should be automatically applied or if the user should be consulted
/// before applying the suggestion.
```
So with that in mind, rust-analyzer should almost definitely not filter out `MaybeIncorrect` (which honestly is named horribly, it just means that it's a semantic change, not just a syntactical one).
Then there's `HasPlaceholders` which basically is just another semantic one, but with placeholders. The user will have to make some adjustments, but the suggestion still is perfectly valid. rust-analyzer could probably detect those placeholders and put proper "tab through" markers there for the IDE, but that's not necessary for now.
Then the last one is `Unspecified` which is so unknown that I don't even know how to judge it, meaning that the suggestion should probably also just be suggested to the user and then they can decide.
So with all that in mind, I'm proposing to get rid of the check for Applicability entirely.
Co-authored-by: Christopher Serr <[email protected]>
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've noticed that there are various suggestions that rust-analyzer seems
to filter out, even if they make sense.
Here's an example of where it seems like there should be a suggestion,
but there isn't:
![https://i.imgur.com/wsjM6iz.png](https://i.imgur.com/wsjM6iz.png)
It turns out that this specific suggestion is not considered
`MachineApplicable`, which are the only suggestions that rust-analyzer
accepts. However if you read the documentation for `MachineApplicable`,
https://github.com/rust-lang/rust/blob/b3897e3d1302391ed02efbac1dce8073646b8173/compiler/rustc_lint_defs/src/lib.rs#L27-L29
then you realize that these are specifically only those suggestions that
rust-analyzer could even automatically apply (in some distant future,
behind some setting or so). Other suggestions that may have some
semantic impact do not use `MachineApplicable`. So all other suggestions
are still intended to be suggested to the user, just not automatically
applied without the user being consulted.
https://github.com/rust-lang/rust/blob/b3897e3d1302391ed02efbac1dce8073646b8173/compiler/rustc_lint_defs/src/lib.rs#L22-L24
So with that in mind, rust-analyzer should almost definitely not filter
out `MaybeIncorrect` (which honestly is named horribly, it just means
that it's a semantic change, not just a syntactical one).
Then there's `HasPlaceholders` which basically is just another semantic
one, but with placeholders. The user will have to make some adjustments,
but the suggestion still is perfectly valid. rust-analyzer could
probably detect those placeholders and put proper "tab through" markers
there for the IDE, but that's not necessary for now.
Then the last one is `Unspecified` which is so unknown that I don't even
know how to judge it, meaning that the suggestion should probably also
just be suggested to the user and then they can decide.
So with all that in mind, I'm proposing to get rid of the check for
Applicability entirely.
|
|\
| |
| |
| |
| |
| |
| |
| | |
7507: Explain what to do if a release fails r=lnicola a=lnicola
bors r+
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
7506: Use block_def_map in body lowering r=jonas-schievink a=jonas-schievink
This makes `lower_block` update the `DefMap` and `ModuleId` used by the expander to the corresponding `block_def_map`. This cleans up a bit of code, but doesn't expose any new features.
bors r+
Co-authored-by: Jonas Schievink <[email protected]>
|
| |
| |
| |
| |
| | |
This previously didn't work, but apparently only because of the wonky
test setup
|
| |
| |
| |
| | |
Removes the hacky and buggy custom lowering code
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
7503: Return inner attributes of outline mod declarations in `attrs_query` r=jonas-schievink a=Veykril
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7502: Honor #![macro_use] in mod source files r=jonas-schievink a=Veykril
Fixes #7501
Since `ItemTree` builds the `RawAttrs` directly we need the special check here as I don't think we can fix this in `RawAttrs` constructor as its solely AST based and we need to touch two different ASTs here.
This just made me realize that `attrs_query` suffers from a similar problem, for example hovering an outline `mod` decl won't show inner docs, only outer ones, #7503.
Co-authored-by: Lukas Wirth <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7500: Fix ast::String::value not properly escaping in some cases r=Veykril a=Veykril
Fixes #7496
bors r+
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
7483: Classify function calls as functions when shadowed by types r=matklad a=Veykril
Fixes #7479
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |
|
| | |
|