- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the incorrect wasm32 C call ABI with the old asmjs
version, which is correct for both wasm32 and JS.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Temporarily makes Emscripten targets use panic=abort by default
because supporting unwinding will require an LLVM patch.
`filter_map()` is less general, but more efficient, and has the same
effect in this case.
This commit reduces the instruction count for
`unicode_normalization-check-clean` by about 2%.
The `if let Some(val) = value.try_eval_bits(...)` branch in `from_const()` is
very hot for the `unicode_normalization` benchmark.
This commit introduces a special-case alternative for scalars that avoids
`try_eval_bits()` and all the functions it calls (`Const::eval()`,
`ConstValue::try_to_bits()`, `ConstValue::try_to_scalar()`, and
`Scalar::to_bits()`), instead extracting the result immediately.
The type and value checking done by `Scalar::to_bits()` is replicated by moving
it into a new function `Scalar::check_raw()` and using that new function in the
special case.
PR #64673 introduced some special-case handling of scalar types in
`Const::try_eval_bits()`. This handling is now moved out of that function into
the new `IntRange::integral_size_and_signed_bias` function.
This commit reduces the instruction count for
`unicode_normalization-check-clean` by about 10%.
This commit moves a lot of code around but doesn't change functionality
at all. The main goal was for `from_pat()` to no longer call
`from_ctor()`.
The increase in inlining resulted in less function call overhead, for a
3% instruction count win on `unicode_normalization-check-clean`.
metadata: Some crate loading cleanup
So, my goal was to fix caching of loaded crates which is broken and causes ICEs like #56935 or #64450.
While investigating I found that the code is pretty messy and likes to confuse various things that look similar but are actually different.
This PR does some initial cleanup in that area, I hope to get to the caching itself a bit later.
Fix most remaining Polonius test differences
This fixes most of the Polonius test differences and also avoids overflow in issue-38591.rs.
r? @nikomatsakis
Set RUST_BACKTRACE=0 in tests that include a backtrace in stderr
This removes the implicit dependency on the environment variables set
when running `./x.py test`
proc_macro API: Expose `macro_rules` hygiene
Proc macros do not have direct access to our oldest and most stable hygiene kind - `macro_rules` hygiene.
To emulate it macro authors have to go through two steps - first generate a temporary `macro_rules` item (using a derive, at least until https://github.com/rust-lang/rust/pull/64035 is merged), then generate a macro call to that item. Popular crates like [proc_macro_hack](https://crates.io/crates/proc-macro-hack) use this trick to generate hygienic identifiers from proc macros.
I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence.
So, let's provide a direct access to `macro_rules` hygiene instead.
This PR does that by adding a new method `Span::mixed_site` (bikeshedding is welcome) in addition to existing `Span::call_site` (stable) and `Span::def_site` (unstable).
Identifiers with this span resolve at def-site in for local variables, labels and `$crate`, and resolve at call-site for everything else, i.e. exactly like identifiers produced by `macro_rules`.
This API addition opens the way to stabilizing proc macros in expression positions (https://github.com/rust-lang/rust/issues/54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate.
(`macro_rules` expanded in expression position, on the other hand, are stable since 1.0 and widely used.)
r? @dtolnay @alexcrichton
Deprecate `#![plugin]` & `#[plugin_registrar]`
This PR deprecates `#![plugin]` and `#[plugin_registrar]`.
~A removal deadline is set: 1.44.0. This will be in 9 months from now and should give everyone who is still relying on the feature ample time to rid themselves of this dependency.~
cc https://github.com/rust-lang/rust/issues/29597
r? @Mark-Simulacrum
Stabilize todo macro
The `todo!` macro is just another name for `unimplemented!`.
Tracking issue: https://github.com/rust-lang/rust/issues/59277
This PR needs a FCP to merge.
r? @withoutboats
It was only used for retreiving edition, which was a bug.
In case of dual proc macros the edition should be taken from the target crate version, like any other metadata.
