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
The compiletest version-parsing tests failed after the previous patch.
However, I don't believe these tests are correct, in that I don't
think RHEL or CentOS ever put the gdb version number into parentheses.
Instead they display like:
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-119.el7
git gdb has moved to version 10. My build prints this as its
--version:
GNU gdb (GDB) 10.0.50.20200420-git
Unfortunately this conflicts with this comment in compiletest:
// We limit major to 1 digit, otherwise, on openSUSE, we parse the openSUSE version
This patch changes the version parsing to follow the GNU coding
standard, which accounts for both the openSUSE case as well as
handling gdb 10.
My debuginfo test run now says:
NOTE: compiletest thinks it is using GDB with native rust support
NOTE: compiletest thinks it is using GDB version 10000050
... where previously it failed to find that gdb 10 had rust support.
In the code, test, and docs, because it makes it much easier to find
things.
Other than adding the comments about alphabetical order, this commit
only moves things around.
More diagnostic items for Clippy usage
This adds a couple of more diagnostic items to be used in Clippy.
I chose these particular ones because they were the types which we seem
to check for the most in Clippy. I'm not sure if the `cfg_attr(not(test))`
is needed, but it was also used for `Vec` and a few other types.
cc https://github.com/rust-lang/rust-clippy/issues/5393
r? @Manishearth
Clarify unused_doc_comments note on macro invocations
The previous error message used to say:
<pre>
/// doc
^^^^^^^ rustdoc does not generate documentation for <b>macros</b>
</pre>
Obviously we do generate documentation for macros, such as https://docs.rs/bitflags/1.2.1/bitflags/macro.bitflags.html. It's only macro invocations that don't get their own docs. This PR updates the message to say "rustdoc does not generate documentation for <b>macro invocations</b>".
I observe that prior to #69084 this used to say "rustdoc does not generate documentation for **macro expansions**", as implemented originally in #57882. I don't have a preference between those but I made the commit before looking up the history.
r? @Manishearth
attn: @yaahc @euclio
Detect mistyped associated consts in `Instance::resolve`.
*Based on #71049 to prevent redundant/misleading downstream errors.*
Fixes#70942 by refusing to resolve an associated `const` if it doesn't have the same type in the `impl` that it does in the `trait` (which we assume had errored, and `delay_span_bug` guards against bugs).
This adds a couple of more diagnostic items to be used in Clippy.
I chose these particular ones because they were the types which we seem
to check for the most in Clippy. I'm not sure if the
`cfg_attr(not(test))` is needed, but it was also used for `Vec` and a
few other types.
