Avoid accessing HIR when it can be avoided
Experiment to see if it helps some incremental cases.
Will be rebased once https://github.com/rust-lang/rust/pull/107942 gets merged.
r? `@ghost`
Resolve documentation links in rustc and store the results in metadata
This PR implements MCP https://github.com/rust-lang/compiler-team/issues/584.
Doc links are now resolved in rustc and stored into metadata, so rustdoc simply retrieves them through a query (local or extern),
Code that is no longer used is removed, and some code that no longer needs to be public is privatized.
The removed code includes resolver cloning, so this PR fixes https://github.com/rust-lang/rust/issues/83761.
Rollup of 8 pull requests
Successful merges:
- #103418 (Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report)
- #106113 (llvm-wrapper: adapt for LLVM API change)
- #106144 (Improve the documentation of `black_box`)
- #106578 (Label closure captures/generator locals that make opaque types recursive)
- #106749 (Update cc to 1.0.77)
- #106935 (Fix `SingleUseLifetime` ICE)
- #107015 (Re-enable building rust-analyzer on riscv64)
- #107029 (Add new bootstrap members to triagebot.toml)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Revert "Make PROC_MACRO_DERIVE_RESOLUTION_FALLBACK a hard error"
This reverts commit 7d82cadd97 aka PR #84022
I am doing this to buy us some time with respect to issue #106337 w.r.t. the 1.67 release.
Use UnordMap and UnordSet for id collections (DefIdMap, LocalDefIdMap, etc)
This PR changes the `rustc_data_structures::define_id_collections!` macro to use `UnordMap` and `UnordSet` instead of `FxHashMap` and `FxHashSet`. This should account for a large portion of hash-maps being used in places where they can cause trouble.
The changes required are moderate but non-zero:
- In some places the collections are extracted into sorted vecs.
- There are a few instances where for-loops have been changed to extends.
~~Let's see what the performance impact is. With a bit more refactoring, we might be able to get rid of some of the additional sorting -- but the change set is already big enough. Unless there's a performance impact, I'd like to do further changes in subsequent PRs.~~
Performance does not seem to be negatively affected ([perf-run here](https://github.com/rust-lang/rust/pull/106977#issuecomment-1396776699)).
Part of [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
r? `@ghost`
Fix bad import suggestion with nested `use` tree
Fixes#105566Fixes#105373
Ideally, we'd find some way to turn these into structured suggestions -- perhaps on a separate line as a different `use` statement, but I have no idea how to access the span for the whole `use` from this point in the import resolution code.
Point out span where we could introduce higher-ranked lifetime
Somewhat addresses #105422, but not really. We don't have that much useful information here since we're still in resolution :^(
Maybe this suggestion isn't worth it. If the reviewer has an idea how we can get a more succinct binder information for a structured suggestion, it would be appreciated.
add function to tell the identical errors for ambiguity_errors
if 2 errors of the kind and ident and span of the ident, b1, b2 and misc1 misc2 are the same we call these 2 ambiguity errors identical
prevent identical ambiguity error from pushing into vector of ambiguity_errors this will fix#105177
if 2 errors of the kind and ident and span of the ident, b1, b2 and misc1 misc2 are the same
then these 2 ambiguity errors matched
prevent identical ambiguity error from pushing into vector of ambiguity_errors
this will fix#105177
Lower them into a single item with multiple resolutions instead.
This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
make simple check of prinf function
Fixes https://github.com/rust-lang/rust/issues/92898
With this commit we start to make some simple
check when the name resolution fails, and
we generate some helper messages in case the
name is a C name like in the case of the `printf`
and suggest the correct rust method.
`@rustbot` r? `@pnkfelix`
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Prefer doc comments over `//`-comments in compiler
Doc comments are generally nicer: they show up in the documentation, they are shown in IDEs when you hover other mentions of items, etc. Thus it makes sense to use them instead of `//`-comments.
Separate lifetime ident from lifetime resolution in HIR
Drive-by: change how suggested generic args are computed.
Fixes https://github.com/rust-lang/rust/issues/103815
I recommend reviewing commit-by-commit.
With this commit we start to make some simple
check when the name resolution fails, and
we generate some helper message in case the
name is a C name like in the case of the `printf`
and suggest the correct rust method.
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
privacy: Fix more (potential) issues with effective visibilities
Continuation of https://github.com/rust-lang/rust/pull/103965.
See individual commits for more detailed description of the changes.
The shortcuts removed in 4eb63f618e and c7c7d16727 could actually be correct (or correct after some tweaks), but they used global reasoning like "we can skip this update because if the code compiles then some other update should do the same thing eventually".
I have some expertise in this area, but I still have doubt whether such global reasoning was correct or not, especially in presence of all possible exotic cases with imports.
After this PR all table changes should be "locally correct" after every update, even if it may be overcautious.
If similar optimizations are introduced again they will need detailed comments explaining why it's legal to do what they do and providing proofs.
Fixes https://github.com/rust-lang/rust/issues/104249.
Fixes https://github.com/rust-lang/rust/issues/104539.
resolve: Don't use constructor def ids in the map for field names
Also do some minor cleanup to insertion of those field names.
Addresses a FIXME left in https://github.com/rust-lang/rust/pull/103578.
Avoid `GenFuture` shim when compiling async constructs
Previously, async constructs would be lowered to "normal" generators, with an additional `from_generator` / `GenFuture` shim in between to convert from `Generator` to `Future`.
The compiler will now special-case these generators internally so that async constructs will *directly* implement `Future` without the need to go through the `from_generator` / `GenFuture` shim.
The primary motivation for this change was hiding this implementation detail in stack traces and debuginfo, but it can in theory also help the optimizer as there is less abstractions to see through.
---
Given this demo code:
```rust
pub async fn a(arg: u32) -> Backtrace {
let bt = b().await;
let _arg = arg;
bt
}
pub async fn b() -> Backtrace {
Backtrace::force_capture()
}
```
I would get the following with the latest stable compiler (on Windows):
```
4: async_codegen:🅱️:async_fn$0
at .\src\lib.rs:10
5: core::future::from_generator::impl$1::poll<enum2$<async_codegen:🅱️:async_fn_env$0> >
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91
6: async_codegen:🅰️:async_fn$0
at .\src\lib.rs:4
7: core::future::from_generator::impl$1::poll<enum2$<async_codegen:🅰️:async_fn_env$0> >
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91
```
whereas now I get a much cleaner stack trace:
```
3: async_codegen:🅱️:async_fn$0
at .\src\lib.rs:10
4: async_codegen:🅰️:async_fn$0
at .\src\lib.rs:4
```
Previously, async constructs would be lowered to "normal" generators,
with an additional `from_generator` / `GenFuture` shim in between to
convert from `Generator` to `Future`.
The compiler will now special-case these generators internally so that
async constructs will *directly* implement `Future` without the need
to go through the `from_generator` / `GenFuture` shim.
The primary motivation for this change was hiding this implementation
detail in stack traces and debuginfo, but it can in theory also help
the optimizer as there is less abstractions to see through.
Previously if the parent was not in the table, and there was nothing to inherit from, the child's private visibility was used, but that's not correct - the parent may have a larger visibility so we should set it to at least the parent's private visibility.
That parent's private visibility is also inserted into the table for caching, so it's not recalculated later if used again.
Optimizations removed in the previous commit required this function to behave incorrectly, but now those optimizations are gone so we can fix the bug.
Fixes https://github.com/rust-lang/rust/issues/104249
First, they require eagerly calculating private visibility (current normal module), which is somewhat expensive.
Private visibilities are also lost once calculated, instead of being cached in the table.
Second, I cannot prove that the optimizations are correct.
Maybe they can be partially reinstated in the future in cases when it's cheap and provably correct to do them.
They will also probably be merged into `fn update` in that case.
Partially fixes https://github.com/rust-lang/rust/issues/104249
Fixes https://github.com/rust-lang/rust/issues/104539
