Do not disable field reordering on enums with big discriminant
The field are always re-ordered to minimize padding, regardless of the
alignment of the discriminant
(spinoff from #70477)
typeck/type_of: let wfcheck handle generics in opaque types' substs.
I was working on #70164, and `type_of`'s handling of opaque types seemed to be, by far, the trickiest use of `Ty::walk`, but I believe it wasn't doing anything (see https://github.com/rust-lang/rust/pull/57896#discussion_r396064431 - I suspect, based on glancing at the PR discussion, that an early attempt was kept in, despite becoming just an overcomplicated way to do exactly the same as the previous simple type equality check).
I would've loved to remove `ResolvedOpaqueTy` (keep the `Ty` and lose the `Substs`), but it looks like the MIR borrowck part of the process needs that now, so it would've been added anyway since #57896, even if that PR hadn't happened.
<hr/>
In the process, I've moved the remaining substitution validation to `wfcheck`, which was already handling lifetimes, and kept only `delay_span_bug`s in `type_of`, as an insurance policy.
I've added tests for lifetime and const cases, they seem to be checked correctly now.
(and more uniform than they were in https://github.com/rust-lang/rust/issues/63063#issuecomment-602162804)
However, the quality of the errors is maybe a bit worse, and they don't trigger when there are other errors (not sure if this is due to compilation stop points or something more specific to one opaque type).
r? @nikomatsakis cc @matthewjasper @oli-obk @Aaron1011
Place TLS initializers with relocations in .tdata
Should fix#70673, although I'm not sure how to test this. Perhaps @joshlf could find a MCVE?
Also adds more context to the FIXME.
r? @oli-obk
Translate the virtual `/rustc/$hash` prefix back to a real directory.
Closes#53486 and fixes#53081, by undoing the remapping to `/rustc/$hash` on the fly, when appropriate (e.g. our testsuites, or user crates that depend on `libstd`), but not during the Rust build itself (as that could leak the absolute build directory into the artifacts, breaking deterministic builds).
Tested locally by setting `remap-debuginfo = true` in `config.toml`, which without these changes, was causing 56 tests to fail (see https://github.com/rust-lang/rust/issues/53081#issuecomment-606703215 for more details).
cc @Mark-Simulacrum @alexcrichton @ehuss
Handle unterminated raw strings with no #s properly
The modified code to handle parsing raw strings didn't properly account for the case where there was no "#" on either end and erroneously reported this strings as complete. This lead to a panic trying to read off the end of the file.
Fixes#70677
r? @petrochenkov
cc @Centril
parse: recover on `const fn()` / `async fn()`
Recover on `const fn()` and `async fn()` function pointers, suggesting to remove the qualifier.
For example:
```
error: an `fn` pointer type cannot be `async`
--> $DIR/recover-const-async-fn-ptr.rs:6:11
|
LL | type T3 = async fn();
| -----^^^^^
| |
| `async` because of this
| help: remove the `async` qualifier
```
r? @estebank
Overhaul of the `AllocRef` trait to match allocator-wg's latest consens; Take 2
GitHub won't let me reopen#69889 so I make a new PR.
In addition to #69889 this fixes the unsoundness of `RawVec::into_box` when using allocators supporting overallocating. Also it uses `MemoryBlock` in `AllocRef` to unify `_in_place` methods by passing `&mut MemoryBlock`. Additionally, `RawVec` now checks for `size_of::<T>()` again and ignore every ZST. The internal capacity of `RawVec` isn't used by ZSTs anymore, as `into_box` now requires a length to be specified.
r? @Amanieu
fixesrust-lang/wg-allocators#38fixesrust-lang/wg-allocators#41fixesrust-lang/wg-allocators#44fixesrust-lang/wg-allocators#51
The modified code to handle parsing raw strings didn't properly account for the case where there was no "#" on either end and erroneously reported this strings as complete. This lead to a panic trying to read off the end of the file.
Miri: make backtrace function names and spans match up
Currently, Miri backtraces are a bit confusing:
```
error: Undefined Behavior: entering unreachable code
--> tests/compile-fail/never_transmute_void.rs:10:11
|
10 | match v {} //~ ERROR entering unreachable code
| ^ entering unreachable code
|
= help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
= help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
note: inside call to `f` at tests/compile-fail/never_transmute_void.rs:17:5
--> tests/compile-fail/never_transmute_void.rs:17:5
|
17 | f(v); //~ inside call to `f`
| ^^^^
= note: inside call to `main` at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:67:34
= note: inside call to closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/rt.rs:52:73
= note: inside call to closure at /home/r/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys_common/backtrace.rs:130:5
```
When reading this like a normal backtrace, one would expect that e.g. the backrace involves the "main" function at "libstd/rt.rs:67:34". But that is not actually where we are in the main function, that is *where the main function is called*.
This is not how backtraces are usually rendered (including e.g. with `RUST_BACKTRACE=1`). Usually we print next to each function name where inside that function the frame is currently executing, not where the *parent* frame is executing. With this PR and the Miri side at https://github.com/rust-lang/miri/pull/1283, the backtrace now looks as follows:
```
error: Undefined Behavior: entering unreachable code
--> tests/compile-fail/never_transmute_void.rs:10:11
|
10 | match v {} //~ ERROR entering unreachable code
| ^ entering unreachable code
|
= help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
= help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
= note: inside `f` at tests/compile-fail/never_transmute_void.rs:10:11
note: inside `main` at tests/compile-fail/never_transmute_void.rs:17:5
--> tests/compile-fail/never_transmute_void.rs:17:5
|
17 | f(v); //~ inside `main`
| ^^^^
= note: inside closure at /home/r/src/rust/rustc/src/libstd/rt.rs:67:34
= note: inside closure at /home/r/src/rust/rustc/src/libstd/rt.rs:52:73
= note: inside `std::sys_common::backtrace::__rust_begin_short_backtrace::<[closure@DefId(1:6034 ~ std[87db]::rt[0]::lang_start_internal[0]::{{closure}}[0]::{{closure}}[0]) 0:&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/src/rust/rustc/src/libstd/sys_common/backtrace.rs:130:5
```
Now function name and printed line numbers match up in the notes.
This code is partially shared with const-eval, so the change also affects const-eval: instead of printing what is being called at some span, we print which function/constant this span is inside.
With this, we can also remove the `span` field from Miri's stack frames (which used to track the *caller span* of that frame, quite confusing), and then get of a whole lot of `span` arguments that ultimately just served to fill that field (and as a fallback for `caller_location`, which however was never actually used).
r? @oli-obk
Improve error messages for raw strings (#60762)
This diff improves error messages around raw strings in a few ways:
- Catch extra trailing `#` in the parser. This can't be handled in the lexer because we could be in a macro that actually expects another # (see test)
- Refactor & unify error handling in the lexer between ByteStrings and RawByteStrings
- Detect potentially intended terminators (longest sequence of "#*" is suggested)
Fixes#60762
cc @estebank who reviewed the original (abandoned) PR for the same ticket.
r? @Centril
add `unused_braces` lint
Add the lint `unused_braces` which is warn by default.
`unused_parens` is also extended and now checks anon consts.
closes#68387
r? @varkor
Ensure there are versions of test code for aarch64 windows
Remove the `cfg` flags that were preventing some tests from running on `aarch64-pc-windows-msvc`.
All the existing `target_os = windows` targets had the same `align()` and `size()` values, so this change just removes the `target_arch` flags.
r? @alexcrichton
infer array len from pattern
closes#70529
This still errors in the following case
```rust
#![feature(const_generics)]
fn arr<const N: usize>() -> [u8; N] {
todo!()
}
fn main() {
match arr() {
[5, ..] => (),
//~^ ERROR cannot pattern-match on an array without a fixed length
[_, _] => (),
}
}
```
Considering that this should be rare and is harder to implement I would merge this PR without *fixing* the above.
Add long error code for error E0226
Added a long description message for error E0226, which previously did not exist.
As requested in issue #61137
r? @GuillaumeGomez
