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)
These forward `Borrowed`/`Owned` values to existing `Box::from` impls.
- `From<Cow<'_, [T]>> for Box<[T]>`
- `From<Cow<'_, str>> for Box<str>`
- `From<Cow<'_, CStr>> for Box<CStr>`
- `From<Cow<'_, OsStr>> for Box<OsStr>`
- `From<Cow<'_, Path>> for Box<Path>`
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
Lint for holding locks across await points
Fixes#4226
This introduces the lint await_holding_lock. For async functions, we iterate
over all types in generator_interior_types and look for types named MutexGuard,
RwLockReadGuard, or RwLockWriteGuard. If we find one then we emit a lint.
changelog: introduce the await_holding_lock lint
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.
