Improve E0308 error message wording again
Hello again,
I recently did this PR: #70242
I felt the error message could be further improved, so I made [a post on the Rust community forum](https://users.rust-lang.org/t/looking-for-feedback-on-an-improved-error-message-for-e0308/40004) to ask for feedback.
(Also, there were some comments on my original PR that I took into consideration as well.)
This PR is my attempt to take all the feedback into account and propose a better and simplified error message that should still be accurate. Its main benefit is having simpler grammar, and hopefully being easier to read and understand.
Thanks to everyone who commented and gave feedback, and thank you for taking a look at this PR.
Reading from the return place is fine
Const eval thinks that reading from local `_0` is UB, but it isn't. `_0` is just a normal local like any other, and codegen handles it that way too. The only special thing is that the `Return` terminator will read from it.
I've hit these errors while working on an NRVO pass that can merge other locals with `_0` in https://github.com/rust-lang/rust/pull/71003.
r? @oli-obk
proc_macro::is_available()
This PR adds `proc_macro::is_available() -> bool` to determine whether proc_macro has been made accessible to the currently running program.
The proc_macro crate is only intended for use inside the implementation of procedural macros. All the functions in the crate panic if invoked from outside of a procedural macro, such as from a build script or unit test or ordinary Rust binary.
Unfortunately those panics made it impossible for libraries that are designed to support both macro and non-macro use cases (e.g. Syn) to be used from binaries that are compiled with panic=abort. In panic=unwind mode we're able to attempt a proc macro call inside catch_unwind and use libproc_macro's result if it succeeds, otherwise fall back to a non-macro alternative implementation. But in panic=abort there was no way to determine which implementation needs to be used.
r? @eddyb
attn: @petrochenkov @adetaylor
ref: https://github.com/dtolnay/cxx/issues/130
allow wasm32 compilation of librustc_data_structures/profiling.rs
I'm trying to use rustfmt from a wasm app. I ran into this compilation problem https://github.com/rust-lang/rustfmt/issues/4132 and after investigating, it looked like just adjusting a few cfg's. I based it on how measureme added support in https://github.com/rust-lang/measureme/pull/43.
My testing on my macbook was just that librustc_data_structures builds now with both:
- cargo build
- cargo build --target wasm32-unknown-unknown
Lint must_use on mem::replace
This adds a hint on `mem::replace`, "if you don't need the old value,
you can just assign the new value directly". This is in similar spirit
to the `must_use` on `ManuallyDrop::take`.
Remove `BodyAndCache`
...returning to the original approach using interior mutability within `Body`. This simplifies the API at the cost of some uncontended mutex locks when the parallel compiler is enabled.
The current API requires you to either have a mutable reference to `Body` (`&mut BodyAndCache`), or to compute the predecessor graph ahead of time by creating a `ReadOnlyBodyAndCache`. This is not a good fit for, e.g., the dataflow framework, which
1. does not mutate the MIR
2. only sometimes needs the predecessor graph (for backward dataflow problems)
Rollup of 4 pull requests
Successful merges:
- #71280 (Miri: mplace_access_checked: offer option to force different alignment on place)
- #71336 (Exhaustively match on `{Statement,Terminator}Kind` during const checking)
- #71370 (Added detailed error code explanation for issue E0696 in Rust compiler.)
- #71401 (visit_place_base is just visit_local)
Failed merges:
r? @ghost
Added detailed error code explanation for issue E0696 in Rust compiler.
Added proper error explanation for issue E0696 in the Rust compiler.
Error Code E0696
Sub Part of Issue #61137
r? @GuillaumeGomez
Exhaustively match on `{Statement,Terminator}Kind` during const checking
This adds a pre-monomorphization error for inline assembly in a const context as well.
r? @oli-obk
