resolve: mark it undetermined if single import is not has any bindings
- Fixes#124490
- Fixes#125013
This issue arises from incorrect resolution updates, for example:
```rust
mod a {
pub mod b {
pub mod c {}
}
}
use a::*;
use b::c;
use c as b;
fn main() {}
```
1. In the first loop, binding `(root, b)` is refer to `root:🅰️:b` due to `use a::*`.
1. However, binding `(root, c)` isn't defined by `use b::c` during this stage because `use c as b` falls under the `single_imports` of `(root, b)`, where the `imported_module` hasn't been computed yet. This results in marking the `path_res` for `b` as `Indeterminate`.
2. Then, the `imported_module` for `use c as b` will be recorded.
2. In the second loop, `use b::c` will be processed again:
1. Firstly, it attempts to find the `path_res` for `(root, b)`.
2. It will iterate through the `single_imports` of `use b::c`, encounter `use c as b`, attempt to resolve `c` in `root`, and ultimately return `Err(Undetermined)`, thus passing the iterator.
3. Use the binding `(root, b)` -> `root:🅰️:b` introduced by `use a::*` and ultimately return `root:🅰️:b` as the `path_res` of `b`.
4. Then define the binding `(root, c)` -> `root:🅰️🅱️:c`.
3. Then process `use c as b`, update the resolution for `(root, b)` to refer to `root:🅰️🅱️:c`, ultimately causing inconsistency.
In my view, step `2.2` has an issue where it should exit early, similar to the behavior when there's no `imported_module`. Therefore, I've added an attribute called `indeterminate` to `ImportData`. This will help us handle only those single imports that have at least one determined binding.
r? ``@petrochenkov``
Rollup of 12 pull requests
Successful merges:
- #123168 (Add `size_of` and `size_of_val` and `align_of` and `align_of_val` to the prelude)
- #125273 (bootstrap: implement new feature `bootstrap-self-test`)
- #125683 (Rewrite `suspicious-library`, `resolve-rename` and `incr-prev-body-beyond-eof` `run-make` tests in `rmake.rs` format)
- #125815 (`rustc_parse` top-level cleanups)
- #125903 (rustc_span: Inline some hot functions)
- #125906 (Remove a bunch of redundant args from `report_method_error`)
- #125920 (Allow static mut definitions with #[linkage])
- #125982 (Make deleting on LinkedList aware of the allocator)
- #125995 (Use inline const blocks to create arrays of `MaybeUninit`.)
- #125996 (Closures are recursively reachable)
- #126003 (Add a co-maintainer for the two ARMv4T targets)
- #126004 (Add another test for hidden types capturing lifetimes that outlive but arent mentioned in substs)
r? `@ghost`
`@rustbot` modify labels: rollup
Add another test for hidden types capturing lifetimes that outlive but arent mentioned in substs
Another test to make sure future implementations of https://github.com/rust-lang/rust/pull/116040 don't have any subtle unsoundness 🤔
r? types
Add a co-maintainer for the two ARMv4T targets
This adds a second maintainer to the `armv4t-none-eabi` and `thumbv4t-none-eabi` targets, a necessary step on the path to Tier 2
Use inline const blocks to create arrays of `MaybeUninit`.
This PR contains 2 changes enabled by the fact that [`inline_const` is now stable](https://github.com/rust-lang/rust/pull/104087), and was split out of #125082.
1. Use inline const instead of `unsafe` to construct arrays in `MaybeUninit` examples.
Rationale: Demonstrate good practice of avoiding `unsafe` code where it is not strictly necessary.
4. Use inline const instead of `unsafe` to implement `MaybeUninit::uninit_array()`.
This is arguably giving the compiler more work to do, in exchange for eliminating just one single internal unsafe block, so it's less certain that this is good on net.
r? `@Nilstrieb`
`rustc_parse` top-level cleanups
A bunch of improvements in and around `compiler/rustc_parse/src/lib.rs`. Many of the changes streamline the API in that file from this (12 functions and one macro):
```
name args return type
---- ---- -----------
panictry_buffer! Result<T, Vec<Diag>> T
pub parse_crate_from_file path PResult<Crate>
pub parse_crate_attrs_from_file path PResult<AttrVec>
pub parse_crate_from_source_str name,src PResult<Crate>
pub parse_crate_attrs_from_source_str name,src PResult<AttrVec>
pub new_parser_from_source_str name,src Parser
pub maybe_new_parser_from_source_str name,src Result<Parser, Vec<Diag>>
pub new_parser_from_file path,error_sp Parser
maybe_source_file_to_parser srcfile Result<Parser, Vec<Diag>>
pub parse_stream_from_source_str name,src,override_sp TokenStream
pub source_file_to_stream srcfile,override_sp TokenStream
maybe_file_to_stream srcfile,override_sp Result<TokenStream, Vec<Diag>>
pub stream_to_parser stream,subparser_name Parser
```
to this:
```
name args return type
---- ---- -----------
unwrap_or_emit_fatal Result<T, Vec<Diag>> T
pub new_parser_from_source_str name,src Result<Parser, Vec<Diag>>
pub new_parser_from_file path,error_sp Result<Parser, Vec<Diag>>
new_parser_from_source_file srcfile Result<Parser, Vec<Diag>>
pub source_str_to_stream name,src,override_sp Result<TokenStream, Vec<Diag>>
source_file_to_stream srcfile,override_sp Result<TokenStream, Vec<Diag>>
```
I found the old API quite confusing, with lots of similar-sounding function names and no clear structure. I think the new API is much better.
r? `@spastorino`
Rewrite `suspicious-library`, `resolve-rename` and `incr-prev-body-beyond-eof` `run-make` tests in `rmake.rs` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Some oddly specific ignore flags in `incr-prev-body-beyond-eof`:
```rs
// ignore-none
// ignore-nvptx64-nvidia-cuda
```
it could be interesting to run a try job, but it seems there is no nvidia-cuda in the CI settings (`jobs.yml`).
try-job: armhf-gnu
bootstrap: implement new feature `bootstrap-self-test`
Some of the bootstrap logics should be ignored during unit tests because they either make the tests take longer or cause them to fail. Therefore we need to be able to exclude them from the bootstrap when it's called by unit tests. This change introduces a new feature called `bootstrap-self-test`, which is enabled on bootstrap unit tests by default. This allows us to keep the logic separate between compiler builds and bootstrap tests without needing messy workarounds (like checking if target names match those in the unit tests).
Also, resolves https://github.com/rust-lang/rust/issues/122090 (without having to create separate modules)
Add `size_of` and `size_of_val` and `align_of` and `align_of_val` to the prelude
(Note: need to update the PR to add `align_of` and `align_of_val`, and remove the second commit with the myriad changes to appease the lint.)
Many, many projects use `size_of` to get the size of a type. However,
it's also often equally easy to hardcode a size (e.g. `8` instead of
`size_of::<u64>()`). Minimizing friction in the use of `size_of` helps
ensure that people use it and make code more self-documenting.
The name `size_of` is unambiguous: the name alone, without any prefix or
path, is self-explanatory and unmistakeable for any other functionality.
Adding it to the prelude cannot produce any name conflicts, as any local
definition will silently shadow the one from the prelude. Thus, we don't
need to wait for a new edition prelude to add it.
The `Input::File` and `Input::Text` cases should be very similar.
However, currently the `Input::File` case uses `catch_unwind` because,
until recently (#125815) there was a fallible version of
`new_parser_from_source_str` but only an infallible version of
`new_parser_from_file`. This difference wasn't fundamental, just an
overlooked gap in the API of `rustc_parse`.
Both of those operations are now fallible, so the `Input::File` and
`Input::Text` cases can made more similar, with no need for
`catch_unwind`. This also lets us simplify an `Option<Vec<Diag>>` to
`Vec<Diag>`.
Currently we have an awkward mix of fallible and infallible functions:
```
new_parser_from_source_str
maybe_new_parser_from_source_str
new_parser_from_file
(maybe_new_parser_from_file) // missing
(new_parser_from_source_file) // missing
maybe_new_parser_from_source_file
source_str_to_stream
maybe_source_file_to_stream
```
We could add the two missing functions, but instead this commit removes
of all the infallible ones and renames the fallible ones leaving us with
these which are all fallible:
```
new_parser_from_source_str
new_parser_from_file
new_parser_from_source_file
source_str_to_stream
source_file_to_stream
```
This requires making `unwrap_or_emit_fatal` public so callers of
formerly infallible functions can still work.
This does make some of the call sites slightly more verbose, but I think
it's worth it for the simpler API. Also, there are two `catch_unwind`
calls and one `catch_fatal_errors` call in this diff that become
removable thanks this change. (I will do that in a follow-up PR.)
The first one is out-of-date -- there are no longer functions expr,
item, stmt. And I don't know what a "HOF" is.
The second one doesn't really tell you anything.
- Convert it from a macro to a function, which is nicer.
- Rename it as `unwrap_or_emit_fatal`, which is clearer.
- Fix the comment. In particular, `panictry!` no longer exists.
- Remove the unnecessary `use` declaration.
It has a single call site.
This also means `CFG_ATTR_{GRAMMAR_HELP,NOTE_REF}` can be moved into
`parse_cfg_attr`, now that it's the only function that uses them.
And the commit removes the line break in the URL.
Lexing converts source text into a token stream. Parsing converts a
token stream into AST fragments. This commit renames several lexing
operations that have "parse" in the name. I think these names have been
subtly confusing me for years.
This is just a `s/parse/lex/` on function names, with one exception:
`parse_stream_from_source_str` becomes `source_str_to_stream`, to make
it consistent with the existing `source_file_to_stream`. The commit also
moves that function's location in the file to be just above
`source_file_to_stream`.
The commit also cleans up a few comments along the way.
Remove `tests/run-make-fulldeps/pretty-expanded`
This was an ancient regression test for #12685, caused by `-Zunpretty=expanded` crashing on certain code produced by `#[derive(RustcEncodable)]`.
Given that this test predates `//@ pretty-expanded` tests, and was tied to ancient implementation details of the pretty-printer and `#[derive(RustcEncodable)]` (which the test no longer even uses), I think we can safely delete it.
---
Spotted via #125948.
Update books
## rust-lang/book
6 commits in 85442a608426d3667f1c9458ad457b241a36b569..5228bfac8267ad24659a81b92ec5417976b5edbc
2024-05-29 20:55:49 UTC to 2024-05-27 17:22:03 UTC
- Fix typo in ch10-03 (rust-lang/book#3539)
- Backport changes to ch 9 and 10 (rust-lang/book#3946)
- infra: correctly support preprocessors for nostarch (rust-lang/book#3944)
- Use `<kbd>` instead of `<span class="keystroke">` (rust-lang/book#3945)
- infra: Fix clippy warning in remove_markup (rust-lang/book#3943)
- fix: ch10-03 - misleading use of expect on .split (rust-lang/book#3939)
## rust-lang/edition-guide
2 commits in 0c68e90acaae5a611f8f5098a3c2980de9845ab2..bbaabbe088e21a81a0d9ae6757705020d5d7b416
2024-05-24 19:07:18 UTC to 2024-05-21 22:40:52 UTC
- 2024: Document reserving `gen` keyword (rust-lang/edition-guide#300)
- 2024: Document cargo changes (rust-lang/edition-guide#301)
## rust-embedded/book
1 commits in dd962bb82865a5284f2404e5234f1e3222b9c022..b10c6acaf0f43481f6600e95d4b5013446e29f7a
2024-05-31 08:51:50 UTC to 2024-05-31 08:51:50 UTC
- Add some explanations as to why exception re-entrancy may still be an issue in a multicore-environment. (rust-embedded/book#367)
## rust-lang/reference
6 commits in e356977fceaa8591c762312d8d446769166d4b3e..6019b76f5b28938565b251bbba0bf5cc5c43d863
2024-06-03 15:58:57 UTC to 2024-05-25 18:35:54 UTC
- Add Apple `target_abi` values to the example values (rust-lang/reference#1507)
- this needs a space (rust-lang/reference#1506)
- Mention Variadics With No Fixed Parameter (rust-lang/reference#1494)
- Add "scopes" chapter. (rust-lang/reference#1040)
- update patterns.md for const pattern RFC (rust-lang/reference#1456)
- document guarantee about evaluation of associated consts and const blocks (rust-lang/reference#1497)
## rust-lang/rust-by-example
3 commits in 20482893d1a502df72f76762c97aed88854cdf81..4840dca06cadf48b305d3ce0aeafde7f80933f80
2024-05-28 13:56:12 UTC to 2024-05-27 11:51:10 UTC
- Update mdbook-i18n-helpers to 0.3.3 (rust-lang/rust-by-example#1857)
- Fix CI failure (rust-lang/rust-by-example#1856)
- Add precision on From/Into asymmetry to from_into.md (rust-lang/rust-by-example#1855)
## rust-lang/rustc-dev-guide
4 commits in b6d4a4940bab85cc91eec70cc2e3096dd48da62d..6a7374bd87cbac0f8be4fd4877d8186d9c313985
2024-05-31 00:27:28 UTC to 2024-05-21 09:56:12 UTC
- Flesh out the "representing types" chapter (rust-lang/rustc-dev-guide#1985)
- sync the stage0 filename (rust-lang/rustc-dev-guide#1979)
- Add Rust for Linux notification group entry (rust-lang/rustc-dev-guide#1984)
- fix some typos (rust-lang/rustc-dev-guide#1983)
Fix typo in the docs of `HashMap::raw_entry_mut`
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Ignore `vec_deque_alloc_error::test_shrink_to_unwind` test on non-unwind targets
https://github.com/rust-lang/rust/pull/123803 added this test which requires unwinding to succeed. This conditionally ignores the test on non-unwind targets (as is the case with other tests using `catch_unwind`).
Create `run-make` `env_var` and `env_var_os` helpers
As mentioned in https://github.com/rust-lang/rust/pull/125886. It's quite useful to know which environment variable failed, so better provide a helper helping with that.
r? `@jieyouxu`
Explain differences between `{Once,Lazy}{Cell,Lock}` types
The question of "which once-ish cell-ish type should I use?" has been raised multiple times, and is especially important now that we have stabilized the `LazyCell` and `LazyLock` types. The answer for the `Lazy*` types is that you would be better off using them if you want to use what is by far the most common pattern: initialize it with a single nullary function that you would call at every `get_or_init` site. For everything else there's the `Once*` types.
"For everything else" is a somewhat weak motivation, as it only describes by negation. While contrasting them is inevitable, I feel positive motivations are more understandable. For this, I now offer a distinct example that helps explain why `OnceLock` can be useful, despite `LazyLock` existing: you can do some cool stuff with it that `LazyLock` simply can't support due to its mere definition.
The pair of `std::sync::*Lock`s are usable inside a `static`, and can serve roles in async or multithreaded (or asynchronously multithreaded) programs that `*Cell`s cannot. Because of this, they received most of my attention.
Fixes#124696Fixes#125615
Convert `proc_macro_back_compat` lint to an unconditional error.
We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour.
The original "hack" implementing alternative behaviour was added in #73345.
The lint was added in #83127.
The tracking issue is #83125.
The direct motivation for the change is that providing the alternative behaviour is interfering with #125174 and follow-on work.
r? ``@estebank``
Add function `core::iter::chain`
The addition of `core::iter::zip` (#82917) set a precedent for adding plain functions for iterator adaptors. Adding `chain` makes it a little easier to `chain` two iterators.
```rust
for (x, y) in chain(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().chain(ys) {}
```
There is prior art for the utility of this in [`itertools::chain`](https://docs.rs/itertools/latest/itertools/fn.chain.html).
Approved ACP https://github.com/rust-lang/libs-team/issues/154
Update `compiler-builtins` test to not clear essential env vars
Noticed in https://github.com/rust-lang/rust/pull/122580#issuecomment-2125755689, the `compiler-builtins` test failed on Windows for a `cargo` invocation because necessary env vars `TMP` and `TEMP` were cleared by `Command::env_clear`, causing temp dir eventually used by codegen to fallback to the Windows directory, which will trigger permission errors.
This PR removes the `env_clear` on the cargo invocation.
r? `@saethlin` (feel free to reroll, since you authored the test)
try-job: x86_64-msvc
try-job: test-various
