Emit a wrap expr span_bug only if context is not tainted
Fixes#127332
The ICE occurs because of this `span_bug`: 51917e2e69/compiler/rustc_hir_typeck/src/expr_use_visitor.rs (L732-L738)
which is triggered by the fact that we're trying to use an `enum` in a `with` expression instead of a `struct`.
The issue originates in commit 814bfe9335 from PR #127202. As per the title of that commit the ICEing code should not be reachable any more, but looks like it still is.
This PR changes the code so that the `span_bug` will be emitted only if the context is not tainted by a previous error.
Don't try to label `ObligationCauseCode::CompareImplItem` for an RPITIT, since it has no name
The old (current) trait solver has a limitation that when a where clause in param-env must be normalized using the same where clause, then we get spurious errors in `normalize_param_env_or_error`. I don't think there's an issue tracking it, but it's the root cause for many of the "fixed-by-next-solver" labeled issues.
Specifically, these errors may occur when checking predicate entailment of the GAT that comes out of desugaring RPITITs. Since we use `ObligationCauseCode::CompareImplItem` for these predicates, we try calling `item_name` on an RPITIT which fails, since the RPITIT has no name.
We simply suppress this logic when we're reporting a predicate entailment error for an RPITIT. RPITITs should never have predicate entailment errors, *by construction*, but they may due to this bug in the old solver.
Addresses the ICE in #127331, though doesn't fix the underlying issue (which is fundamental to the old solver).
r? types
offset_from, offset: clearly separate safety requirements the user needs to prove from corollaries that automatically follow
By landing https://github.com/rust-lang/rust/pull/116675 we decided that objects larger than `isize::MAX` cannot exist in the address space of a Rust program, which lets us simplify these rules.
For `offset_from`, we can even state that the *absolute* distance fits into an `isize`, and therefore exclude `isize::MIN`. This PR also changes Miri to treat an `isize::MIN` difference like the other isize-overflowing cases.
Match ergonomics 2024: align with RFC again
- `&` matches `&mut` on old editions
- Add some more tests
r? ``@Nadrieril``
cc https://github.com/rust-lang/rust/issues/123076
``@rustbot`` label A-edition-2024 A-patterns
Add `new_range_api` for RFC 3550
Initial implementation for #125687
This includes a `From<legacy::RangeInclusive> for RangeInclusive` impl for convenience, instead of the `TryFrom` impl from the RFC. Having `From` is highly convenient and the debug assert should find almost all misuses.
This includes re-exports of all existing `Range` types under `core::range`, plus the range-related traits (`RangeBounds`, `Step`, `OneSidedRange`) and the `Bound` enum.
Currently the iterators are just wrappers around the old range types.
Tracking issues:
- https://github.com/rust-lang/rust/issues/123741
- https://github.com/rust-lang/rust/issues/125687
Improve dead code analysis
Fixes#120770
1. check impl items later if self ty is private although the trait method is public, cause we must use the ty firstly if it's private
2. mark the adt live if it appears in pattern, like generic argument, this implies the use of the adt
3. based on the above, we can handle the case that private adts impl Default, so that we don't need adding rustc_trivial_field_reads on Default, and the logic in should_ignore_item
r? ``@pnkfelix``
This includes a `From<legacy::RangeInclusive> for RangeInclusive` impl for convenience, instead of the `TryFrom` impl from the RFC.
Having `From` is highly convenient and the assertion is unlikely to be a problem in practice.
This includes re-exports of all existing `Range` types under `core::range`, plus the range-related traits (`RangeBounds`, `Step`, `OneSidedRange`) and the `Bound` enum.
Currently the iterators are just wrappers around the old range types,
and most other trait impls delegate to the old rage types as well.
Also includes an `.iter()` shorthand for `.clone().into_iter()`
Match ergonomics 2024: Implement TC's match ergonomics proposal
Under gate `ref_pat_eat_one_layer_2024_structural`. Enabling `ref_pat_eat_one_layer_2024` at the same time allows the union of what the individual gates allow. `@traviscross`
r? `@Nadrieril`
cc https://github.com/rust-lang/rust/issues/123076
`@rustbot` label A-edition-2024 A-patterns
Remove a use of `StructuredDiag`, which is incompatible with automatic error tainting and error translations
fixes#127219
I want to remove all of `StructuredDiag`, but it's a bit more involved as it is also used from the `ItemCtxt`, which doesn't support tainting yet.
Tweak some structured suggestions to be more verbose and accurate
Addressing some issues I found while working on #127282.
```
error: this URL is not a hyperlink
--> $DIR/auxiliary/include-str-bare-urls.md:1:11
|
LL | HEADS UP! https://example.com MUST SHOW UP IN THE STDERR FILE!
| ^^^^^^^^^^^^^^^^^^^
|
= note: bare URLs are not automatically turned into clickable links
note: the lint level is defined here
--> $DIR/include-str-bare-urls.rs:14:9
|
LL | #![deny(rustdoc::bare_urls)]
| ^^^^^^^^^^^^^^^^^^
help: use an automatic link instead
|
LL | HEADS UP! <https://example.com> MUST SHOW UP IN THE STDERR FILE!
| + +
```
```
error[E0384]: cannot assign twice to immutable variable `v`
--> $DIR/assign-imm-local-twice.rs:7:5
|
LL | v = 1;
| ----- first assignment to `v`
LL | println!("v={}", v);
LL | v = 2;
| ^^^^^ cannot assign twice to immutable variable
|
help: consider making this binding mutable
|
LL | let mut v: isize;
| +++
```
```
error[E0393]: the type parameter `Rhs` must be explicitly specified
--> $DIR/issue-22560.rs:9:23
|
LL | trait Sub<Rhs=Self> {
| ------------------- type parameter `Rhs` must be specified for this
...
LL | type Test = dyn Add + Sub;
| ^^^
|
= note: because of the default `Self` reference, type parameters must be specified on object types
help: set the type parameter to the desired type
|
LL | type Test = dyn Add + Sub<Rhs>;
| +++++
```
```
error[E0596]: cannot borrow `v` as mutable, as it is not declared as mutable
--> $DIR/issue-33819.rs:4:34
|
LL | Some(ref v) => { let a = &mut v; },
| ^^^^^^ cannot borrow as mutable
|
help: try removing `&mut` here
|
LL - Some(ref v) => { let a = &mut v; },
LL + Some(ref v) => { let a = v; },
|
```
```
help: remove the invocation before committing it to a version control system
|
LL - dbg!();
|
```
```
error[E0308]: mismatched types
--> $DIR/issue-39974.rs:1:21
|
LL | const LENGTH: f64 = 2;
| ^ expected `f64`, found integer
|
help: use a float literal
|
LL | const LENGTH: f64 = 2.0;
| ++
```
```
error[E0529]: expected an array or slice, found `Vec<i32>`
--> $DIR/match-ergonomics.rs:8:9
|
LL | [&v] => {},
| ^^^^ pattern cannot match with input type `Vec<i32>`
|
help: consider slicing here
|
LL | match x[..] {
| ++++
```
```
error[E0609]: no field `0` on type `[u32; 1]`
--> $DIR/parenthesized-deref-suggestion.rs:10:21
|
LL | (x as [u32; 1]).0;
| ^ unknown field
|
help: instead of using tuple indexing, use array indexing
|
LL | (x as [u32; 1])[0];
| ~ +
```
Reject SmartPointer constructions not serving the purpose
Tracking issue: #123430
With this PR we will reject a row of malformed `SmartPointer` implementor candidates.
cc `@Darksonn` `@davidtwco` for context.
Disable dead variant removal for `#[repr(C)]` enums.
This prevents removing dead branches from a `#[repr(C)]` enum (they now get discriminants allocated as if they were inhabited).
Implementation notes: ABI of something like
```rust
#[repr(C)]
enum Foo {
Foo(!),
}
```
is still `Uninhabited`, but its layout is now computed as if all the branches were inhabited.
This seemed to me like a proper way to do it, especially given that ABI sanity check explicitly asserts that type-level uninhabitedness implies ABI uninhabitedness.
This probably needs some sort of FCP (given that it changes `#[repr(C)]` layout, which is a stable guarantee), but I’m not sure how to call for one or which team is the most relevant.
See https://github.com/rust-lang/unsafe-code-guidelines/issues/500.
Rollup of 6 pull requests
Successful merges:
- #127092 (Change return-type-notation to use `(..)`)
- #127184 (More refactorings to rustc_interface)
- #127190 (Update LLVM submodule)
- #127253 (Fix incorrect suggestion for extra argument with a type error)
- #127280 (Disable rmake test rustdoc-io-error on riscv64gc-gnu)
- #127294 (Less magic number for corountine)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix incorrect suggestion for extra argument with a type error
Fixes#126246
I tried to fix it in the `find_errors` of ArgMatrix, but seems it's hard to avoid breaking some other test cases.
The root cause is we eliminate the first argument even with a type error at here:
6292b2af62/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs (L664)
So the left argument is always treated as extra one.
But if there is already a type error, an error message will be generated firstly, which make this issue a trivial one.
Add parse fail test using safe trait/impl trait
Added 2 more tests to be sure that nothing weird happens using `safe` on items.
Needed to do this in separate tests as they give parsing errors.
