Support importing path-segment keyword with renaming
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/146972)*
#### Reference PR
- https://github.com/rust-lang/reference/pull/2010
- https://github.com/rust-lang/reference/pull/2136
#### Description
This PR unifies and extends the behavior of importing path-segment keywords (`crate`/`$crate`/`super`/`self`), resolving several long-standing inconsistencies.
Previously, Rust only allowed `use crate as name;` without renaming support for other path keywords. This PR enables importing these keywords with explicit renaming. And it also denies importing these keywords without renaming.
##### What's now allowed
For **`crate`** and **`$crate`**:
- `use crate as name;`
- `use crate::{self as name};`
- `use $crate as name;`
- `use $crate::{self as name};`
For **`super`** (including chained `super::super`):
- `use super as name;`
- `use super::{self as name};`
- `use super::super as name;`
- `use super::super::{self as name};`
For **`self`**:
- `use self as name;`
- `use self::{self as name};`
##### Removed error codes
Two error codes are no longer emitted:
- **E0430**: Previously emitted for duplicate `self` imports like `std::fmt::{self, self}`. The existing E0252 ("name defined multiple times") provides sufficient guidance.
- **E0431**: Previously emitted for `use {self [as name]};` and `use ::{self [as name]};`. These patterns are now allowed or denied but with new clearer errors.
- For `use {self as name};` and `use ::{self as name};` (in edition 2015), they are allowed now and equivalent to `use crate as name`;
- For `use {self};` and `use ::{self};` (in edition 2015) without renaming, they are equivalent to `use crate;`, the new clearer error suggests adding an explicit rename.
- For `use ::{self [as name]};` after edition 2015, it is equivalent to `use ${extern-prelude} [as name];`, it is denied with new errors.
##### Future
We plan to remove error [E0429](https://doc.rust-lang.org/stable/error_codes/E0429.html#error-code-e0429) and support `self` at the end of paths (https://github.com/rust-lang/rust/pull/146972#issuecomment-3719825627). This language extension and lint for redundant `::self` instead of hard error `E0429` will be landed separately in the future.
---
Fixesrust-lang/rust#29036Fixesrust-lang/rust#35612Fixesrust-lang/rust#37156Fixesrust-lang/rust#146967Fixesrust-lang/rust#149811
r? petrochenkov
Not linting irrefutable_let_patterns on let chains
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/146832)*
# Description
this PR makes the lint `irrefutable_let_patterns` not check for `let chains`,
only check for single `if let`, `while let`, and `if let guard`.
# Motivation
Since `let chains` were stabilized, the following code has become common:
```rust
fn max() -> usize { 42 }
fn main() {
if let mx = max() && mx < usize::MAX { /* */ }
}
```
This code naturally expresses "please call that function and then do something if the return value satisfies a condition".
Putting the let binding outside the if would be bad as then it remains in scope after the if, which is not the intent.
Current Output:
```bash
warning: leading irrefutable pattern in let chain
--> src/main.rs:7:8
|
7 | if let mx = max() && mx < usize::MAX {
| ^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it outside of the construct
= note: `#[warn(irrefutable_let_patterns)]` on by default
```
Another common case is progressively destructuring a struct with enum fields, or an enum with struct variants:
```rust
struct NameOfOuterStruct {
middle: NameOfMiddleEnum,
other: (),
}
enum NameOfMiddleEnum {
Inner(NameOfInnerStruct),
Other(()),
}
struct NameOfInnerStruct {
id: u32,
}
fn test(outer: NameOfOuterStruct) {
if let NameOfOuterStruct { middle, .. } = outer
&& let NameOfMiddleEnum::Inner(inner) = middle
&& let NameOfInnerStruct { id } = inner
{
/* */
}
}
```
Current Output:
```bash
warning: leading irrefutable pattern in let chain
--> src\main.rs:17:8
|
17 | if let NameOfOuterStruct { middle, .. } = outer
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it outside of the construct
= note: `#[warn(irrefutable_let_patterns)]` on by default
warning: trailing irrefutable pattern in let chain
--> src\main.rs:19:12
|
19 | && let NameOfInnerStruct { id } = inner
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it into the body
```
To avoid the warning, the readability would be much worse:
```rust
fn test(outer: NameOfOuterStruct) {
if let NameOfOuterStruct {
middle: NameOfMiddleEnum::Inner(NameOfInnerStruct { id }),
..
} = outer
{
/* */
}
}
```
# related issue
* rust-lang/rust#139369
# possible questions
1. Moving the irrefutable pattern at the head of the chain out of it would cause a variable that was intended to be temporary to remain in scope, so we remove it.
However, should we keep the check for moving the irrefutable pattern at the tail into the body?
2. Should we still lint `entire chain is made up of irrefutable let`?
---
This is my first time contributing non-documentation code to Rust. If there are any irregularities, please feel free to point them out.
: )
std::ops::ControlFlow - use normal comment for internal methods
Rather than a doc comment, which causes rustdoc to output the impl documentation even though the impl block only has non-public methods.
resolve: do not suggest `_` for unresolved imports
Fix invalid unresolved-import suggestion when a module contains an item named `_`.
`use _` is never valid syntax, so `_` should not be suggested as a similar name.
Closesrust-lang/rust#152812
Clarify some variable names in the query proc-macro
These are some cleanups to the `rustc_macros::query`, extracted from https://github.com/rust-lang/rust/pull/152833.
r? nnethercote
Rename `DepGraphQuery` to `RetainedDepGraph`
This is a revised subset of https://github.com/rust-lang/rust/pull/152836 that only performs an internal renaming, and does not touch the `-Zquery-dep-graph` flag.
The new name and comments for `RetainedDepGraph` should hopefully do a better job of communicating that it is not used in normal compiler operation, even in incremental mode.
Add bootstrap snapshot tests for {`install`, `install src`}
And `install src` with `build.docs = false`.
This is mostly to get coverage for the baseline to make it easier to review rust-lang/rust#150845.
DOC: do not link to "nightly" in Iterator::by_ref() docstring
I happened to see that the link in the docstring https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.by_ref points to the "nightly" docs instead of "stable".
I'm not sure if my fix actually works because I didn't get `cargo doc` to run on my local computer.
bootstrap: respect POSIX jobserver
When bootstrapping Rust, the `-j N` flag was passed to CMake, which was
then forwarded to Ninja. This prevents the jobserver from being used,
and as a result leads to oversubscription when Rust is just one of the
many packages built as part of a larger software stack.
Since Cargo and the Rust compiler have long supported the jobserver, it
would be good if also bootstrapping Rust itself would participate in the
protocol, leading to composable parallelism.
This change allows bootstrapping to respect an existing FIFO based
jobserver. Old pipe based jobservers are not supported, because they are
brittle: currently the Python scripts in bootstrap do not inherit the
file descriptors, but do pass on `MAKEFLAGS`, which has lead to errors
like "invalid file descriptor" in the past. Because Ninja only supports
FIFO based jobservers, it's better to focus on new jobservers only,
which shouldn't suffer from the "invalid file descriptor" issue.
In summary:
* Bootstrap Cargo passes `MAKEFLAGS` verbatim to subprocesses if it
advertises a FIFO style jobserver, otherwise it unsets it. This ensures
subprocesses respect the jobserver during bootstrap.
* `llvm.rs` does not pass `-j` to `cmake` when a FIFO style jobserver is
set in `MAKEFLAGS`. This ensures Ninja respects the jobserver.
* Bootstrap Cargo no longer unsets `MKFLAGS`: from git blame, GNU Make
considered it a historical artifact back in 1992, and it is never read
by GNU Make, it's only set for backwards compatibility in case sub-Makefiles
read it.
---
I've tested this with the [Spack package manager](https://github.com/spack/spack) starting the POSIX jobserver,
building node.js and rust in parallel with `-j16`, which looks like this:
```console
$ pstree 382710
python3─┬─python3
└─python3─┬─python3─┬─make───make───6*[ccache───g++───cc1plus]
│ └─{python3}
└─python3─┬─python3.11───bootstrap───cmake───ninja-build───10*[sh───ccache───g++───cc1plus]
└─{python3}
```
As you can see there are 10 `g++` processes running for rust, and `6` for node.js, and
with a mix of `make` and `ninja` as build tools :).
(The only violation I see now is `rust-lld`, but I think that'll be fixed with the LLVM 23
release)
Simplify `size/align_of_val<T: Sized>` to `size/align_of<T>` instead
This is relevant to things like `Box<[u8; 1024]>` where the drop looks at the `size_of_val` (since obviously it might be DST in general) but where we don't actually need to do that since it's always that same value for the `Sized` type.
(Equivalent to rust-lang/rust#152681, but flipped in the rebase so it can land before rust-lang/rust#152641 instead of depending on it.)
Perform many const checks in typeck
Some smaller diagnostic changes, the biggest ones avoided by https://github.com/rust-lang/rust/pull/148641
We should be able to move various checks in mir const checking to using `span_bug!` instead of reporting an error, just like mir typeck does as a sanity check. I would like to start doing so separately though, as this PR is a big enough (in what effects it causes, pun intended).
r? @fee1-dead
fix stale comments left over from ed3711e
Remove stale overflow comments in core::str.
Commit ed3711ea introduced stale comments in library/core/src/str/iter.rs.
Prior to that commit, the comments explained why `(len + 3)` and `(len + 2)` couldn't overflow.
Since the code now uses `div_ceil`, these specific overflow justifications are no longer relevant to the current implementation.
Update enzyme submodule to match upstream
For a while we were carying one extra commit to handle static builds on macos. That commit got upstreamed, so we can drop it (and update to a newer Enzyme while at it).
r? @Kobzol
Can I get a rollup, please?
Jonathan Brouwer