Fix ICE in borrowck mutability suggestion with multi-byte ref sigil
Fixesrust-lang/rust#139089
Similarly to rust-lang/rust#155068, this is another instance where span arithmetic did not account for multi-byte characters. (Note that the ampersand in the test is full-width)
This change also results in correcting some inappropriate suggestions.
Fix misleading "borrowed data escapes outside of function" diagnostic
Fixesrust-lang/rust#154350
Fall back to `report_general_error()` when `fr_name_and_span` is `None` in function items, since the "escaping data" framing is only appropriate for closures capturing outside variables.
Add Sized supertrait for CoerceUnsized and DispatchFromDyn
This is part of rust-lang/rust#149094. I did not include `Receiver` because I think it is correct to allow non-sized receivers.
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#154781 (Fix attribute order implementation)
- rust-lang/rust#155242 (resolve: Introduce `(Local,Extern)Module` newtypes for local and external modules respectively)
- rust-lang/rust#149614 (Use `MaybeDangling` in `std`)
- rust-lang/rust#153178 (Add `TryFromIntError::kind` method and `IntErrorKind::NotAPowerOfTwo` variant)
- rust-lang/rust#155049 (Documenting the case of `Weak::upgrade` returning `None` when the value behind the reference is missing)
Failed merges:
- rust-lang/rust#155308 (Make `OnDuplicate::Error` the default for attributes)
Fix attribute order implementation
The implementation in https://github.com/rust-lang/rust/pull/153041 contained a mistake :c
I swapped the place where the error message was on, but did not change any code for which attribute was also selected, which explains the empty crater results.
**Interestingly, the original code is broken too, before https://github.com/rust-lang/rust/pull/153041 it always took the last attribute, regardless of what the `AttributeOrder` actually was...**
Let's first see crater results before making a decision
TODO for this PR: Make better tests for this
delegation: fix def path hash collision, add per parent disambiguators
This PR addresses the following delegation issues:
- It fixesrust-lang/rust#153410 when generating new `DefId`s for generic parameters by ~saving `DisambiguatorState`s from resolve stage and using them at AST -> HIR lowering~ introducing per owner disambiguators and transferring them to AST -> HIR lowering stage
- ~Next it fixes the ICE which is connected to using `DUMMY_SP` in delegation code, which was found during previous fix~
- ~Finally, after those fixes the rust-lang/rust#143498 is also fixed, only bugs with propagating synthetic generic params are left.~
Fixesrust-lang/rust#153410. Part of rust-lang/rust#118212.
r? @petrochenkov
changed the information provided by (mut x) to mut x (Fix 155030)
When trying to change a value without using mut in a for loop, the recommendation for this change is incorrect, so I am correcting it.
resolve: rust-lang/rust#155030
Suggest to bind `self.x` to `x` when field `x` may be in format string
Fixesrust-lang/rust#141350
I added the new test in the first commit, and committed the changes in the second one.
r? @fmease
cc @mejrs
Make `span_suggestions` always verbose
`span_suggestions` is to provide mutually exclusive suggestions. When it was introduced, we made its behavior be that if a single suggestion is given to it, we present the suggestion inline, otherwise in patch format. Changing this to make all of its uses be verbose, as that is closer in intent of output.
Handle nonnull pattern types in size skeleton
The original comment was correct, the size is always the same, but we have more information now. In theory there was an additional bug that would have allowed transmuting things of different sizes, but I don't see how that would have been actually doable as the `tail` types would always have differed.
fixesrust-lang/rust#155330
Clean up `AttributeLintKind` and refactor diagnostic attribute linting
There was a fair amount of duplication here, and thanks to the proliferation of new diagnostic attributes these days, it was threatening to grow bigger.
Emit fatal on invalid const args with nested defs
Fixed https://github.com/rust-lang/rust/issues/123629
Fixes https://github.com/rust-lang/rust/issues/154539
Invalid const args are rejected, so their surrounding HIR is not preserved. But nested defs inside them can still get created, leaving children lowered without a valid HIR parent and causing an ICE when later error handling walks HIR parents.
r? @BoxyUwU
Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32`
Currently, the following code compiles:
```rust
fn foo<T: Into<f32>>(_: T) {}
fn main() {
foo(1.0);
}
```
This is because the only `From<{float}>` impl for `f32` is currently `From<f32>`. However, once `impl From<f16> for f32` is added this is no longer the case. This would cause the float literal to fallback to `f64`, subsequently causing a type error as `f32` does not implement `From<f64>`. While this kind of change to type inference isn't technically a breaking change according to Rust's breaking change policy, the previous attempt to add `impl From<f16> for f32` was removed rust-lang/rust#123830 due to the large number of crates affected (by my count, there were root regressions in 42 crates and 52 GitHub repos, not including duplicates). This PR solves this problem by using `f32` as the fallback type for `{float}` when there is a trait predicate of `f32: From<{float}>`. This allows adding `impl From<f16> for f32` without affecting the code that currently compiles (such as the example above; this PR shouldn't affect what is possible on stable).
This PR also allows adding a future-incompatibility warning for the fallback to `f32` (currently implemented in the third commit) if the lang team wants one (allowing the `f32` fallback to be removed in the future); alternatively this could be expanded in the future into something more general like @tgross35 suggested in https://github.com/rust-lang/rust/issues/123831#issuecomment-2064728053. I think it would be also possible to disallow the `f32` fallback in a future edition.
As expected, a crater check showed [no non-spurious regressions](https://github.com/rust-lang/rust/pull/139087#issuecomment-2764732580).
For reference, I've based the implementation loosely on the existing `calculate_diverging_fallback`. This first commit adds the `f32` fallback, the second adds `impl From<f16> for f32`, and the third adds a FCW lint for the `f32` fallback. I think this falls under the types team, so
r? types
Fixes: rust-lang/rust#123831
Tracking issue: rust-lang/rust#116909
@rustbot label +T-lang +T-types +T-libs-api +F-f16_and_f128
To decide on whether a future-incompatibility warning is desired or otherwise (see above):
@rustbot label +I-lang-nominated
cc https://github.com/rust-lang/rust/issues/154024https://github.com/rust-lang/rust/issues/154005
Tests for precise-capture through RPIT and TAIT
- Tests for https://github.com/rust-lang/rust/issues/155151.
These tests succeed under `-Znext-solver`, but incorrectly fail under the old trait solver.
---
The bug can be triggered via return-position `impl Trait` on stable, but requires some rather contrived code. When using type-alias `impl Trait`, it's easier to imagine the issue being triggered by real code.
Test/lexer unicode pattern white space
This PR adds a test for the Rust lexer to verify it correctly accepts vertical tab (`\x0B`) as valid whitespace between tokens. Vertical tab is part of Unicode Pattern_White_Space, which the Rust language specification uses to define whitespace.
Related: Outreachy tracking [Pattern_White_Space](https://www.unicode.org/reports/tr31/#R3a)
explicit-tail-calls: disable two tests on LoongArch
A [recent LLVM change](https://github.com/llvm/llvm-project/pull/191508) broke these on LLVM 23.
I suspect these will eventually be fixed, so maybe it'd be okay/better to just leave this pending so it applies to our CI without merging it? I'm open to opinions.
Fix ICE when Self is used in enum discriminant of a generic enum
Fixesrust-lang/rust#153756
Let discriminant AnonConst inherit parent generics via Node::Variant in generics_of, and emit a proper error instead of span_bug! for the TooGeneric case in wfcheck.
`span_suggestions` is to provide mutually exclusive suggestions. When it was introduced, we made its behavior be that if a single suggestion is given to it, we present the suggestion inline, otherwise in patch format. Changing this to make all of its uses be verbose, as that is closer in intent of output.
Previously the lint would be reported at the right span, but could not be `allow`ed or `expect`ed in that location, because the lint was actually emitted using `CRATE_HIR_ID`
* Fix ICE when Self is used in enum discriminant of a generic enum
Move the validation into the existing `check_param_uses_if_mcg` machinery
in HIR ty lowering instead of adding a new check in wfcheck. After the
`AnonConstKind` refactoring, `ForbidMCGParamUsesFolder` was only gated on
`AnonConstKind::MCG`, causing discriminant anon consts (`NonTypeSystem`) to
bypass it entirely.
Add `anon_const_forbids_generic_params()` which returns the appropriate
`ForbidParamContext` for both MCG and enum discriminant contexts. Wire it
into `check_param_uses_if_mcg` so that `Self` aliasing a generic type is
caught before reaching `const_eval_poly`. Convert the `TooGeneric` span_bug
into a proper diagnostic as a fallback for anything slipping through
type-dependent path resolution.
* Address review comments
- Rename `ForbidMCGParamUsesFolder` to `ForbidParamUsesFolder`
- Rename `MinConstGenerics` variant to `ConstArgument` with updated doc
- Simplify doc comment on `anon_const_forbids_generic_params`
- Make match on `AnonConstKind` exhaustive
- Move `anon_const_def_id` inside the `if let` in `check_param_uses_if_mcg`
- Remove now-unreachable `TooGeneric` span_err in wfcheck
* Revert TooGeneric arm back to span_bug! as requested by reviewer
* Use generics_of to determine if NonTypeSystem anon consts allow generic params
* Also check InlineConst and Closure defs nested in enum discriminants
* Simplify logic for determining anonymous constant parent in generic contexts
* add test
coroutines: Skip the closure signature annotation check for tainted bodies
When a coroutine has too many parameters, `check_match` fails and `construct_error` builds a MIR body with only the coroutine's computed arguments (env + resume type). The user-provided signature, however, still reflects all the parameters the user wrote. `check_signature_annotation` then tries to `zip_eq` these two mismatched iterators, causing a panic. Checking `tainted_by_errors` and bailing early avoids this, since `construct_error` bodies cannot meaningfully be compared against user annotations.
Example currently ICEing:
```rust
fn main() {
|(1, 42), ()| yield;
}
```
Closesrust-lang/rust#139570.
Instead of the last segment of the delegation path.
`self` is something that introduced by the whole delegation item, not some specific part of it, and the last segment may need to have a different context for path resolution purposes.
Jacob Pratt