Add information to higher-ranked lifetimes conflicts error messages
Make these errors go through the new "placeholder error" code path, to have self tys displayed and make them hopefully less confusing.
Should fix#57362.
r? @nikomatsakis — so we can iterate on the specific wording you wanted.
add typo suggestion to unknown attribute error
Provides a suggestion using Levenshtein distance to suggest built-in attributes and attribute macros.
Fixes#49270.
Use pinning for generators to make trait safe
I'm unsure whether there needs to be any changes to the actual generator transform. Tests are passing so the fact that `Pin<&mut T>` is fundamentally the same as `&mut T` seems to allow it to still work, but maybe there's something subtle here that could go wrong.
This is specified in [RFC 2349 § Immovable generators](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md#immovable-generators) (although, since that RFC it has become safe to create an immovable generator, and instead it's unsafe to resume any generator; with these changes both are now safe and instead the unsafety is moved to creating a `Pin<&mut [static generator]>` which there are safe APIs for).
CC #43122
This commit extends existing suggestions to prefix unused variable
bindings in match arms with an underscore so that it applies to all
patterns in a match arm.
When mentioning lifetimes, only invert wording between the expected trait and the self type when the self type has the vid.
This way, the lifetimes always stay close to the self type or trait ref that actually contains them.
Suggest removing leading left angle brackets.
Fixes#57819.
This PR adds errors and accompanying suggestions as below:
```
bar::<<<<<T as Foo>::Output>();
^^^ help: remove extra angle brackets
```
r? @estebank
Implement optimize(size) and optimize(speed) attributes
This PR implements both `optimize(size)` and `optimize(speed)` attributes.
While the functionality itself works fine now, this PR is not yet complete: the code might be messy in places and, most importantly, the compiletest must be improved with functionality to run tests with custom optimization levels. Otherwise the new attribute cannot be tested properly. Oh, and not all of the RFC is implemented – attribute propagation is not implemented for example.
# TODO
* [x] Improve compiletest so that tests can be written;
* [x] Assign a proper error number (E9999 currently, no idea how to allocate a number properly);
* [ ] Perhaps reduce the duplication in LLVM attribute assignment code…
Rollup of 5 pull requests
Successful merges:
- #56233 (Miri and miri-related code contains repetitions of `(n << amt) >> amt`)
- #57645 (distinguish "no data" from "heterogeneous" in ABI)
- #57734 (Fix evaluating trivial drop glue in constants)
- #57886 (Add suggestion for moving type declaration before associated type bindings in generic arguments.)
- #57890 (Fix wording in diagnostics page)
Failed merges:
r? @ghost
Fix evaluating trivial drop glue in constants
```rust
struct A;
impl Drop for A {
fn drop(&mut self) {}
}
const FOO: Option<A> = None;
const BAR: () = (FOO, ()).1;
```
was erroring with
```
error: any use of this value will cause an error
--> src/lib.rs:9:1
|
9 | const BAR: () = (FOO, ()).1;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^-^
| |
| calling non-const function `std::ptr::real_drop_in_place::<(std::option::Option<A>, ())> - shim(Some((std::option::Option<A>, ())))`
|
= note: #[deny(const_err)] on by default
error: aborting due to previous error
```
before this PR. According to godbolt this last compiled successfully in 1.27
distinguish "no data" from "heterogeneous" in ABI
Ignore zero-sized types when computing whether something is a homogeneous aggregate, except be careful of VLA.
cc #56877
r? @arielb1
cc @eddyb
[NLL] Clean up handling of type annotations
* Renames (Canonical)?UserTypeAnnotation -> (Canonical)?UserType so that the name CanonicalUserTypeAnnotation is free.
* Keep the inferred type associated to user type annotations in the MIR, so that it can be compared against the annotated type, even when the annotated expression gets removed from the MIR. (#54943)
* Use the inferred type to allow infallible handling of user type projections (#57531)
* Uses revisions for the tests in #56993
* Check the types of `Unevaluated` constants with no annotations (#46702)
* Some drive-by cleanup
Closes#46702Closes#54943Closes#57531Closes#57731
cc #56993 leaving this open to track the underlying issue: we are not running tests with full NLL enabled on CI at the moment
r? @nikomatsakis
This commit extends existing suggestions to move lifetimes before types
in generic arguments to also suggest moving types behind associated type
bindings.
Print visible name for types as well as modules.
Fixes#56943 and fixes#57713.
This commit extends previous work in #55007 where the name from the
visible parent was used for modules. Now, we also print the name from
the visible parent for types.
r? @estebank
When using value after move, point at span of local
When trying to use a value after move, instead of using a note, point
at the local declaration that has a type that doesn't implement `Copy`
trait.
```
error[E0382]: use of moved value: `x`
--> $DIR/issue-34721.rs:27:9
|
LL | pub fn baz<T: Foo>(x: T) -> T {
| - - move occurs because `x` has type `T`, which does not implement the `Copy` trait
| |
| consider adding a `Copy` constraint to this type argument
LL | if 0 == 1 {
LL | bar::bar(x.zero())
| - value moved here
LL | } else {
LL | x.zero()
| - value moved here
LL | };
LL | x.zero()
| ^ value used here after move
```
Fix#34721.
Add suggestion for incorrect field syntax.
Fixes#57684.
This commit adds a suggestion when a `=` character is used when
specifying the value of a field in a struct constructor incorrectly
instead of a `:` character.
r? @estebank
Get rid of the fake stack frame for reading from constants
r? @RalfJung
fixes the ice in https://github.com/rust-lang/rust/issues/53708 but still keeps around the wrong "non-exhaustive match" error
cc @varkor
Remove quote_*! macros
This deletes a considerable amount of test cases, some of which we may want to keep. I'm not entirely certain what the primary intent of many of them was; if we should keep them I can attempt to edit each case to continue compiling without the quote_*! macros involved.
Fixes#46849.
Fixes#12265.
Fixes#12266.
Fixes#26994.
r? @Manishearth
Add intrinsic to create an integer bitmask from a vector mask
This PR adds a new simd intrinsic: `simd_bitmask(vector) -> unsigned integer` that creates an integer bitmask from a vector mask by extracting one bit of each vector lane.
This is required to implement: https://github.com/rust-lang-nursery/packed_simd/issues/166 .
EDIT: the reason we need an intrinsics for this is that we have to truncate the vector lanes to an `<i1 x N>` vector, and then bitcast that to an `iN` integer (while making sure that we only materialize `i8`, ... , `i64` - that is, no `i1`, `i2`, `i4`, types), and we can't do any of that in a Rust library.
r? @rkruppe
Add error for trailing angle brackets.
Fixes#54521.
This PR adds a error (and accompanying machine applicable
suggestion) for trailing angle brackets on function calls with a
turbofish.
r? @estebank
This commit adds a suggestion when a `=` character is used when
specifying the value of a field in a struct constructor incorrectly
instead of a `:` character.
typeck: remove leaky nested probe during trait object method resolution
addresses #57673 (but not marking with f-x because thats now afflicting beta channel).
Fix#57216
Remove unnecessary dummy span checks
The emitter already verifies wether a given span note or span label
can be emitted to the output. If it can't, because it is a dummy
span, it will be either elided for labels or emitted as an unspanned
note/help when applicable.
Add signed num::NonZeroI* types
Multiple people have asked for them in https://github.com/rust-lang/rust/issues/49137. Given that the unsigned ones already exist, they are very easy to add and not an additional maintenance burden.
This commit extends the trailing `>` detection to also work for paths
such as `Foo::<Bar>>:Baz`.
This involves making the existing check take the token that is expected
to follow the path being checked as a parameter.
Care is taken to ensure that this only happens on the construction of a
whole path segment and not a partial path segment (during recursion).
Through this enhancement, it was also observed that the ordering of
right shift token and greater than tokens was overfitted to the examples
being tested.
In practice, given a sequence of `>` characters: `>>>>>>>>>`
..then they will be split into `>>` eagerly: `>> >> >> >> >`.
..but when a `<` is prepended, then the first `>>` is split:
`<T> > >> >> >> >`
..and then when another `<` is prepended, a right shift is first again:
`Vec<<T>> >> >> >> >`
In the previous commits, a example that had two `<<` characters was
always used and therefore it was incorrectly assumed that `>>` would
always be first - but when there is a single `<`, this is not the case.
The diagnostic for this error prints `the following implementations
were found` followed by the first N relevant impls, sorted.
This commit makes the sort happen before slicing,
so that the set of impls being printed is deterministic
when the input is not.
This commit extends previous work in #55007 where the name from the
visible parent was used for modules. Now, we also print the name from
the visible parent for types.
Add "dereference boxed value" suggestion.
Contributes to #57741.
This PR adds a `help: consider dereferencing the boxed value` suggestion to discriminants of match statements when the match arms have type `T` and the discriminant has type `Box<T>`.
r? @estebank
Suggest correct cast for struct fields with shorthand syntax
```
error[E0308]: mismatched types
--> $DIR/type-mismatch-struct-field-shorthand.rs:8:19
|
LL | let _ = RGB { r, g, b };
| ^ expected f64, found f32
help: you can cast an `f32` to `f64` in a lossless way
|
LL | let _ = RGB { r: r.into(), g, b };
| ^^^^^^^^^^^
```
Fix#52497.
Continue parsing after parent type args and suggest using angle brackets
```
error[E0214]: parenthesized parameters may only be used with a trait
--> $DIR/E0214.rs:2:15
|
LL | let v: Vec(&str) = vec!["foo"];
| ^^^^^^
| |
| only traits may use parentheses
| help: use angle brackets instead: `<&str>`
```
r? @zackmdavis
Change bounds on `TryFrom` blanket impl to use `Into` instead of `From`
This is from this [comment](https://github.com/rust-lang/rust/issues/33417#issuecomment-447111156) I made.
This will expand the impls available for `TryFrom` and `TryInto`, without losing anything in the process.
The emitter already verifies wether a given span note or span label
can be emitted to the output. If it can't, because it is a dummy
span, it will be either elided for labels or emitted as an unspanned
note/help when applicable.
This commit adds a `help: consider dereferencing the boxed value`
suggestion to discriminants of match statements when the match arms have
type `T` and the discriminant has type `Box<T>`.
Attempt to recover from parse errors while parsing a struct's literal fields
by skipping tokens until a comma or the closing brace is found. This allows
errors in other fields to be reported.
make trait-aliases work across crates
This is rebase of a small part of @alexreg's PR #55994. It focuses just on the changes that integrate trait aliases properly into crate metadata, excluding the stylistic edits and the trait objects.
The stylistic edits I also rebased and can open a separate PR.
The trait object stuff I found challenging and decided it basically needed to be reimplemented. For now I've excluded it.
Since this is really @alexreg's work (I really just rebased) I am going to make it r=me once it is working.
Fixes#56488.
Fixes#57023.
Generalize `huge-enum.rs` test and expected stderr for more cross platform cases
With this change, I am able to build and test cross-platform `rustc`
In particular, I can use the following in my `config.toml`:
```
[build]
host = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
target = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
```
Before this change, my attempt to run the test suite would fail
because the error output differs depending on what your host and
targets are.
----
To be concrete, here are the actual messages one can observe:
```
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `std::option::Option<[u32; 35184372088831]>` is too big for the current architecture
error: aborting due to previous error
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `[u32; 35184372088831]` is too big for the current architecture
error: aborting due to previous error
```
To address these variations, I changed the test to be more aggressive
in its normalization strategy. We cannot (and IMO should not)
guarantee that `Option` will appear in the error output here. So I
normalized both types `Option<[u32; N]>` and `[u32; N]` to just `TYPE`
High priority resolutions for associated variants
In https://github.com/rust-lang/rust/pull/56225 variants were assigned lowest priority during name resolution to avoid crater run and potential breakage.
This PR changes the rules to give variants highest priority instead.
Some motivation:
- If variants (and their constructors) are treated as associated items, then they are obviously *inherent* associated items since they don't come from traits.
- Inherent associated items have higher priority during resolution than associated items from traits.
- The reason is that there is a way to disambiguate in favor of trait items (`<Type as Trait>::Ambiguous`), but there's no way to disambiguate in favor of inherent items, so they became unusable in case of ambiguities if they have low priority.
- It's technically problematic to fallback from associated types to anything until lazy normalization (?) is implemented.
Crater found some regressions from this change, but they are all in type positions, e.g.
```rust
fn f() -> Self::Ambiguos { ... } // Variant `Ambiguous` or associated type `Ambiguous`?
```
, so variants are not usable there right now, but they may become usable in the future if https://github.com/rust-lang/rfcs/pull/2593 is accepted.
This PR keeps code like this successfully resolving, but introduces a future-compatibility lint `ambiguous_associated_items` that recommends rewriting it as `<Self as Trait>::Ambiguous`.
Fix stack overflow when finding blanket impls
Currently, SelectionContext tries to prevent stack overflow by keeping
track of the current recursion depth. However, this depth tracking is
only used when performing normal section (which includes confirmation).
No such tracking is performed for evaluate_obligation_recursively, which
can allow a stack overflow to occur.
To fix this, this commit tracks the current predicate evaluation depth.
This is done separately from the existing obligation depth tracking:
an obligation overflow can occur across multiple calls to 'select' (e.g.
when fulfilling a trait), while a predicate evaluation overflow can only
happen as a result of a deep recursive call stack.
Fixes#56701
I've re-used `tcx.sess.recursion_limit` when checking for predication evaluation overflows. This is such a weird corner case that I don't believe it's necessary to have a separate setting controlling the maximum depth.
Fix suggestions given mulitple bad lifetimes
When given multiple lifetimes prior to type parameters in generic
parameters, do not ICE and print the correct suggestion.
r? @estebank
CC @pnkfelix
Fixes: #57521
librustc_metadata: Pass a default value when unwrapping a span
Fixes#57323.
When compiling with `static-nobundle` a-la
`rustc -l static-nobundle=nonexistent main.rs`
we now get a neat output in the form of:
```
error[E0658]: kind="static-nobundle" is feature gated (see issue #37403)
|
= help: add #![feature(static_nobundle)] to the crate attributes to enable
error: aborting due to previous error
For more information about this error, try `rustc --explain E0658`.
```
The build and tests completed successfully on my machine. Should I be adding a new test?
Better error note on unimplemented Index trait for string
fixes#56740
I've tried to compile suggestion from comments in the issue #56740, but unsure of it. So I'm open to advice :)
Current output will be like this:
```rust
error[E0277]: the type `str` cannot be indexed by `{integer}`
--> $DIR/str-idx.rs:3:17
|
LL | let c: u8 = s[4]; //~ ERROR the type `str` cannot be indexed by `{integer}`
| ^^^^ `str` cannot be indexed by `{integer}`
|
= help: the trait `std::ops::Index<{integer}>` is not implemented for `str`
= note: you can use `.chars().nth()` or `.bytes().nth()`
see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
```
`x.py test src/test/ui` succeeded and I've also tested output manually by compiling the following code:
```rust
fn _f() {
let s = std::string::String::from("hello");
let _c = s[0];
let s = std::string::String::from("hello");
let mut _c = s[0];
let s = "hello";
let _c = s[0];
let s = "hello";
let mut _c = &s[0];
}
```
Not sure if some docs should be changed too. I will also fix error message in the [Book :: Indexing into Strings](db53e2e3cd/src/ch08-02-strings.md (indexing-into-strings)) if that PR will get approved :)
Additionally, the root implementation was changed a bit: it now uses
`all` instead of coding that logic manually.
To avoid duplicate code, the inherent `[T]::is_sorted_by` method now
calls `self.iter().is_sorted_by(...)`. This should always be inlined
and not result in overhead.
Multiple people have asked for them, in
https://github.com/rust-lang/rust/issues/49137.
Given that the unsigned ones already exist,
they are very easy to add and not an additional maintenance burden.
Implement basic input validation for built-in attributes
Correct top-level shape (`#[attr]` vs `#[attr(...)]` vs `#[attr = ...]`) is enforced for built-in attributes, built-in attributes must also fit into the "meta-item" syntax (aka the "classic attribute syntax").
For some subset of attributes (found by crater run), errors are lowered to deprecation warnings.
NOTE: This PR previously included https://github.com/rust-lang/rust/pull/57367 as well.
In particular, I can use the following in my `config.toml`:
```
[build]
host = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
target = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
```
Before this change, my attempt to run the test suite would fail
because the error output differs depending on what your host and
targets are.
----
To be concrete, here are the actual messages one can observe:
```
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `std::option::Option<[u32; 35184372088831]>` is too big for the current architecture
error: aborting due to previous error
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `[u32; 35184372088831]` is too big for the current architecture
error: aborting due to previous error
```
To address these variations, I changed the test to be more aggressive
in its normalization strategy. We cannot (and IMO should not)
guarantee that `Option` will appear in the error output here. So I
normalized both types `Option<[u32; N]>` and `[u32; N]` to just `TYPE`
rustc: Remove platform intrinsics crate
This was originally attempted in #57048 but it was realized that we
could fully remove the crate via the `"unadjusted"` ABI on intrinsics.
This means that all intrinsics in stdsimd are implemented directly
against LLVM rather than using the abstraction layer provided here. That
ends up meaning that this crate is no longer used at all.
This crate developed long ago to implement the SIMD intrinsics, but we
didn't end up using it in the long run. In that case let's remove it!
forbid manually impl'ing one of an object type's marker traits
This shouldn't break compatibility for crates that do not use
`feature(optin_builtin_traits)`, because as the test shows, it is
only possible to impl a marker trait for a trait object in the crate the
marker trait is defined in, which must define
`feature(optin_builtin_traits)`.
Fixes#56934.
r? @nikomatsakis
Modify some parser diagnostics to continue evaluating beyond the parser
Continue evaluating further errors after parser errors on:
- trailing type argument attribute
- lifetime in incorrect location
- incorrect binary literal
- missing `for` in `impl Trait for Foo`
- type argument in `where` clause
- incorrect float literal
- incorrect `..` in pattern
- associated types
- incorrect discriminator value variant error
and others. All of these were found by making `continue-parse-after-error` `true` by default to identify errors that would need few changes. There are now only a handful of errors that have any change with `continue-parse-after-error` enabled.
These changes make it so `rust` _won't_ stop evaluation after finishing parsing, enabling type checking errors to be displayed on the existing code without having to fix the parse errors.
Each commit has an individual diagnostic change with their corresponding tests.
CC #48724.
This was originally attempted in #57048 but it was realized that we
could fully remove the crate via the `"unadjusted"` ABI on intrinsics.
This means that all intrinsics in stdsimd are implemented directly
against LLVM rather than using the abstraction layer provided here. That
ends up meaning that this crate is no longer used at all.
This crate developed long ago to implement the SIMD intrinsics, but we
didn't end up using it in the long run. In that case let's remove it!
Stabilize cfg_target_vendor
This stabilizes the use of `cfg(target_vendor = "...")` and removes the corresponding `cfg_target_vendor` feature. Other unstable cfgs remain behind their existing feature gates.
This functionality was added back in 2015 in #28612 to complete the coverage of target tuples (`<arch><sub>-<vendor>-<os>-<env>`). [RFC 131](https://github.com/rust-lang/rfcs/blob/master/text/0131-target-specification.md) governs the target specification, not including `target_vendor` seems to have just been an oversight. `target_os`, `target_family`, and `target_arch` are stable as of 1.0.0. `target_env` was also not mentioned in RFC 131, was added in #24777, never behind a feature_gate, and insta-stable at 1.1.0.
The functionality is tested in [test/run-pass/cfg/cfg-target-vendor.rs](https://github.com/rust-lang/rust/blob/master/src/test/run-pass/cfg/cfg-target-vendor.rs).
Closes#29718
Stabilize core::convert::identity
r? @SimonSapin
fixes https://github.com/rust-lang/rust/issues/53500
This is waiting for FCP to complete but in the interim it would be good to review.
Use structured suggestions for nonstandard style lints
This PR modifies the lints in the nonstandard_style group to use structured suggestions. Note that there's a bit of tricky span calculation going on for the `crate_name` attribute. It also simplifies the code a bit: I don't think the "fallback" suggestions for these lints can actually be triggered.
Fixes#48103.
Fixes#52414.
Rollup of 4 pull requests
Successful merges:
- #56874 (Simplify foreign type rendering.)
- #57113 (Move diagnostics out from QueryJob and optimize for the case with no diagnostics)
- #57366 (Point at match discriminant on type error in match arm pattern)
- #57538 (librustc_mir: Fix ICE with slice patterns)
Failed merges:
- #57381 (Tweak output of type mismatch between "then" and `else` `if` arms)
r? @ghost
librustc_mir: Fix ICE with slice patterns
If a match arm does not include all fields in a structure and a later
pattern includes a field that is an array, we will attempt to use the
array type from the prior arm. When calculating the field type, treat
a array of an unknown size as a `TyErr`.
Fixes: #57472
Point at match discriminant on type error in match arm pattern
```
error[E0308]: mismatched types
--> src/main.rs:5:9
|
4 | let temp: usize = match a + b {
| ----- this expression has type `usize`
5 | Ok(num) => num,
| ^^^^^^^ expected usize, found enum `std::result::Result`
|
= note: expected type `usize`
found type `std::result::Result<_, _>`
```
Fix#57279.
This shouldn't break compatibility for crates that do not use
`feature(optin_builtin_traits)`, because as the test shows, it is
only possible to impl a marker trait for a trait object in the crate the
marker trait is defined in, which must define
`feature(optin_builtin_traits)`.
Fixes#56934
NLL: Add union justifications to conflicting borrows.
Fixes#57100.
This PR adds justifications to error messages for conflicting borrows of union fields.
Where previously an error message would say ``cannot borrow `u.b` as mutable..``, it now says ``cannot borrow `u` (via `u.b`) as mutable..``.
r? @pnkfelix
If a match arm does not include all fields in a structure and a later
pattern includes a field that is an array, we will attempt to use the
array type from the prior arm. When calculating the field type, treat
a array of an unknown size as a TyErr.
Update the const fn tracking issue to the new metabug
The new `const fn` tracking issue is #57563. We don't want to point to a closed issue in the diagnostics (or FIXMEs), so these have been updated (from the old issue, #24111).
r? @Centril
...while still keeping ambiguity errors future-proofing for uniform paths.
This corner case is not going to be stabilized for 1.32 and needs some more general experiments about retrofitting 2018 import rules to 2015 edition
Rollup of 26 pull requests
Successful merges:
- #56425 (Redo the docs for Vec::set_len)
- #56906 (Issue #56905)
- #57042 (Don't call `FieldPlacement::count` when count is too large)
- #57175 (Stabilize `let` bindings and destructuring in constants and const fn)
- #57192 (Change std::error::Error trait documentation to talk about `source` instead of `cause`)
- #57296 (Fixed the link to the ? operator)
- #57368 (Use CMAKE_{C,CXX}_COMPILER_LAUNCHER for ccache)
- #57400 (Rustdoc: update Source Serif Pro and replace Heuristica italic)
- #57417 (rustdoc: use text-based doctest parsing if a macro is wrapping main)
- #57433 (Add link destination for `read-ownership`)
- #57434 (Remove `CrateNum::Invalid`.)
- #57441 (Supporting backtrace for x86_64-fortanix-unknown-sgx.)
- #57450 (actually take a slice in this example)
- #57459 (Reference tracking issue for inherent associated types in diagnostic)
- #57463 (docs: Fix some 'second-edition' links)
- #57466 (Remove outdated comment)
- #57493 (use structured suggestion when casting a reference)
- #57498 (make note of one more normalization that Paths do)
- #57499 (note that FromStr does not work for borrowed types)
- #57505 (Remove submodule step from README)
- #57510 (Add a profiles section to the manifest)
- #57511 (Fix undefined behavior)
- #57519 (Correct RELEASES.md for 1.32.0)
- #57522 (don't unwrap unexpected tokens in `format!`)
- #57530 (Fixing a typographical error.)
- #57535 (Stabilise irrefutable if-let and while-let patterns)
Failed merges:
r? @ghost
Reference tracking issue for inherent associated types in diagnostic
This makes it clearer that associated types in inherent impls are an intended feature, like the diagnostic for equality constraints in where clauses. (This is more helpful, because the lack of associated types is a confusing omission and it lets users more easily track the state of the feature.)
Stabilize `let` bindings and destructuring in constants and const fn
r? @Centril
This PR stabilizes the following features in constants and `const` functions:
* irrefutable destructuring patterns (e.g. `const fn foo((x, y): (u8, u8)) { ... }`)
* `let` bindings (e.g. `let x = 1;`)
* mutable `let` bindings (e.g. `let mut x = 1;`)
* assignment (e.g. `x = y`) and assignment operator (e.g. `x += y`) expressions, even where the assignment target is a projection (e.g. a struct field or index operation like `x[3] = 42`)
* expression statements (e.g. `3;`)
This PR does explicitly *not* stabilize:
* mutable references (i.e. `&mut T`)
* dereferencing mutable references
* refutable patterns (e.g. `Some(x)`)
* operations on `UnsafeCell` types (as that would need raw pointers and mutable references and such, not because it is explicitly forbidden. We can't explicitly forbid it as such values are OK as long as they aren't mutated.)
* We are not stabilizing `let` bindings in constants that use `&&` and `||` short circuiting operations. These are treated as `&` and `|` inside `const` and `static` items right now. If we stopped treating them as `&` and `|` after stabilizing `let` bindings, we'd break code like `let mut x = false; false && { x = true; false };`. So to use `let` bindings in constants you need to change `&&` and `||` to `&` and `|` respectively.
