| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
It already stores the DefMap containing the module, so having
a full ModuleId is unnecessary and makes it easier to mix things up
|
| | |
| | |
| | |
| | |
| | | |
This seems like it could easily leak a lot of memory since we don't
currently run GC
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7546: Add newline between block and crate maps r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | | |
|
|/ / / |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7541: Use block_def_map in body lowering (third time's the charm) r=jonas-schievink a=jonas-schievink
After https://github.com/rust-analyzer/rust-analyzer/pull/7380 and https://github.com/rust-analyzer/rust-analyzer/pull/7506 both had to be reverted, this should have finally resolved all remaining bugs.
Most importantly, the optimization to skip `block_def_map` computation when the block contains no inner items was fixed (which fortunately was simpler than expected).
I've ran `analysis-stats` on libstd locally, which works fine, and also ran this PR locally for a short while without issues.
Note that this *still* has no (or almost no) user-facing impact, because the rest of r-a still relies on some local item support hacks.
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
|
| | | | |
|
|/ / / |
|
|/ / |
|
| |
| |
| |
| |
| | |
They resolve to the crate root, not the DefMap's root module (which
can be a block)
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
`cargo audit` complains that `memmap` is unmaintained so switch to
RazrFalcon's maintained version.
Removes yet another edge on winapi
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
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]>
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7494: Simpilfy mbe parsing r=edwin0cheng a=edwin0cheng
bors r+
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | | |
|
|/ / / |
|
| | |
| | |
| | |
| | | |
Handle parse error in rule parsing instead of match in mbe
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Apparently we were using the crate's root file instead of the file
containing the block.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7482: block_def_map: add a few macro tests r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7412: Async loading for outdir and proc-macro r=maklad a=edwin0cheng
cc #7328
![Peek 2021-01-24 02-04](https://user-images.githubusercontent.com/11014119/105610083-8f208100-5de8-11eb-8e96-c2d4e349b352.gif)
[Edit]
~~Finding a way to know when the workspace and build data are loaded...~~
[Edit 2]
Not perfect solution, but seem to work now.
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | | |
|