Error on attempt to construct scalable vector type
If you attempt to construct a scalable vector type rust will ICE.
E.g.:
```rust
#[rustc_scalable_vector(4)]
#[allow(non_camel_case_types)]
struct svint32_t(i32);
fn main() {
let foo = svint32_t(1);
// This will ICE
}
```
This PR adds a check that will emit an error if you attempt to use a SV constructor and a test to ensure it works.
Tighten the `!range` bounds on alignments in vtables
Right now we're only telling LLVM that they're non-zero, but alignments must be powers of two so can't be more than `isize::MAX+1`. And we actually never emit anything beyond LLVM's limit of 2²⁹, so outside of 16-bit targets the limit is that.
(Pulled out from rust-lang/rust#152867 which is starting to have too much in it.)
Expose Span for all DefIds in rustc_public
Part of https://github.com/rust-lang/project-stable-mir/issues/118
To be maximally useful, `VariantDef` and `FieldDef` should be changed to be a wrapper around `DefId` instead of holding their parent and index. I can do this change in this PR or a follow-up if it is desired. For now, I added the missing `impl Stable for DefId` in internals so you can convert from rustc internals.
Skip the `use_existential_projection_new_instead` field in the `Debug` impl
Resolves: rust-lang/rust#152807 .
Simply slap a `#derive_where[skip(Debug)]` on that field.
Add tests for delegation generics
This PR adds tests from rust-lang/rust#151864 as discussed in this [comment](https://github.com/rust-lang/rust/pull/151864#issuecomment-3928053049). Part of rust-lang/rust#118212.
The majority of new tests are added in `mapping` folder, (`ast-hir-engine` folder in rust-lang/rust#151864), those tests test mapping between generic params of delegee and our generated function for delegation (that is why the name of the folder was changed, I think it better reflects what those tests testing). In each mapping test comments were added to each test case and one comment describing the goal of mapping tests was added at the top of each file.
Next, tests for defaults in generic params (`generic-params-defaults.rs`), params with the same name (`generic-params-same-names`), errors in providing user-specified generic args (`generics-gen-args-errors.rs`) and wrong signature of a generated function in impl trait case (`impl-trait-wrong-args-count.rs`, renamed from `wrong-args-count-ice.rs` in rust-lang/rust#151864). `generic-aux-pass.rs` test was not added, as all reuses in this test produce known ICE `DefId::expect_local DefId(..) isn't local` rust-lang/rust#143498 (which will be fixed in rust-lang/rust#151864, however it will not close mentioned issue, as synthetic generic params are not yet supported in new generics implementation).
r? @petrochenkov
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)
As far as I can tell it was introduced to allow fat LTO with
-Clinker-plugin-lto. Later a change was made to automatically disable
ThinLTO summary generation when -Clinker-plugin-lto -Clto=fat is used,
so we can safely remove it.
Matthias Krüger