rustc: Always emit `uwtable` on Android
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
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
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
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
proc_macro: Stay on the "use the cache" path more
Discovered in #50061 we're falling off the "happy path" of using a stringified
token stream more often than we should. This was due to the fact that a
user-written token like `0xf` is equality-different from the stringified token
of `15` (despite being semantically equivalent).
This patch updates the call to `eq_unspanned` with an even more awful solution,
`probably_equal_for_proc_macro`, which ignores the value of each token and
basically only compares the structure of the token stream, assuming that the AST
doesn't change just one token at a time.
While this is a step towards fixing #50061 there is still one regression
from #49154 which needs to be fixed.
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
atomic: remove 'Atomic*' from Debug output
For the same reason that we don't show `Vec { data: [0, 1, 2, 3] }`, but just the array, the `AtomicUsize(1000)` is noisy, and seeing just `1000` is likely better.
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 src/test/ui regression testing for NLL
This PR changes `x.py test` so that when you are running the `ui` test suite, it will also always run `compiletest` in the new `--compare-mode=nll`, which just double-checks that when running under the experimental NLL mode, the output matches the `<source-name>.nll.stderr` file, if present.
In order to reduce the chance of a developer revolt in response to this change, this PR also includes some changes to make the `--compare-mode=nll` more user-friendly:
1. It now generates nll-specific .stamp files, and uses them (so that repeated runs can reuse previously cached results).
2. Each line of terminal output distinguishes whether we are running under `--compare-mode=nll` by printing with the prefix `[ui (nll)]` instead of just the prefix `[ui]`.
Subtask of rust-lang/rust#48879
Add rustc_trans to x.py check
r? @Mark-Simulacrum
I looked at `bootstrap/compile.rs` and `bootstrap/check.rs` to try to work out which steps were appropriate, but I'm sure I've overlooked some details here, so it's worth checking carefully I've got all the steps right (e.g. I wasn't sure whether we want to build LLVM if necessary with `x.py check`, though I thought it was probably better to than to not).
From a quick test, it seems to be working, though.
Discovered in #50061 we're falling off the "happy path" of using a stringified
token stream more often than we should. This was due to the fact that a
user-written token like `0xf` is equality-different from the stringified token
of `15` (despite being semantically equivalent).
This patch updates the call to `eq_unspanned` with an even more awful solution,
`probably_equal_for_proc_macro`, which ignores the value of each token and
basically only compares the structure of the token stream, assuming that the AST
doesn't change just one token at a time.
While this is a step towards fixing #50061 there is still one regression
from #49154 which needs to be fixed.
`char_lit` uses an allocation in order to ignore '_' chars in \u{...}
literals. This patch changes it to not do that by processing the chars
more directly.
This improves various rustc-perf benchmark measurements by up to 6%,
particularly regex, futures, clap, coercions, hyper, and encoding.