Rollup of 6 pull requests
Successful merges:
- #89685 (refactor: VecDeques Iter fields to private)
- #97172 (Optimize the diagnostic generation for `extern unsafe`)
- #97395 (Miri call ABI check: ensure type size+align stay the same)
- #97431 (don't do `Sized` and other return type checks on RPIT's real type)
- #97555 (Source code page: line number click adds `NaN`)
- #97558 (Fix typos in comment)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
don't do `Sized` and other return type checks on RPIT's real type
Fixes an ICE where we're doing `Sized` check against the RPIT's real type, instead of against the opaque type. This differs from what we're doing in MIR typeck, which causes ICE #97226.
This regressed in #96516 -- this adjusts that fix to be a bit more conservative. That PR was backported and thus the ICE is also present in stable. Not sure if it's worth to beta and/or stable backport, probably not the latter but I could believe the former.
r? `@oli-obk`
cc: another attempt to fix this ICE #97413. I believe this PR addresses the root cause.
Miri call ABI check: ensure type size+align stay the same
We should almost certainly not accept calls where caller and callee disagree on the size or alignment of the type.
The checks we do *almost* imply that, except that `ScalarPair` types can have `repr(align)` and thus differ in size/align even when they are pairs of the same primitive type.
r? ``@oli-obk``
Optimize the diagnostic generation for `extern unsafe`
This PR does the following about diagnostic generation when parsing foreign mod:
1. Fixes the FIXME about avoiding depending on the error message text.
2. Continue parsing when `unsafe` is followed by `{` (just like `unsafe extern {...}`).
3. Add test case.
errors: simplify referring to fluent attributes
To render the message of a Fluent attribute, the identifier of the Fluent message must be known. `DiagnosticMessage::FluentIdentifier` contains both the message's identifier and optionally the identifier of an attribute. Generated constants for each attribute would therefore need to be named uniquely (amongst all error messages) or be able to refer to only the attribute identifier which will be combined with a message identifier later. In this commit, the latter strategy is implemented as part of the `Diagnostic` type's functions for adding subdiagnostics of various kinds.
r? `@oli-obk`
Add validation layer for Derefer
_Follow up work to #96549#96116#95857 #95649_
This adds validation for Derefer making sure it is always the first projection.
r? rust-lang/mir-opt
To render the message of a Fluent attribute, the identifier of the
Fluent message must be known. `DiagnosticMessage::FluentIdentifier`
contains both the message's identifier and optionally the identifier of
an attribute. Generated constants for each attribute would therefore
need to be named uniquely (amongst all error messages) or be able to
refer to only the attribute identifier which will be combined with a
message identifier later. In this commit, the latter strategy is
implemented as part of the `Diagnostic` type's functions for adding
subdiagnostics of various kinds.
Signed-off-by: David Wood <david.wood@huawei.com>
Ensure source file present when calculating max line number
Resubmission of #89268, fixes#71363
The behavior difference of `simulate-remapped-rust-src-base` is not something we should take into account here, so limiting targets to run the test makes sense, I think.
r? `@davidtwco,` and `@estebank,` you might be interested in this change
Replace `#[default_method_body_is_const]` with `#[const_trait]`
pulled out of #96077
related issues: #67792 and #92158
cc `@fee1-dead`
This is groundwork to only allowing `impl const Trait` for traits that are marked with `#[const_trait]`. This is necessary to prevent adding a new default method from becoming a breaking change (as it could be a non-const fn).
Finish bumping stage0
It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.
This now brings us to cfg-clean, with the exception of check-cfg-features in bootstrap;
I'd prefer to leave that for a separate PR at this time since it's likely to be more tricky.
cc https://github.com/rust-lang/rust/pull/97147#issuecomment-1132845061
r? `@pietroalbini`
Prepare Rust for opaque pointers
Fix one codegen bug with opaque pointers, and update our IR tests to accept both typed pointer and opaque pointer IR. This is a bit annoying, but unavoidable if we want decent test coverage on both LLVM 14 and LLVM 15.
This prepares Rust for when LLVM will enable opaque pointers by default.
Rollup of 5 pull requests
Successful merges:
- #96950 (Add regression test for #96395)
- #97028 (Add support for embedding pretty printers via `#[debugger_visualizer]` attribute)
- #97478 (Remove FIXME on `ExtCtxt::fn_decl()`)
- #97479 (Make some tests check-pass)
- #97482 (ptr::invalid is not equivalent to a int2ptr cast)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove FIXME on `ExtCtxt::fn_decl()`
`ExtCtxt::fn_decl()` is used like `self.fn_decl(..)` or `self.cx.fn_decl(..)`, coverting it to an assoc fn, for example, makes it inconvenience (e.g. `self.cx.fn_decl(..)` would be longer to represent). Given that, it doesn't seem a "FIXME" thing and unused `self` is okay, I think.
Add support for embedding pretty printers via `#[debugger_visualizer]` attribute
Initial support for [RFC 3191](https://github.com/rust-lang/rfcs/pull/3191) in PR https://github.com/rust-lang/rust/pull/91779 was scoped to supporting embedding NatVis files using a new attribute. This PR implements the pretty printer support as stated in the RFC mentioned above.
This change includes embedding pretty printers in the `.debug_gdb_scripts` just as the pretty printers for rustc are embedded today. Also added additional tests for embedded pretty printers. Additionally cleaned up error checking so all error checking is done up front regardless of the current target.
RFC: https://github.com/rust-lang/rfcs/pull/3191
Update to rebased rustc-rayon 0.4
In rayon-rs/rayon#938, miri uncovered a race in `rustc-rayon-core` that had already been fixed in the regular `rayon-core`. I have now rebased that fork onto the latest rayon branch, and published as 0.4. I also updated `indexmap` to bump the dependency.
`Cargo.lock` changes:
Updating indexmap v1.8.0 -> v1.8.2
Updating rayon v1.5.1 -> v1.5.3
Updating rayon-core v1.9.1 -> v1.9.3
Updating rustc-rayon v0.3.2 -> v0.4.0
Updating rustc-rayon-core v0.3.2 -> v0.4.1
Previously whenever a duplicate discriminant was detected for an Enum,
we would print the discriminant bits in the diagnostic without any
casting. This caused us to display incorrect values for negative
discriminants. After this PR we format the discriminant signedness
correctly. Also reworded some of the original error
messages.
proc_macro: don't pass a client-side function pointer through the server.
Before this PR, `proc_macro::bridge::Client<F>` contained both:
* the C ABI entry-point `run`, that the server can call to start the client
* some "payload" `f: F` passed to that entry-point
* in practice, this was always a (client-side Rust ABI) `fn` pointer to the actual function the proc macro author wrote, i.e. `#[proc_macro] fn foo(input: TokenStream) -> TokenStream`
In other words, the client was passing one of its (Rust) `fn` pointers to the server, which was passing it back to the client, for the client to call (see later below for why that was ever needed).
I was inspired by `@nnethercote's` attempt to remove the `get_handle_counters` field from `Client` (see https://github.com/rust-lang/rust/pull/97004#issuecomment-1139273301), which combined with removing the `f` ("payload") field, could theoretically allow for a `#[repr(transparent)]` `Client` that mostly just newtypes the C ABI entry-point `fn` pointer <sub>(and in the context of e.g. wasm isolation, that's *all* you want, since you can reason about it from outside the wasm VM, as just a 32-bit "function table index", that you can pass to the wasm VM to call that function)</sub>.
<hr/>
So this PR removes that "payload". But it's not a simple refactor: the reason the field existed in the first place is because monomorphizing over a function type doesn't let you call the function without having a value of that type, because function types don't implement anything like `Default`, i.e.:
```rust
extern "C" fn ffi_wrapper<A, R, F: Fn(A) -> R>(arg: A) -> R {
let f: F = ???; // no way to get a value of `F`
f(arg)
}
```
That could be solved with something like this, if it was allowed:
```rust
extern "C" fn ffi_wrapper<
A, R,
F: Fn(A) -> R,
const f: F // not allowed because the type is a generic param
>(arg: A) -> R {
f(arg)
}
```
Instead, this PR contains a workaround in `proc_macro::bridge::selfless_reify` (see its module-level comment for more details) that can provide something similar to the `ffi_wrapper` example above, but limited to `F` being `Copy` and ZST (and requiring an `F` value to prove the caller actually can create values of `F` and it's not uninhabited or some other unsound situation).
<hr/>
Hopefully this time we don't have a performance regression, and this has a chance to land.
cc `@mystor` `@bjorn3`
