This improves the output for issue #72577, but there's still more work
to be done.
Currently, an overflow error during monomorphization results in an error
that points at the function we were unable to monomorphize. However, we
don't point at the call that caused the monomorphization to happen. In
the overflow occurs in a large recursive function, it may be difficult
to determine where the issue is.
This commit tracks and `Span` information during collection of
`MonoItem`s, which is used when emitting an overflow error. `MonoItem`
itself is unchanged, so this only affects
`src/librustc_mir/monomorphize/collector.rs`
Upgrade Chalk
Things done in this PR:
- Upgrade Chalk to `0.11.0`
- Added compare-mode=chalk
- Bump rustc-hash in `librustc_data_structures` to `1.1.0` to match Chalk
- Removed `RustDefId` since the builtin type support is there
- Add a few more `FIXME(chalk)`s for problem spots I hit when running all tests with chalk
- Added some more implementation code for some newer builtin Chalk types (e.g. `FnDef`, `Array`)
- Lower `RegionOutlives` and `ObjectSafe` predicates
- Lower `Dyn` without the region
- Handle `Int`/`Float` `CanonicalVarKind`s
- Uncomment some Chalk tests that actually work now
- Remove the revisions in `src/test/ui/coherence/coherence-subtyping.rs` since they aren't doing anything different
r? @nikomatsakis
Add a lint to catch clashing `extern` fn declarations.
Closes#69390.
Adds lint `clashing_extern_decl` to detect when, within a single crate, an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake.
This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, we can't say that the clashing declaration is incorrect.
r? @eddyb
lint: normalize projections using opaque types
Fixes#73251.
This PR normalizes projections which use opaque types (opaque types are otherwise linted against, which is would have previously made the test cases added in this PR fail).
Projection bound validation
During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl.
However, for default values with specialization and higher-ranked bounds from GATs or otherwise, we can't normalize when checking the impl, and so we use the bound from the trait to prove that the bound applies to the impl, which is clearly unsound.
This PR makes 2 fixes for this:
1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs, so a bound `for<'a> <Self as X<'a>>::U: Copy` on the trait cannot be used to prove `<T as X<'_>>::U: Copy`.
2. Actually checking that the bounds that we still allow apply to generic/default associated types.
Opening for a crater run.
Closes#68641Closes#68642Closes#68643Closes#68644Closes#68645Closes#68656
r? @ghost
Try to suggest dereferences on trait selection failed
Fixes#39029Fixes#62530
This PR consists of two parts:
1. Decouple `Autoderef` with `FnCtxt` and move `Autoderef` to `librustc_trait_selection`.
2. Try to suggest dereferences when trait selection failed.
The first is needed because:
1. For suggesting dereferences, the struct `Autoderef` should be used. But before this PR, it is placed in `librustc_typeck`, which depends on `librustc_trait_selection`. But trait selection error emitting happens in `librustc_trait_selection`, if we want to use `Autoderef` in it, dependency loop is inevitable. So I moved the `Autoderef` to `librustc_trait_selection`.
2. Before this PR, `FnCtxt` is coupled to `Autoderef`, and `FnCtxt` only exists in `librustc_typeck`. So decoupling is needed.
After this PR, we can get suggestion like this:
```
error[E0277]: the trait bound `&Baz: Happy` is not satisfied
--> $DIR/trait-suggest-deferences-multiple.rs:34:9
|
LL | fn foo<T>(_: T) where T: Happy {}
| ----- required by this bound in `foo`
...
LL | foo(&baz);
| ^^^^
| |
| the trait `Happy` is not implemented for `&Baz`
| help: consider adding dereference here: `&***baz`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
```
r? @estebank
Properly encode AnonConst into crate metadata
Fixes#68104
Previous, we were encoding AnonConst as a regular Const, causing us to
treat them differently after being deserialized in another compilation
session.
Given `trait X { type U; }` the bound `<Self as X>::U` now lives
on the type, rather than the trait. This is feature gated on
`feature(generic_associated_types)` for now until more testing can
be done.
The also enabled type-generic associated types since we no longer
need "implies bounds".
We now require that projection candidates are applicable with the
idenitity substs of the trait, rather than allowing predicates that are
only applicable for certain substs.
This commit normalizes projections which contain opaque types (opaque types
are otherwise linted against, which is would have previously made the
test cases added in this commit fail).
Signed-off-by: David Wood <david@davidtw.co>
Unify region variables when projecting associated types
This is required to avoid cycles when evaluating auto trait predicates.
Notably, this is required to be able add Chalk types to `CtxtInterners` for `cfg(parallel_compiler)`.
r? @nikomatsakis
pretty/mir: const value enums with no variants
Fixes#72181.
This PR modifies the pretty printer and const eval in the MIR so that `destructure_const` (used in `pretty_print_const_value`) can handle enums with no variants (or types containing enums with no variants).
I'm not convinced that this is the correct approach, folks more familiar with `destructure_const` would be able to say - happy to adjust the PR. Looking through `destructure_const` and the functions that it invokes, it didn't seem like it was written to handle zero-variant-enums - I assume that case is handled earlier in some way so `destructure_const` doesn't need to under normal circumstances. It didn't seem like it would be straightforward to make `destructure_const` handle this case in a first-class-feeling way (e.g. adding a `Variants::None` variant), so this PR makes some minimal changes to avoid ICEs.
Diagnose use of incompatible sanitizers
Emit an error when incompatible sanitizer are configured through command
line options. Previously the last one configured prevailed and others
were silently ignored.
Additionally use a set to represent configured sanitizers, making it
possible to enable multiple sanitizers at once. At least in principle,
since currently all of them are considered to be incompatible with
others.
Make `need_type_info_err` more conservative
Makes sure arg patterns we are going to suggest on are actually contained within the span of the obligation that caused the inference error (credit to @lcnr for suggesting this fix).
There's a subtle trade-off regarding the handling of local patterns which I've left a comment about.
Resolves#72690
update coerce docs and unify relevant tests
Merges `test/ui/coerce` with `test/ui/coercion`.
Updates the documentation of `librustc_typeck/check/coercion.rs`.
Adds 2 new coercion tests.
Specialization is unsound
As discussed in https://github.com/rust-lang/rust/issues/31844#issuecomment-617013949, it might be a good idea to warn users of specialization that the feature they are using is unsound.
I also expanded the "incomplete feature" warning to link the user to the tracking issue.
Only display other method receiver candidates if they actually apply
Previously, we would suggest `Box<Self>` as a valid receiver, even if
method resolution only succeeded due to an autoderef (e.g. to `&self`)
asm: Allow multiple template string arguments; interpret them as newline-separated
Allow the `asm!` macro to accept a series of template arguments, and interpret them as if they were concatenated with a '\n' between them. This allows writing an `asm!` where each line of assembly appears in a separate template string argument.
This syntax makes it possible for rustfmt to reliably format and indent each line of assembly, without risking changes to the inside of a template string. It also avoids the complexity of having the user carefully format and indent a multi-line string (including where to put the surrounding quotes), and avoids the extra indentation and lines of a call to `concat!`.
For example, rewriting the second example from the [blog post on the new inline assembly syntax](https://blog.rust-lang.org/inside-rust/2020/06/08/new-inline-asm.html) using multiple template strings:
```rust
fn main() {
let mut bits = [0u8; 64];
for value in 0..=1024u64 {
let popcnt;
unsafe {
asm!(
" popcnt {popcnt}, {v}",
"2:",
" blsi rax, {v}",
" jz 1f",
" xor {v}, rax",
" tzcnt rax, rax",
" stosb",
" jmp 2b",
"1:",
v = inout(reg) value => _,
popcnt = out(reg) popcnt,
out("rax") _, // scratch
inout("rdi") bits.as_mut_ptr() => _,
);
}
println!("bits of {}: {:?}", value, &bits[0..popcnt]);
}
}
```
Note that all the template strings must appear before all other arguments; you cannot, for instance, provide a series of template strings intermixed with the corresponding operands.
Note numeric literals that can never fit in an expected type
re https://github.com/rust-lang/rust/pull/72380#discussion_r438289385
Given the toy code
```rust
fn is_positive(n: usize) {
n > -1_isize;
}
```
We currently get a type mismatch error like the following:
```
error[E0308]: mismatched types
--> src/main.rs:2:9
|
2 | n > -1_isize;
| ^^^^^^^^ expected `usize`, found `isize`
|
help: you can convert an `isize` to `usize` and panic if the converted value wouldn't fit
|
2 | n > (-1_isize).try_into().unwrap();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
But clearly, `-1` can never fit into a `usize`, so the suggestion will
always panic. A more useful message would tell the user that the value
can never fit in the expected type:
```
error[E0308]: mismatched types
--> test.rs:2:9
|
2 | n > -1_isize;
| ^^^^^^^^ expected `usize`, found `isize`
|
note: `-1_isize` can never fit into `usize`
--> test.rs:2:9
|
2 | n > -1_isize;
| ^^^^^^^^
```
Which is what this commit implements.
I only added this check for negative literals because
- Currently we can only perform such a check for literals (constant
value propagation is outside the scope of the typechecker at this
point)
- A lint error for out-of-range numeric literals is already emitted
IMO it makes more sense to put this check in librustc_lint, but as far
as I can tell the typecheck pass happens before the lint pass, so I've
added it here.
r? @estebank
