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.
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>
Opaque types cannot be used in extern declarations, and normally cannot
exist in fields - except with type aliases to `impl Trait` and
projections which normalize to them.
Signed-off-by: David Wood <david@davidtw.co>
This commit modifies `transparent_newtype_field` so that it handles
projections with generic parameters, where `normalize_erasing_regions`
would ICE.
Signed-off-by: David Wood <david@davidtw.co>
tag/niche terminology cleanup
The term "discriminant" was used in two ways throughout the compiler:
* every enum variant has a corresponding discriminant, that can be given explicitly with `Variant = N`.
* that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called "discriminant", even though it is conceptually quite different (e.g., it can be smaller in size, or even use niche-filling).
After discussion with @eddyb, this renames the second term to "tag". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`).
This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants, which surfaced in https://github.com/rust-lang/rust/pull/72419.
(There is also a `DiscriminantKind` type in libcore, it remains unaffected. I think this corresponds to the discriminant, not the tag, so that seems all right.)
r? @eddyb
Tweak "non-primitive cast" error
- Suggest borrowing expression if it would allow cast to work.
- Suggest using `<Type>::from(<expr>)` when appropriate.
- Minor tweak to `;` typo suggestion.
Partily address #47136.
Make new type param suggestion more targetted
Do not suggest new type param when encountering a missing type in an ADT
field with generic parameters.
Fix#72640.
Further tweak lifetime errors involving `dyn Trait` and `impl Trait` in return position
* Suggest substituting `'static` lifetime in impl/dyn `Trait + 'static` instead of `Trait + 'static + '_`
* When `'static` is explicit, also suggest constraining argument with it
* Reduce verbosity of suggestion message and mention lifetime in label
* Tweak output for overlapping required/captured spans
* Give these errors an error code
Follow up to #72543.
r? @nikomatsakis
Improve diagnostics for `let x += 1`
Fixes(?) #66736
The code responsible for the `E0404` errors is [here](https://github.com/rust-lang/rust/blob/master/src/librustc_parse/parser/ty.rs#L399-L424) which I don't think can be easily modified to prevent emitting an error in one specific case. Because of this I couldn't get rid of `E0404` and instead added `E0067` along with a help message which will fix the problem.
r? @estebank
Make novel structural match violations not a `bug`
Fixes (on master) #73431.
Ideally, `CustomEq` would emit a strict subset of the structural match errors that are found by `search_for_structural_match_violation`, since it allows more cases due to value-based reasoning. However, const qualification is more conservative than `search_for_structural_match_violation` around associated constants, since qualification does not try to substitute type parameters.
In the long term, we should probably make const qualification work for generic associated constants, but I don't like extending its capabilities even further.
r? @pnkfelix
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.
In order to get srcloc mappings right for macros that generate
multi-line string literals, create one line_span for each
line in the string literal, each pointing to the macro.
Make `rustc_parse_format::Parser::curarg` `pub`, so that we can
propagate it from one template string argument to the next.
