Long ago (#40549) we enabled the `uwtable` attribute on Windows by default
(even with `-C panic=abort`) to allow unwinding binaries for [stack unwinding
information][winstack]. It looks like this same issue is [plaguing][arm1]
Gecko's Android platforms [as well][arm2]. This commit applies the same fix
as #40549 except that this time it's applied for all Android targets.
Generating a `-C panic=abort` binary for `armv7-linux-androideabi` before this
commit generated a number of `cantunwind` functions (detected with `readelf -u`)
but after this commit they all list appropriate unwind information.
Closes#49867
[winstack]: https://bugzilla.mozilla.org/show_bug.cgi?id=1302078
[arm1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1453220
[arm2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1451741
rustc: Tweak custom attribute capabilities
This commit starts to lay some groundwork for the stabilization of custom
attribute invocations and general procedural macros. It applies a number of
changes discussed on [internals] as well as a [recent issue][issue], namely:
* The path used to specify a custom attribute must be of length one and cannot
be a global path. This'll help future-proof us against any ambiguities and
give us more time to settle the precise syntax. In the meantime though a bare
identifier can be used and imported to invoke a custom attribute macro. A new
feature gate, `proc_macro_path_invoc`, was added to gate multi-segment paths
and absolute paths.
* The set of items which can be annotated by a custom procedural attribute has
been restricted. Statements, expressions, and modules are disallowed behind
two new feature gates: `proc_macro_expr` and `proc_macro_mod`.
* The input to procedural macro attributes has been restricted and adjusted.
Today an invocation like `#[foo(bar)]` will receive `(bar)` as the input token
stream, but after this PR it will only receive `bar` (the delimiters were
removed). Invocations like `#[foo]` are still allowed and will be invoked in
the same way as `#[foo()]`. This is a **breaking change** for all nightly
users as the syntax coming in to procedural macros will be tweaked slightly.
* Procedural macros (`foo!()` style) can only be expanded to item-like items by
default. A separate feature gate, `proc_macro_non_items`, is required to
expand to items like expressions, statements, etc.
Closes#50038
[internals]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
[issue]: https://github.com/rust-lang/rust/issues/50038
… previously in the unstable core::num::Float trait.
Per https://github.com/rust-lang/rust/issues/32110#issuecomment-379503183,
the `abs`, `signum`, and `powi` methods are *not* included for now
since they rely on LLVM intrinsics and we haven’t determined yet whether
those instrinsics lower to calls to libm functions on any platform.
This commit starts to lay some groundwork for the stabilization of custom
attribute invocations and general procedural macros. It applies a number of
changes discussed on [internals] as well as a [recent issue][issue], namely:
* The path used to specify a custom attribute must be of length one and cannot
be a global path. This'll help future-proof us against any ambiguities and
give us more time to settle the precise syntax. In the meantime though a bare
identifier can be used and imported to invoke a custom attribute macro. A new
feature gate, `proc_macro_path_invoc`, was added to gate multi-segment paths
and absolute paths.
* The set of items which can be annotated by a custom procedural attribute has
been restricted. Statements, expressions, and modules are disallowed behind
two new feature gates: `proc_macro_expr` and `proc_macro_mod`.
* The input to procedural macro attributes has been restricted and adjusted.
Today an invocation like `#[foo(bar)]` will receive `(bar)` as the input token
stream, but after this PR it will only receive `bar` (the delimiters were
removed). Invocations like `#[foo]` are still allowed and will be invoked in
the same way as `#[foo()]`. This is a **breaking change** for all nightly
users as the syntax coming in to procedural macros will be tweaked slightly.
* Procedural macros (`foo!()` style) can only be expanded to item-like items by
default. A separate feature gate, `proc_macro_non_items`, is required to
expand to items like expressions, statements, etc.
Closes#50038
[internals]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
[issue]: https://github.com/rust-lang/rust/issues/50038
Tweak some stabilizations in libstd
This commit tweaks a few stable APIs in the `beta` branch before they hit
stable. The `str::is_whitespace` and `str::is_alphanumeric` functions were
deleted (added in #49381, issue at #49657). The `and_modify` APIs added
in #44734 were altered to take a `FnOnce` closure rather than a `FnMut` closure.
Closes#49581Closes#49657
Note that this commit, since it is trying to be minimal in order to
ease backporting to the beta and release channels, does *not* include
the old future-proofing warnings that we used to have associated with
such fallback to `()`; see discussion at this comment:
https://github.com/rust-lang/rust/issues/49691#issuecomment-381266730
This commit is just covering the feature gate itself and the tests
that made direct use of `!` and thus need to opt back into the
feature.
A follow on commit brings back the other change that motivates the
revert: Namely, going back to the old rules for falling back to `()`.
Fix bad merge in #49991
When I rebased #49991 on `master`, I messed up the merge for this line. I'm reverting this back to the way it was in f15e5c1.
r? @michaelwoerister
Disable auto-detection of libxml2 when compiling llvm.
This broke cross-compiling rustc with internal llvm (with both the host and target being executable on the machine), because llvm's build system detected libxml2 on the host, therefore auto-enabled libxml2 support, but wouldn't compile as the target didn't have libxml2 installed.
wasm: Increase default stack size to 1MB
This commit increases the dfeault stack size allocated to the
wasm32-unknown-unknown target to 1MB by default. Currently the default stack
size is one wasm page, or 64 kilobytes. This default stack is quite small and
has caused a stack overflow or two in the wild by accident.
The current "best practice" for fixing this is to pass `-Clink-args='-z
stack-size=$bigger'` but that's not great nor always easy to do. A default of
1MB matches more closely with other platforms where it's "pretty big" by
default.
Note that it was tested and if the users uses `-C link-args` to pass a custom
stack size that's still resepected as lld seems to take the first argument, and
where rustc is passing it will always be last.
Add rustdoc to x.py check
Modifying rustc can often cause errors in rustdoc, so it's useful to include it in the steps that are checked.
One thing that I was unsure about was when to call `clear_if_dirty` (both in this step, and in other steps in relation to this one) — we want to be sure rustdoc will always be rechecked after modifying previous steps — but does this belong in rustdoc, or the other steps?
Fixes#49917.
r? @Mark-Simulacrum
`nearest_common_ancestor()` uses an algorithm that requires computing
the full scope chain for both scopes, which is expensive because each
element involves a hash table lookup, and then looking for a common
tail.
This patch changes `nearest_common_ancestor()` to use a different
algorithm, which starts at the given scopes and works outwards (i.e. up
the scope tree) until a common ancestor is found. This is much faster
because in most cases the common ancestor is found well before the end
of the scope chains. Also, the use of a SmallVec avoids the need for any
allocation most of the time.
