retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features
`-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates).
* Enables target features for `-Zretpoline-external-thunk`:
`+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
* Enables target features for `-Zretpoline`:
`+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.
Also this PR forbids to specify those target features manually (warning).
Issue: rust-lang/rust#116852
intrinsics: rename min_align_of to align_of
Now that `pref_align_of` is gone (https://github.com/rust-lang/rust/pull/141803), we can give the intrinsic backing `align_of` its proper name.
r? `@workingjubilee` or `@bjorn3`
Add bootstrap option to compile a tool with features
Add an option to specify which features to build a tool with, e.g. it will be useful to build Miri with tracing enabled:
```toml
tool-config.miri.features = ["tracing"]
```
See [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Passing.20--features.20to.20Miri.20build.20using.20.2E.2Fx.2Epy/with/523564773) for the options considered. If the final decision will be different than what I wrote now, I will update the code as needed. The reason why the option is `tool-config.miri.features` instead of something like `tool-features.miri` is to possibly allow adding more tool-specific configurations in the future.
I didn't do any validation of the keys of the `tool-config` hashmap, since I saw that no validation is done on the `tools` hashset either.
I don't like much the fact that features can be chosen by various places of the codebase: `Step`s can have some fixed `extra_features`, `prepare_tool_cargo` will add features depending on some bootstrapping options, and the newly added option can also contribute features to tools. However I think it is out of scope of this PR to try to refactor all of that (if it even is refactorable), so I left a comment in the codebase explaining all of the sources of features I could find.
Tracking the old name of renamed unstable library features
This PR resolves the first problem of rust-lang/rust#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification.
r? `@jdonszelmann`
There have been a lot of PR's reviewed by you lately, thanks for your time!
cc `@jyn514`
Introduce `-Zmacro-stats`
Introduce `-Zmacro-stats`.
It collects data about macro expansions and prints them in a table after expansion finishes. It's very useful for detecting macro bloat, especially for proc macros.
r? `@petrochenkov`
Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code
Follow-up of https://github.com/rust-lang/rust/pull/141747.
Thanks `@camelid` for spotting it!
r? `@camelid`
miri: add flag to suppress float non-determinism
We have flags controlling most non-determinism, so this seems generally useful for debugging. It is also needed to work around https://github.com/rust-lang/portable-simd/issues/463 in miri-test-libstd.
I made this a rustc PR so that it propagates faster to unbreak miri-test-libstd.
r? `@oli-obk`
It collects data about macro expansions and prints them in a table after
expansion finishes. It's very useful for detecting macro bloat,
especially for proc macros.
Details:
- It measures code snippets by pretty-printing them and then measuring
lines and bytes. This required a bunch of additional pretty-printing
plumbing, in `rustc_ast_pretty` and `rustc_expand`.
- The measurement is done in `MacroExpander::expand_invoc`.
- The measurements are stored in `ExtCtxt::macro_stats`.
Assorted bootstrap cleanups (step 1)
Now that the stage0 redesign has landed, we can finally start cleaning up many things in bootstrap, and lord knows it deserves it! I plan to send many PRs once I figure out an incremental way forward, this is the first one of them. It doesn't actually change anything, just renames stuff and adds more documentation, but the rename is bitrotty, so I wanted to push the PR eagerly.
r? `@jieyouxu`
Add tracing import to execution context
In https://github.com/rust-lang/rust/pull/141909, we missed adding the trace_cmd import in the execution context module. This PR fixes that. Additionally, we are updating the mingw-check-2 check command to include BOOTSTRAP_TRACING=1 to help ensure we don't miss such cases in future PRs.
r? `@Kobzol`
Implement `//@ needs-target-std` compiletest directive
Closesrust-lang/rust#141863.
Needed to unblock rust-lang/rust#139244 and rust-lang/rust#141856.
### Summary
This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit].
### Implementation limitation
Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](https://github.com/rust-lang/rust/issues/142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`.
### Auxiliary changes
This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang/rust#139244.
---
r? bootstrap
[^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
Rewriting git history is something that is often difficult for new contributors,
and we're already explaining the `<foo>` placeholder syntax,
so I think it makes sense to be explicit about what exactly the paths mean.
Host is the machine where bootstrap runs, and this field represents the target of the (host) stage0/beta compiler. This is much clearer than `build`, which also conflicts with the `Build` struct, which is stored under the name `build` inside `Builder` (lol).
platform-support.md: Mention specific Linux kernel version or later
To be consistent with notes for other targets...
~~(Only made the change for `aarch64-unknown-linux-gnu` for now, as that's fairly certain after looking at the `git blame` just to be sure.)~~
Add central execution context to bootstrap
This PR continues the effort toward command centralization as outlined in https://github.com/rust-lang/rust/issues/126819. It introduces a centralized execution context through which all commands will be executed. Previously, centralization was limited to build methods; this PR extends it to the `config` module and updates the remaining methods accordingly.
Best reviewed commit by commit.
r? ``@Kobzol``
Don't create .msi installer for gnullvm hosts
WIX toolset works only on Windows hosts, but gnullvm doesn't have host toolchain yet. To get out of this loop, we will create a single release without MSI installer.
Split out from: https://github.com/rust-lang/rust/pull/140772
