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.
NLL: Fix bug in associated constant type annotations.
Fixes#57280.
This PR reverses the variance used when relating types from the type
annotation of an associated constant - this matches the behaviour of the
lexical borrow checker and fixes a bug whereby matching a `&'a str`
against a `&'static str` would produce an error.
r? @nikomatsakis
tests: Do not use `-Z parse-only`, continue compilation to test recovery
Make tests closer to reality!
The next step will be enabling `-Z continue-parse-after-error` by default and looking at the regressions.
A few instances of `-Z parse-only` are kept when it's appropriate, see e.g `ui/impl-trait/impl-trait-plus-priority.rs`, which tests mostly semantically wrong code and would generate too much useless noise if allowed to continue.
use structured suggestion for method calls
Furthermore, don't suggest calling the method if it is part of a place
expression, as this is invalid syntax.
I'm thinking it might be worth putting a label on the method assignment span like "this is a method" and removing the span from the "methods are immutable" text so it isn't reported twice.
The suggestions in `src/test/ui/did_you_mean/issue-40396.stderr` are suboptimal. I could check if the containing expression is `BinOp`, but I'm not sure if that's general enough. Any ideas?
r? @estebank
