Do not consider traits that have unsatisfied const conditions to be conditionally const
This will improve error messages as we continue to constify traits, since we don't want to start calling things "conditionally const" if they aren't implemented with a const impl anyways.
The only case that this affects today is `Deref` since that's one of the only constified traits in the standard library :)
r? RalfJung
Enforce syntactical stability of const traits in HIR
This PR enforces what I'm calling *syntactical* const stability of traits. In other words, it enforces the ability to name `~const`/`const` traits in trait bounds in various syntax positions in HIR (including in the trait of an impl header). This functionality is analogous to the *regular* item stability checker, which is concerned with making sure that you cannot refer to unstable items by name, and is implemented as an extension of that pass.
This is separate from enforcing the *recursive* const stability of const trait methods, which is implemented in MIR and runs on MIR bodies. That will require adding a new `NonConstOp` to the const checker and probably adjusting some logic to deduplicate redundant errors.
However, this check is separate and necessary for making sure that users don't add `~const`/`const` bounds to items when the trait is not const-stable in the first place. I chose to separate enforcing recursive const stability out of this PR to make it easier to review. I'll probably open a follow-up following this one, blocked on this PR.
r? `@RalfJung` cc `@rust-lang/project-const-traits`
Make sure we can produce `ConstArgHasWrongType` errors for valtree consts
I forgot about `ty::ConstKind::Value` in #134771.
The error message here could use some work -- both in the new trait solver and the old trait solver. But unrelated to the issue here.
Fixes https://github.com/rust-lang/rust/issues/135361 -- this was only ICEing in coherence because coherence uses the new trait solver, but I don't think the minimization is worth committing compared to the test I added.
r? ```@lcnr``` or ```@BoxyUwU```
re-add --disable-minification to rustdoc
this also makes the rust.docs-minification option work as advertised in config.toml
nothing fancy this time, this is intended to be perma-unstable. it's only really here for the benefit of rustdoc devs.
mitegates https://github.com/rust-lang/rust/issues/135345
It was removed in f9e1f6ffdf.
Improve `DispatchFromDyn` and `CoerceUnsized` impl validation
* Disallow arbitrary 1-ZST fields in `DispatchFromDyn` -- only `PhantomData`, and 1-ZSTs that mention no params (which is needed to support, e.g., the `Global` alloctor in `Box<T, U = Global>`).
* Don't allow coercing between non-ZSTs to ZSTs (since the previous check wasn't actually checking the field tys were the same before checking the layout...)
* Normalize the field before checking it's `PhantomData`.
Fixes#135215Fixes#135214Fixes#135220
r? ```@BoxyUwU``` or reassign
Make sure to scrape region constraints from deeply normalizing type outlives assumptions in borrowck
Otherwise we're just randomly registering these region relations into the infcx which isn't good
r? lcnr
Rollup of 7 pull requests
Successful merges:
- #134216 (Enable "jump to def" feature on patterns)
- #134880 (Made `Path::name` only have item name rather than full name)
- #135466 (Leak check in `impossible_predicates` to avoid monomorphizing impossible instances)
- #135476 (Remove remnant of asmjs)
- #135479 (mir borrowck: cleanup late-bound region handling)
- #135493 (Fix legacy symbol mangling of closures)
- #135495 (Add missing closing backtick in commit hook message 🐸)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix legacy symbol mangling of closures
When this code was written, there was no `type_of` implementation for closures. That has long since been changed.
In the UI test:
```
trait A where
[(); (|| {}, 1).1]: Sized,
{
}
```
We tried to walk up the def path tree for the closure, from closure -> anon const -> trait. When we reached the trait, we tried to call `type_of` on it which obviously doesn't do the right thing and ICEs.
Fixes#135418
Made `Path::name` only have item name rather than full name
Closes#134853
This PR makes `Path::name` to only have item name rather than full name, i.e. with the following code
```rust
pub mod foo {
pub struct Bar;
}
pub fn get_bar() -> foo::Bar {
foo::Bar
}
```
and running `./rustdoc ./demo.rs -wjson -Zunstable-options` gives:
```json
{
"41": {
"id": 41,
"name": "get_bar",
"inner": {
"function": {
"sig": {
"inputs": [],
"output": {
"resolved_path": {
"name": "Bar",
"id": 0,
"args": { "angle_bracketed": { "args": [], "constraints": [] }
}
}
}
}
}
}
}
}
```
_Information which isn't useful here was trimmed_
r? aDotInTheVoid
Enable "jump to def" feature on patterns
Part of https://github.com/rust-lang/rust/issues/89095.
Pattern (as in "patterns in pattern matching") were not handled by the feature, it's now added.
It all started when I realized that prelude values like `Some` or `Err` were not getting a link generated either (added support for it in the first commit).
r? ``@fmease``
Eagerly mono drop for structs with lifetimes
That is, use `!generics.requires_monomorphization()` rather than `generics.is_empty()` like the rest of the mono collector code.
Exclude dependencies of `std` for diagnostics
Currently crates in the sysroot can show up in diagnostic suggestions, such as in https://github.com/rust-lang/rust/issues/135232. To prevent this, duplicate `all_traits` into `visible_traits` which only shows traits in non-private crates.
Setting `#![feature(rustc_private)]` overrides this and makes items in private crates visible as well, since `rustc_private` enables use of `std`'s private dependencies.
This may be reviewed per-commit.
Fixes: https://github.com/rust-lang/rust/issues/135232
In order to avoid diagnostics suggesting stdlib-private dependencies,
make everything that is a direct dependency of any `std` crates private
by default. Note that this will be overridden, if the same crate is
public elsewhere in the crate graph then that overrides the private
default.
It may also be feasible to do this in the library crate, marking `std`'s
dependencies private via Cargo. However, given that the feature is still
rather unstable, doing this within the compiler seems more
straightforward.
Fixes: https://github.com/rust-lang/rust/issues/135232 [1]
fix ICE with references to infinite structs in consts
fixes https://github.com/rust-lang/rust/issues/114484
Normalizing `<Type as Pointee>::Metadata` may emit a (non-fatal) error during trait selection if finding the struct tail of `Type` hits the recursion limit. When this happens, prior this PR, we would treat the projection as rigid, i.e. don't normalize it further. This PR changes it so that we normalize to `ty::Error` instead.
This is important, because to compute the layout of `&Type` we need to compute the layout of `<Type as Pointee>::Metadata`
2ae9916816/compiler/rustc_ty_utils/src/layout.rs (L247-L273)
and computing the layout of a rigid alias will (correctly) fail and needs to report an error to the user. For example:
```rust
trait Project {
type Assoc;
}
fn foo<T: Project>() {
[(); {
let _: Option<T::Assoc> = None;
// ^^^^^^^^ this projection is rigid, so we can't know it's layout
0
}];
}
```
```
error: constant expression depends on a generic parameter
--> src/lib.rs:6:10
|
6 | [(); {
| __________^
7 | | let _: Option<T::Assoc> = None;
8 | | // ^^^^^^^^ this projection is rigid, so we can't know it's layout
9 | | 0
10 | | }];
| |_____^
|
= note: this may fail depending on what value the parameter takes
```
For non-generic rigid projections we will currently ICE, because we incorrectly assume that `LayoutError::Unknown` means that a const must be generic (https://github.com/rust-lang/rust/issues/135138). This is being fixed and turned into a proper error in https://github.com/rust-lang/rust/pull/135158.
```rust
#![feature(trivial_bounds)]
trait Project {
type Assoc;
}
fn foo()
where
u8: Project,
{
[(); {
let _: Option<<u8 as Project>::Assoc> = None; // ICEs currently, but will be an error
0
}];
}
```
However, if we hit the recursion limit when normalizing `<Type as Pointee>::Metadata` we don't want to report a layout error, because we already emitted the recursion error. So by normalizing to `ty::Error` here, we get a `LayoutError::ReferencesError` instead of a `LayoutError::Unknown` and don't report the layout error to the user.
llvm: Allow sized-word rather than ymmword in tests
llvm/llvm-project#122530 changes LLVM to use sized-word rather than ymmword for scatter gather pointers. While this will not always be qword, it is for these two tests.
`@rustbot` label: +llvm-main
Make sure to mark `IMPL_TRAIT_REDUNDANT_CAPTURES` as `Allow` in edition 2024
I never got sign-off on #127672 for this lint being warn by default in edition 2024, so let's turn downgrade this lint to allow for now.
Should be backported so it ships with the edition.
```@rustbot``` label: +beta-nominated
Re-added regression test for #122638
Re-adds the test for #122638😄fixes#122638
r? `@BoxyUwU`
(please let me know if this can be improved. I am still fairly new to using compiletest)
Detect `mut arg: &Ty` meant to be `arg: &mut Ty` and provide structured suggestion
When a newcomer attempts to use an "out parameter" using borrows, they sometimes get confused and instead of mutating the borrow they try to mutate the function-local binding instead. This leads to either type errors (due to assigning an owned value to a mutable binding of reference type) or a multitude of lifetime errors and unused binding warnings.
This change adds a suggestion to the type error
```
error[E0308]: mismatched types
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:6:14
|
LL | fn change_object(mut object: &Object) {
| ------- expected due to this parameter type
LL | let object2 = Object;
LL | object = object2;
| ^^^^^^^ expected `&Object`, found `Object`
|
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object(object: &mut Object) {
LL | let object2 = Object;
LL ~ *object = object2;
|
```
and to the unused assignment lint
```
error: value assigned to `object` is never read
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:11:5
|
LL | object = &object2;
| ^^^^^^
|
note: the lint level is defined here
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:1:9
|
LL | #![deny(unused_assignments, unused_variables)]
| ^^^^^^^^^^^^^^^^^^
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object2(object: &mut Object) {
LL | let object2 = Object;
LL ~ *object = object2;
|
```
Fix#112357.
Fix cycle error only occurring with -Zdump-mir
fixes#134205
During mir dumping, we evaluate static items to render their allocations. If a static item refers to itself, its own MIR will have a reference to itself, so during mir dumping we end up evaluating the static again, causing us to try to build MIR again (mir dumping happens during MIR building).
Thus I disabled evaluation of statics during MIR dumps in case the MIR body isn't far enough along yet to be able to be guaranteed cycle free.
llvm/llvm-project#122530 changes LLVM to use sized-word rather than
ymmword for scatter gather pointers. While this will not always be
qword, it is for these two tests.
A clone-like function in a function that takes as an argument the type
that it returns.
However, functions that return a type variable are not counted as
clone-line. Because we're not unifying the whole function at once,
a function like `U -> T` would otherwise be counted as "clone-like"
because the generics will just unify with anything when done seperatly.
Co-authored-by: Michael Howell <michael@notriddle.com>
Add and improve debuginfo tests for Windows
Adds new test for closures and function pointers.
Improves robustness of existing tests by sorting wildcard matched outputs.
try-job: i686-msvc
Assert that `Instance::try_resolve` is only used on body-like things
`Instance::resolve` is not set up to resolve items that are not body-like things. The logic in `resolve_associated_item` very much encodes this assumption:
e7ad3ae331/compiler/rustc_ty_utils/src/instance.rs (L96-L386)
However, some diagnostics were using `Instance::resolve` on an associated type, and it was simply a lucky coicidence that nothing went wrong.
This PR adds an assertion to make sure we won't do this again in the future, and fixes two callsites:
1. `call_kind` which returns a `CallKind` enum to categorize what a call in MIR comes from, and was using `Instance::resolve` to point at the associated type `Deref::Target` for a specific self ty.
2. `MirBorrowckCtxt::explain_deref_coercion`, which was doing the same thing.
The logic was replaced with `specialization_graph::assoc_def`, which is the proper way of fetching the right `AssocItem` for a given impl.
r? `@lcnr` or re-roll :)
fix handling of ZST in win64 ABI on windows-msvc targets
The Microsoft calling conventions do not really say anything about ZST since they do not seem to exist in MSVC. However, both GCC and clang allow passing ZST over `__attribute__((ms_abi))` functions (which matches our `extern "win64" fn`) on `windows-gnu` targets, and therefore implicitly define a de-facto ABI for these types (and lucky enough they seem to define the same ABI). This ABI should be the same for windows-msvc and windows-gnu targets, so we use this as a hint for how to implement this ABI everywhere: we always pass ZST by-ref.
The best alternative would be to just reject compiling functions which cannot exist in MSVC, but that would be a breaking change.
Cc `@programmerjake` `@ChrisDenton`
Fixes https://github.com/rust-lang/rust/issues/132893
Depth limit const eval query
Currently the const-eval query doesn't have a recursion limit or timeout, causing the complier to freeze in an infinite loop, see #125718. This PR depth limits the `eval_to_const_value_raw` query (with the [`recursion_limit`](https://doc.rust-lang.org/reference/attributes/limits.html) attribute) and improves the diagnostics for query overflow errors, so spans are reported for other dep kinds than `layout_of` (e.g. `eval_to_const_value_raw`).
fixes#125718fixes#114192
This was a test for `ref_pat_eat_one_layer_2024` downgrading a `mut ref`
default binding mode to `ref` within a shared reference pattern (i.e.
Rule 3) on edition 2021 specifically. Since it's near-identical to
another existing test (currently in `ref_pat_eat_one_layer_2021.rs` in
the "experimental" rfc 3627 subdirectory) and that particular feature
gate's typing rulesets are planned to no longer have Rule 3, I'm opting
to remove it rather than continue maintaining it separately.
Remove some empty expected files to fix blessing
https://github.com/rust-lang/rust/pull/134808 made --bless remove empty
expected files. Remove some empty files that were causing noise in
unrelated `--bless` invocations.
rustdoc-json: Include items in stripped modules in `Crate::paths`.
Closes#135309
When we're running rustdoc-json, we should err on the side of adding more items to `Cache::paths`, as that directly becomes `Crate::paths` in the output.
r? ``@GuillaumeGomez.`` Best reviewed commit-by-commit.
Rollup of 6 pull requests
Successful merges:
- #129259 (Add inherent versions of MaybeUninit methods for slices)
- #135374 (Suggest typo fix when trait path expression is typo'ed)
- #135377 (Make MIR cleanup for functions with impossible predicates into a real MIR pass)
- #135378 (Remove a bunch of diagnostic stashing that doesn't do anything)
- #135397 (compiletest: add erroneous variant to `string_enum`s conversions error)
- #135398 (add more crash tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove a bunch of diagnostic stashing that doesn't do anything
#121669 removed a bunch of conditional diagnostic stashing/canceling, but left around the `steal` calls which just emitted the error eagerly instead of canceling the diagnostic. I think that these no-op `steal` calls don't do much and are confusing to encounter, so let's remove them.
The net effect is:
1. We emit more duplicated errors, since stashing has the side effect of duplicating diagnostics. This is not a big deal, since outside of `-Zdeduplicate-diagnostics=no`, the errors are already being deduplicated by the compiler.
2. It changes the order of diagnostics, since we're no longer stashing and then later stealing the errors. I don't think this matters much for the changes that the UI test suite manifests, and it makes these errors less order dependent.
Make MIR cleanup for functions with impossible predicates into a real MIR pass
It's a bit jarring to see the body of a function with an impossible-to-satisfy where clause suddenly go to a single `unreachable` terminator when looking at the MIR dump output in order, and I discovered it's because we manually replace the body outside of a MIR pass.
Let's make it into a fully flegded MIR pass so it's more clear what it's doing and when it's being applied.
Suggest typo fix when trait path expression is typo'ed
When users write something like `Default::defualt()` (notice the typo), failure to resolve the erroneous `defualt` item will cause resolution + lowering to interpret this as a type-dependent path whose self type is `Default` which is a trait object without `dyn`, rather than a trait function like `<_ as Default>::default()`.
Try to provide a bit of guidance in this situation when we can detect the typo.
Fixes https://github.com/rust-lang/rust/issues/135349
Cleanup `suggest_binding_for_closure_capture_self` diag in borrowck
Mostly grammar fix/improvement, but also a small cleanup to use iterators instead of for loops for collecting into a vector.
this also makes the rust.docs-minification option work
as advertised in config.toml
nothing fancy this time, this is intended to be perma-unstable.
it's only really here for the benefit of rustdoc devs.
mitegates https://github.com/rust-lang/rust/issues/135345
Eagerly collect mono items for non-generic closures
This allows users to use `-Zprint-mono-items=eager` to eagerly monomorphize closures and coroutine bodies, in case they want to inspect the LLVM or ASM for those items.
`-Zprint-mono-items`, which used to be called `-Zprint-trans-items`, was originally added in https://github.com/rust-lang/rust/pull/30900:
> Eager mode is meant to be used in conjunction with incremental compilation
> where a stable set of translation items is more important than a minimal
> one. Thus, eager mode will instantiate drop-glue for every drop-able type
> in the crate, even of no drop call for that type exists (yet). It will
> also instantiate default implementations of trait methods, something that
> otherwise is only done on demand.
Although it remains an unstable option, its purpose has somewhat expanded since then, and as far as I can tell it's generally useful for cases when you want to monomorphize as many items as possible, even if they're unreachable. Specifically, it's useful for debugging since you can look at the codegen'd body of a function, since we don't emit items that are not reachable in monomorphization.
And even more specifically, it would be very to monomorphize the coroutine body of an async fn, since those you can't easily call those without a runtime. This PR enables this usecase since we now monomorphize `DefKind::Closure`.
Avoid ICE: Account for `for<'a>` types when checking for non-structural type in constant as pattern
When we encounter a constant in a pattern, we check if it is non-structural. If so, we check if the type implements `PartialEq`, but for types with escaping bound vars the check would be incorrect as is, so we break early. This is ok because these types would be filtered anyways.
Slight tweak to output to remove unnecessary context as a drive-by.
Fix#134764.
add `-Zmin-function-alignment`
tracking issue: https://github.com/rust-lang/rust/issues/82232
This PR adds the `-Zmin-function-alignment=<align>` flag, that specifies a minimum alignment for all* functions.
### Motivation
This feature is requested by RfL [here](https://github.com/rust-lang/rust/issues/128830):
> i.e. the equivalents of `-fmin-function-alignment` ([GCC](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fmin-function-alignment_003dn), Clang does not support it) / `-falign-functions` ([GCC](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-falign-functions), [Clang](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang1-falign-functions)).
>
> For the Linux kernel, the behavior wanted is that of GCC's `-fmin-function-alignment` and Clang's `-falign-functions`, i.e. align all functions, including cold functions.
>
> There is [`feature(fn_align)`](https://github.com/rust-lang/rust/issues/82232), but we need to do it globally.
### Behavior
The `fn_align` feature does not have an RFC. It was decided at the time that it would not be necessary, but maybe we feel differently about that now? In any case, here are the semantics of this flag:
- `-Zmin-function-alignment=<align>` specifies the minimum alignment of all* functions
- the `#[repr(align(<align>))]` attribute can be used to override the function alignment on a per-function basis: when `-Zmin-function-alignment` is specified, the attribute's value is only used when it is higher than the value passed to `-Zmin-function-alignment`.
- the target may decide to use a higher value (e.g. on x86_64 the minimum that LLVM generates is 16)
- The highest supported alignment in rust is `2^29`: I checked a bunch of targets, and they all emit the `.p2align 29` directive for targets that align functions at all (some GPU stuff does not have function alignment).
*: Only with `build-std` would the minimum alignment also be applied to `std` functions.
---
cc `@ojeda`
r? `@workingjubilee` you were active on the tracking issue
Rollup of 6 pull requests
Successful merges:
- #134074 (bootstrap: `std::io::ErrorKind::CrossesDevices` is finally stable)
- #135236 (Update a bunch of library types for MCP807)
- #135301 (re-add a warning for old master branch, but with much simpler logic)
- #135324 (Initial fs module for uefi)
- #135326 (support target specific `optimized-compiler-builtins`)
- #135347 (Use `NonNull::without_provenance` within the standard library)
r? `@ghost`
`@rustbot` modify labels: rollup
Update a bunch of library types for MCP807
This greatly reduces the number of places that actually use the `rustc_layout_scalar_valid_range_*` attributes down to just 3:
```
library/core\src\ptr\non_null.rs
68:#[rustc_layout_scalar_valid_range_start(1)]
library/core\src\num\niche_types.rs
19: #[rustc_layout_scalar_valid_range_start($low)]
20: #[rustc_layout_scalar_valid_range_end($high)]
```
Everything else -- PAL Nanoseconds, alloc's `Cap`, niched FDs, etc -- all just wrap those `niche_types` types.
r? ghost
Add an InstSimplify for repetitive array expressions
I noticed in https://github.com/rust-lang/rust/pull/135068#issuecomment-2569955426 that GVN's implementation of this same transform was quite profitable on the deep-vector benchmark. But of course GVN doesn't run in unoptimized builds, so this is my attempt to write a version of this transform that benefits the deep-vector case and is fast enough to run in InstSimplify.
The benchmark suite indicates that this is effective.
Use llvm.memset.p0i8.* to initialize all same-bytes arrays
Similar to #43488
debug builds can now handle `0x0101_u16` and other multi-byte scalars that have all the same bytes (instead of special casing just `0`)
```
error: value assigned to `object` is never read
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:11:5
|
LL | object = &object2;
| ^^^^^^
|
note: the lint level is defined here
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:1:9
|
LL | #![deny(unused_assignments, unused_variables)]
| ^^^^^^^^^^^^^^^^^^
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object2(object: &mut Object) {
LL | let object2 = Object;
LL ~ *object = object2;
|
```
This might be the first thing someone tries to write to mutate the value *behind* an argument, trying to avoid an E0308.
```
error[E0308]: mismatched types
--> $DIR/mut-arg-of-borrowed-type-meant-to-be-arg-of-mut-borrow.rs:6:14
|
LL | fn change_object(mut object: &Object) {
| ------- expected due to this parameter type
LL | let object2 = Object;
LL | object = object2;
| ^^^^^^^ expected `&Object`, found `Object`
|
help: you might have meant to mutate the pointed at value being passed in, instead of changing the reference in the local binding
|
LL ~ fn change_object(object: &mut Object) {
LL | let object2 = Object;
LL ~ *object = object2;
|
```
This might be the first thing someone tries to write to mutate the value *behind* an argument. We avoid suggesting `object = &object2;`, as that is less likely to be what was intended.
When we encounter a constant in a pattern, we check if it is non-structural. If so, we check if the type implements `PartialEq`, but for types with escaping bound vars the check would be incorrect as is, so we break early. This is ok because these types would be filtered anyways.
Fix#134764.
Adds `#[rustc_force_inline]` which is similar to always inlining but
reports an error if the inlining was not possible, and which always
attempts to inline annotated items, regardless of optimisation levels.
It can only be applied to free functions to guarantee that the MIR
inliner will be able to resolve calls.
Rollup of 7 pull requests
Successful merges:
- #132607 (Used pthread name functions returning result for FreeBSD and DragonFly)
- #134693 (proc_macro: Use `ToTokens` trait in `quote` macro)
- #134732 (Unify conditional-const error reporting with non-const error reporting)
- #135083 (Do not ICE when encountering predicates from other items in method error reporting)
- #135251 (Only treat plain literal patterns as short)
- #135320 (Fix typo in `#[coroutine]` gating error)
- #135321 (remove more redundant into() conversions)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not ICE when encountering predicates from other items in method error reporting
See the comments I left in the code and the test file.
Fixes https://github.com/rust-lang/rust/issues/124350
Unify conditional-const error reporting with non-const error reporting
This PR unifies the error reporting between `ConditionallyConstCall` and `FnCallNonConst` so that the former will refer to syntactical sugar like operators by their sugared name, rather than calling all operators "methods". We achieve this by making the "non-const" part of the error message generic over the "non" part so we can plug in "conditionally" instead.
This should ensure that as we constify traits in the standard library, we don't regress error messages for things like `==`.
r? fmease or reassign
proc_macro: Use `ToTokens` trait in `quote` macro
Tracking issues: #130977, #54722
This PR changed `proc_macro::quote!` to use `ToTokens` trait instead of `TokenStream::from`, and migrated test cases from `quote` crate.
r? `@dtolnay`
CC `@tgross35`
Remove special-casing for argument patterns in MIR typeck (attempt to fix perf regression of #133858)
See [my comment](https://github.com/rust-lang/rust/pull/133858#issuecomment-2579029618) on #133858 for more information. This is just a guess as to what went wrong, and I haven't been able to get the profiler running locally, so I'll need a perf run to make sure this actually helps.
There's one test's stderr that suffers a bit, but this was just papering over the issue anyway. Making region errors point to the correct constraints in the presence of invariance/contravariance is a broader problem; the current way it's handled is mostly based on guesswork, luck, and hoping it works out. Properly handling that (somehow) would improve the test's stderr without the hack that this PR reverts.
This greatly reduces the number of places that actually use the `rustc_layout_scalar_valid_range_*` attributes down to just 3:
```
library/core\src\ptr\non_null.rs
68:#[rustc_layout_scalar_valid_range_start(1)]
library/core\src\num\niche_types.rs
19: #[rustc_layout_scalar_valid_range_start($low)]
20: #[rustc_layout_scalar_valid_range_end($high)]
```
Everything else -- PAL Nanoseconds, alloc's `Cap`, niched FDs, etc -- all just wrap those `niche_types` types.
Make sure to walk into nested const blocks in `RegionResolutionVisitor`
Fixes https://github.com/rust-lang/rust/issues/135306
I tried auditing the rest of the visitors that called `.visit_body`, and it seems like this is the only one that was missing it. I wonder if we should modify intravisit (specifcially, that `NestedBodyFilter` stuff) to make this less likely to happen, tho...
r? oli-obk
Make `bare-fn-no-impl-fn-ptr-99875` test less dependent on path width
This sets diagnostic-width to some arbitrary number. Seems to work on my machine.
`-Zrandomize-layout` harder. `Foo<T> != Foo<U>`
Tracking issue: #106764
Previously randomize-layout only used a deterministic shuffle based on the seed stored in an Adt's ReprOptions, meaning that `Foo<T>` and `Foo<U>` were shuffled by the same seed. This change adds a similar seed to each calculated LayoutData so that a struct can be randomized both based on the layout of its fields and its per-type seed.
Primitives start with simple seed derived from some of their properties. Though some types can no longer be distinguished at that point, e.g. usize and u64 will still be treated the same.
previously field ordering was using the same seed for all instances of Foo,
now we pass seed values through the layout tree so that not only
the struct itself affects layout but also its fields
Make `lit_to_mir_constant` and `lit_to_const` infallible
My motivation for this change is just that it's annoying to check everywhere, especially since all but one call site was just ICEing on errors anyway right there.
They can still fail, but now just return an error constant instead of having the caller handle the error.
fixes#114317fixes#126182
Rollup of 5 pull requests
Successful merges:
- #135212 (Remove outdated information in the `unreachable_pub` lint description)
- #135225 (Explicitly build proc macro test with panic=unwind)
- #135242 (add missing provenance APIs on NonNull)
- #135247 (Add a list of symbols for stable standard library crates)
- #135269 (Remove some unnecessary `.into()` calls)
r? `@ghost`
`@rustbot` modify labels: rollup
Explicitly build proc macro test with panic=unwind
Fuchsia explicitly builds rust and all rust targets with `-C panic=abort` to minimize code generation size. However, when compiling a proc-macro with this setting it can cause a warning to be emitted, which breaks `tests/ui/invalid-compile-flags/crate-type-flag.rs`. This hasn't been a problem in the past for us since we compile our proc macros on host, rather than inside Fuchsia.
This attempts to fix the issue by explicitly requiring that we're using the unwinder when compiling this test to avoid the warning being emitted.
Fixes#135223
