Better error message for generic_const_exprs inference failure
Fixes#90531
This code:
```rs
#![feature(generic_const_exprs)]
fn foo<const N: usize>(_arr: [u64; N + 1]) where [u64; N + 1]: {}
fn main() {
let arr = [5; 5];
foo(arr);
}
```
Will now emit the following error:
```rs
warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes
--> test.rs:1:12
|
1 | #![feature(generic_const_exprs)]
| ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(incomplete_features)]` on by default
= note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information
error[E0284]: type annotations needed
--> test.rs:8:7
|
8 | foo(arr);
| ^^^ cannot infer the value of the const parameter `N` declared on the function `foo`
|
note: required by a bound in `foo`
--> test.rs:3:56
|
3 | fn foo<const N: usize>(_arr: [u64; N + 1]) where [u64; N + 1]: {}
| ^^^^^ required by this bound in `foo`
help: consider specifying the generic argument
|
8 | foo::<N>(arr);
| +++++
error: aborting due to previous error; 1 warning emitted
```
cc: `@lcnr` thanks a lot again for the help on this
Move abstract const to middle
Moves AbstractConst (and all associated methods) to rustc middle for use in `rustc_infer`.
This allows for const resolution in infer to use abstract consts to walk consts and check if
they are resolvable.
This attempts to resolve the issue where `Foo<{ concrete const }, generic T>` is incorrectly marked as conflicting, and is independent from the other issue where nested abstract consts must be resolved.
r? `@lcnr`
Emit warning when named arguments are used positionally in format
Addresses Issue 98466 by emitting an error if a named argument
is used like a position argument (i.e. the name is not used in
the string to be formatted).
Fixes rust-lang#98466
`ty::Const` doesn't have precomputed type flags, so
computing `has_vars_bound_at_or_above` for constants
requires us to visit the const and its contained types
and constants. A noop fold should be pretty much equally as
fast so removing it prevents us from walking the constant twice
in case it contains bound vars.
remove allow(rustc::potential_query_instability) in rustc_span
Also, avoid sorting before debug output as iteration order can now be
relied upon.
Related #84447
Implement `for<>` lifetime binder for closures
This PR implements RFC 3216 ([TI](https://github.com/rust-lang/rust/issues/97362)) and allows code like the following:
```rust
let _f = for<'a, 'b> |a: &'a A, b: &'b B| -> &'b C { b.c(a) };
// ^^^^^^^^^^^--- new!
```
cc ``@Aaron1011`` ``@cjgillot``
Always create elided lifetime parameters for functions
Anonymous and elided lifetimes in functions are sometimes (async fns) --and sometimes not (regular fns)-- desugared to implicit generic parameters.
This difference of treatment makes it some downstream analyses more complicated to handle. This step is a pre-requisite to perform lifetime elision resolution on AST.
There is currently an inconsistency in the treatment of argument-position impl-trait for functions and async fns:
```rust
trait Foo<'a> {}
fn foo(t: impl Foo<'_>) {} //~ ERROR missing lifetime specifier
async fn async_foo(t: impl Foo<'_>) {} //~ OK
fn bar(t: impl Iterator<Item = &'_ u8>) {} //~ ERROR missing lifetime specifier
async fn async_bar(t: impl Iterator<Item = &'_ u8>) {} //~ OK
```
The current implementation reports "missing lifetime specifier" on `foo`, but **accepts it** in `async_foo`.
This PR **proposes to accept** the anonymous lifetime in both cases as an extra generic lifetime parameter.
This change would be insta-stable, so let's ping t-lang.
Anonymous lifetimes in GAT bindings keep being forbidden:
```rust
fn foo(t: impl Foo<Assoc<'_> = Bar<'_>>) {}
^^ ^^
forbidden ok
```
I started a discussion here: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Anonymous.20lifetimes.20in.20universal.20impl-trait/near/284968606
r? ``@petrochenkov``
Fix drop-tracking ICE when a struct containing a field with a significant drop is used across an await
Previously, drop-tracking would incorrectly assume the struct would be dropped immediately, which was not true.
Fixes#98476. Also fixes https://github.com/rust-lang/rust/issues/98477, I think because the parent HIR node for type variables is the whole function instead of the expression where the variable is used.
r? `@eholk`
Addresses Issue 98466 by emitting a warning if a named argument
is used like a position argument (i.e. the name is not used in
the string to be formatted).
Fixes rust-lang#98466
Pull Derefer before ElaborateDrops
_Follow up work to #97025#96549#96116#95887 #95649_
This moves `Derefer` before `ElaborateDrops` and creates a new `Rvalue` called `VirtualRef` that allows us to bypass many constraints for `DerefTemp`.
r? `@oli-obk`
Refactor: remove an unnecessary `span_to_snippet`
`span_suggestion_hidden` does not show the suggested code and the suggestion is used just for rustfix, so `span_to_snippet` is unnecessary here.
Keep unstable target features for asm feature checking
Inline assembly uses the target features to determine which registers
are available on the current target. However it needs to be able to
access unstable target features for this.
Fixes#99071
diagnostics: error messages when struct literals fail to parse
If an expression is supplied where a field is expected, the parser can become convinced that it's a shorthand field syntax when it's not.
This PR addresses it by explicitly recording the permitted `:` token immediately after the identifier, and also adds a suggestion to insert the name of the field if it looks like a complex expression.
Fixes#98917
Lower let-else in MIR
This MR will switch to lower let-else statements in MIR building instead.
To lower let-else in MIR, we build a mini-switch two branches. One branch leads to the matching case, and the other leads to the `else` block. This arrangement will allow temporary lifetime analysis running as-is so that the temporaries are properly extended according to the same rule applied to regular `let` statements.
cc https://github.com/rust-lang/rust/issues/87335Fix#98672
interpret: refactor projection handling code
Moves our projection handling code into a common file, and avoids the use of a
general mplace-based fallback function by have more specialized implementations.
mplace_index (and the other slice-related functions) could be more efficient by
copy-pasting the body of operand_index. Or we could do some trait magic to share
the code between them. But for now this is probably fine.
This is the common part of https://github.com/rust-lang/rust/pull/99013 and https://github.com/rust-lang/rust/pull/99097. I am seeing some strange perf results so this probably should be its own change so we know which diff caused which perf changes...
r? `@oli-obk`
Fix last `let_chains` blocker
In order to forbid things like `let x = (let y = 1);` or `if let a = 1 && { let x = let y = 1; } {}`, the parser **HAS** to know the context of `let`.
This context thing is not a surprise in the parser because you can see **a lot** of ad hoc fixes mixing parsing logic with validation logic creating code that looks more like spaghetti with tomato sauce.
To make things even greater, a new ad hoc fix was added to only allow `let`s in a valid `let_chains` context by checking the previously processed token. This was the only solution I could think of and believe me, I thought about it for a long time 👍
In the long term, it should be preferable to segregate different responsibilities or create a more robust and cleaner parser framework.
cc https://github.com/rust-lang/rust/pull/94927
cc https://github.com/rust-lang/rust/issues/53667
Moves our projection handling code into a common file, and avoids the use of a
general mplace-based fallback function by have more specialized implementations.
mplace_index (and the other slice-related functions) could be more efficient by
copy-pasting the body of operand_index. Or we could do some trait magic to share
the code between them. But for now this is probably fine.
Do not error during method probe on `Sized` predicates for types that aren't the method receiver
Fixes#61525
This is safe even though we're skipping an error because we end up confirming the method, which means we're still checking the `Sized` predicate in the end. It just means that we don't emit an erroneous message as below:
```
error: the `query` method cannot be invoked on a trait object
--> src/lib.rs:14:11
|
14 | 1.query::<dyn ToString>("")
| ^^^^^
|
= note: another candidate was found in the following trait, perhaps add a `use` for it:
`use crate::Example;`
```
Also fixes erroneously suggesting the same trait over again, as seen in the `issue-35976.rs` UI test.
Don't rerun the build script for the compiler each time on non-windows platforms
In practice, this doesn't matter very much because the script takes ~no time to run.
But this makes `CARGO_LOG=info` easier to read, and theoretically saves a few milliseconds.
Fix sized check ICE in asm check
Fixes (beta nominated, so doesn't close) #99122
1. Moves a check for unresolved inference variables to _before_ other checks that could possibly ICE. We're not changing behavior here, just doing the same thing earlier in the function.
2. Erases region variables in sized check (which are not resolved at this point) because rustc will also ICE when region vars are passed to a query which does not canonicalize them.
Fix duplicated type annotation suggestion
Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.
This fixes#93506 .
Create fresh lifetime parameters for bare fn trait too
The current code fails to account for the equivalence between `dyn FnMut(&mut u8)` and bare `FnMut(&mut u8)`, and treated them differently.
This PR introduces a special case for `Fn` traits, which are always fully resolved.
Fixes#98616Fixes#98726
This will require a beta-backport, as beta contains that bug.
r? `@petrochenkov`
Inline assembly uses the target features to determine which registers
are available on the current target. However it needs to be able to
access unstable target features for this.
Fixes#99071
Mention similarly named associated type even if it's not clearly in supertrait
Due to query cycle avoidance, we sometimes restrict the candidates in `complain_about_assoc_type_not_found` too much so that we can't detect typo replacements from just supertraits.
This creates a more general note of the existence of a similarly named associated type from _all_ visible traits when possible.
Fixes#55673
Implement `SourceMap::is_span_accessible`
This patch adds `SourceMap::is_span_accessible` and replaces `span_to_snippet(span).is_ok()` and `span_to_snippet(span).is_err()` with it. This removes a `&str` to `String` conversion.
explain doc comments in macros a bit
Open to suggestions on improving this... macro parsing is very foreign to me.
Should we have a structured suggestion to turn them into their regular non-doc comments?
Fixes#92846Fixes#97850
Currently, for the enums and comparison traits we always check the tag
for equality before doing anything else. This is a bit clumsy. This
commit changes things so that the tags are handled very much like a
zeroth field in the enum.
For `eq`/ne` this makes the code slightly cleaner.
For `partial_cmp` and `cmp` it's a more notable change: in the case
where the tags aren't equal, instead of having a tag equality check
followed by a tag comparison, it just does a single tag comparison.
The commit also improves how `Hash` works for enums: instead of having
duplicated code to hash the tag for every arm within the match, we do
it just once before the match.
All this required replacing the `EnumNonMatchingCollapsed` value with a
new `EnumTag` value.
For fieldless enums the new code is particularly improved. All the code
now produced is close to optimal, being very similar to what you'd write
by hand.
In practice, this doesn't matter very much because the script takes ~no time to run.
But this makes `CARGO_LOG=info` easier to read, and theoretically saves a few milliseconds.
Use `tag` in names of things referring to tags, instead of the
mysterious `vi`.
Also change `arg_N` in output to `argN`, which has the same length as
`self` and so results in nicer vertical alignments.
By producing `&T` expressions for fields instead of `T`. This matches
what the existing comments (e.g. on `FieldInfo`) claim is happening, and
it's also what most of the trait-specific code needs.
The exception is `PartialEq`, which needs `T` expressions for lots of
special case error messaging to work. So we now convert the `&T` back to
a `T` for `PartialEq`.
E.g. improving code like this:
```
match &*self {
&Enum1::Single { x: ref __self_0 } => {
::core:#️⃣:Hash::hash(&*__self_0, state)
}
}
```
to this:
```
match self {
Enum1::Single { x: __self_0 } => {
::core:#️⃣:Hash::hash(&*__self_0, state)
}
}
```
by removing the `&*`, the `&`, and the `ref`.
I suspect the current generated code predates deref-coercion.
The commit also gets rid of `use_temporaries`, instead passing around
`always_copy`, which makes things a little clearer. And it fixes up some
comments.
promote placeholder bounds to 'static obligations
In NLL, when we are promoting a bound out from a closure, if we have a requirement that `T: 'a` where `'a` is in a higher universe, we were previously ignoring that, which is totally wrong. We should be promoting those constraints to `'static`, since universes are not expressible across closure boundaries.
Fixes#98693
~~(Marking as WIP because I'm still running tests, haven't add the new test, etc)~~
r? ``@jackh726``
Previously, drop-tracking would incorrectly assume the struct would be dropped immediately, which
was not true: when the field had a type with a manual `Drop` impl, the drop becomes observable and
has to be dropped after the await instead.
For reasons I don't understand, this also fixes another error crater popped up related to type parameters.
#98476
proc_macro: Fix expand_expr expansion of bool literals
Previously, the expand_expr method would expand bool literals as a
`Literal` token containing a `LitKind::Bool`, rather than as an `Ident`.
This is not a valid token, and the `LitKind::Bool` case needs to be
handled seperately.
Tests were added to more deeply compare the streams in the expand-expr
test suite to catch mistakes like this in the future.
Partially stabilize const_slice_from_raw_parts
This doesn't stabilize methods working on mutable pointers.
This pull request continues from #94946.
Pinging `@rust-lang/wg-const-eval` this because I use `rustc_allow_const_fn_unstable`. I believe this is justifiable as it's already possible to use `slice::from_raw_parts` in stable by abusing `transmute`. The stable alternative to this would be to provide a stable const implementation of `std::ptr::from_raw_parts` (as it can already be implemented in stable).
```rust
use std::mem;
#[repr(C)]
struct Slice<T> {
data: *const T,
len: usize,
}
fn main() {
let data: *const i32 = [1, 2, 3, 4].as_ptr();
let len = 4;
println!("{:?}", unsafe {
mem::transmute::<Slice<i32>, &[i32]>(Slice { data, len })
});
}
```
`@rustbot` modify labels: +T-libs-api
don't use `commit_if_ok` during `higher_ranked_sub`
This snapshot doesn't really do anything useful for us, especially once we deal with placeholder outlive bounds during trait solving.
I guess that currently the idea is that `higher_ranked_sub` could cause a later `leak_check` to fail even if the combine operation isn't actually relevant. But really, using combine outside of snapshot and ignoring its result is wrong anyways, as it can constrain inference variables.
r? rust-lang/types
don't allow ZST in ScalarInt
There are several indications that we should not ZST as a ScalarInt:
- We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it.
`ValTree::zst()` used the former, but the latter could possibly arise as well.
- Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`.
- LLVM codegen already had to special-case ZST ScalarInt.
So I propose we stop using ScalarInt to represent ZST (which are clearly not integers). Instead, we can add new ZST variants to those types that did not have other variants which could be used for this purpose.
Based on https://github.com/rust-lang/rust/pull/98831. Only the commits starting from "don't allow ZST in ScalarInt" are new.
r? `@oli-obk`
There are several indications that we should not ZST as a ScalarInt:
- We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it.
`ValTree::zst()` used the former, but the latter could possibly arise as well.
- Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`.
- LLVM codegen already had to special-case ZST ScalarInt.
So instead add new ZST variants to those types that did not have other variants
which could be used for this purpose.
Clarify MIR semantics of storage statements
Seems worthwhile to start closing out some of the less controversial open questions about MIR semantics. Hopefully this is fairly non-controversial - it's what we implement already, and I see no reason to do anything more restrictive. cc ``@tmiasko`` who commented on this when it was discussed in the original PR that added these docs.
Implement support for DWARF version 5.
DWARF version 5 brings a number of improvements over version 4. Quoting from
the announcement [1]:
> Version 5 incorporates improvements in many areas: better data compression,
> separation of debugging data from executable files, improved description of
> macros and source files, faster searching for symbols, improved debugging
> optimized code, as well as numerous improvements in functionality and
> performance.
On platforms where DWARF version 5 is supported (Linux, primarily), this commit
adds support for it behind a new `-Z dwarf-version=5` flag.
[1]: https://dwarfstd.org/Public_Review.php
r? ``@michaelwoerister``
Miscellaneous inlining improvements
Add `#[inline]` to a few trivial non-generic methods from a perf report
that otherwise wouldn't be candidates for inlining.
