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
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
Implement crate-level-only lints checking.
This implements a crate_level_only flag on lints, and when it is true, it becomes an error when user tries to specify this flag upon nodes other than crate node.
This also turns on this flag for all non_ascii_ident lints.
ty: projections in `transparent_newtype_field`
Fixes#73249.
This PR modifies `transparent_newtype_field` so that it handles
projections with generic parameters, where `normalize_erasing_regions`
would ICE.
We can never supply a meaningful implementation of this.
Instead, the follow up commits will create two intrinsics
that approximate comparisons:
* `ptr_maybe_eq`
* `ptr_maybe_ne`
The fact that `ptr_maybe_eq(a, b)` is not necessarily the same
value as `!ptr_maybe_ne(a, b)` is a symptom of this entire
problem.
compiletest: Add directives to detect sanitizer support
Add needs-sanitizer-{address,leak,memory,thread} directive indicating
that test requires target with support for specific sanitizer.
This is an addition to the existing needs-sanitizer-support directive
indicating that test requires a sanitizer runtime library.
The existing needs-sanitizer-support directive could be incorporated into the
new ones, but I decided to retain it, since it enables running sanitizer
codegen tests even when building of sanitizer runtime libraries is disabled.
Fix up autoderef when reborrowing
Currently `(f)()` and `f.call_mut()` behaves differently if expression `f` contains autoderef in it. This causes a weird error in #72225.
When `f` is type checked, `Deref` is used (this is expected as we can't yet determine if we should use `Fn` or `FnMut`). When subsequently we determine the actual trait to be used, when using the `f.call_mut()` syntax the `Deref` is patched to `DerefMut`, while for the `(f)()` syntax case it is not.
This PR replicates the fixup for the first case.
Fixes#72225Fixes#68590
This commit removes the normalization from `transparent_newtype_field` -
turns out it wasn't necessary and that makes it a bunch simpler -
particularly when handling projections.
Signed-off-by: David Wood <david@davidtw.co>
