Rustbuild cleanups/fixes and improvements
Each commit is a standalone change, and can/should be reviewed separately.
This adds two new functionalities:
- `--target` and `--host` can be passed without changing config.toml, and we'll respect the users' wishes, instead of requiring that all possible targets are passed.
- Note that this means that `./x.py clean` won't be quite as wide-spread as before, since it limits itself to the configured hosts, not all hosts. This could be considered a feature as well.
- `ignore-git` field in `config.toml` which tells Rustbuild to not attempt to load git hashes from `.git`.
This is a precursor to eventual further simplification of the configuration system, but I want to get this merged first so that later work can be made in individual PRs.
r? @alexcrichton
Expose all OS-specific modules in libstd doc.
1. Uses the special `--cfg dox` configuration passed by rustbuild when running `rustdoc`. Changes the `#[cfg(platform)]` into `#[cfg(any(dox, platform))]` so that platform-specific API are visible to rustdoc.
2. Since platform-specific implementations often won't compile correctly on other platforms, `rustdoc` is changed to apply `everybody_loops` to the functions during documentation and doc-test harness.
3. Since platform-specific code are documented on all platforms now, it could confuse users who found a useful API but is non-portable. Also, their examples will be doc-tested, so must be excluded when not testing on the native platform. An undocumented attribute `#[doc(cfg(...))]` is introduced to serve the above purposed.
Fixes#24658 (Does _not_ fully implement #1998).
This fixes the bug we previously had where we'd build a libtest tool
after building a libstd tool and clear out the libstd tool. Since we
clear out all tools for a given stage on invocations of CleanTools after
lib{std, test, rustc} change, we need to make sure that all tools built
with that stage will be built after the clearing is done.
The fix contained here technically isn't perfect; there is still an edge
case of compiling a libstd tool, then compiling libtest, which will
clear out the libstd tool and it won't ever get rebuilt within that
session of rustbuild. This is where the caching system used today shows
it's problems -- in effect, all tools depend on a global counter of the
stage being cleared out. We can implement such a counter in a future
patch to ensure that tools are rebuilt as needed, but it is deemed
unlikely that it will be required in practice, since most if not all
tools are built after the relevant stage's std/test/rustc are built,
though this is only an opinion and hasn't been verified.
Some users of the build system change the git sha on every build due to
utilizing git to push changes to a remote server. This allows them to
simply configure that away instead of depending on custom patches to
rustbuild.
This introduces a slight change in behavior, where we unilaterally
respect the --host and --target parameters passed for all sanity
checking and runtime configuration.
Improve std::ops docs
Fixes#29365. (This fixes all but one point from @steveklabnik's list, but that point was referring to examples of implementing range traits, but there are no range traits in std::ops.)
The main changes are quite a bit of copyediting, adding more "real" examples for some of the traits, incorporating some guidance from the API docs, more linking (cross-docs and to the book & reference), cleaning up examples, moving things around, and so on. Refer to the commit messages for more details.
Note: I decided to link to the second edition of the book since I think it's more appropriate now for the sections I linked, if this is not okay, please say so!
* fixed link typos and copy-paster errors
* rewrote Fn* explanations
* `RHS = Self` -> `RHS` is `Self` (added that to all applicable places as
well)
* fixed up some links
* s/MutDeref/DerefMut
* removed remaining superfluous `fn main()`s
* fixed some minor phrasings and factual errors and inaccuracies
std::ops docs: Fix phrasing and factual errors/inaccuracies
Update GitHub pull request documentation link
It looks like the GitHub documentation has been re-organized so that the "fork and pull" model isn't explained alongside the PR process in one convenient link any more.
Check #[thread_local] statics correctly in the compiler.
Fixes#43733 by introducing `#[allow_internal_unsafe]` analogous to `#[allow_internal_unstable]`, for letting a macro expand to `unsafe` blocks and functions even in `#![forbid(unsafe_code)]` crates.
Fixes#17954 by not letting references to `#[thread_local]` statics escape the function they're taken in - we can't just use a magical lifetime because Rust has *lifetime parametrism*, so if we added the often-proposed `'thread` lifetime, we'd have no way to check it in generic code.
To avoid potential edge cases in the compiler, the lifetime is actually that of a temporary at the same position, i.e. `&TLS_STATIC` has the same lifetime `&non_const_fn()` would.
Referring to `#[thread_local]` `static`s at compile-time is banned now (as per PR discussion).
Additionally, to remove `unsafe impl Sync` from `std:🧵:local::fast::Key`, `#[thread_local]` statics are now not required to implement `Sync`, as they are not shared between threads.
For box expressions, use NZ drop instead of a free block
This falls naturally out of making drop elaboration work with `box`
expressions, which is probably required for sane MIR borrow-checking.
This is a pure refactoring with no intentional functional effects.
r? @nagisa
Improve LLVM/trans scheduling a bit
Currently it's possible that the main thread is waiting on LLVM threads to finish work while its implicit token is going to waste. This PR let's the main thread take over, so one of the running LLVM threads can free its token earlier.
r? @alexcrichton
Put `intrinsics::unreachable` on a possible path to stabilization
Mark it with the `unreachable` feature and put it into the `mem` module.
This is a pretty straight-forward API that can already be simulated in
stable Rust by using `transmute` to create an uninhabited enum that can
be matched.
AddValidation: handle Call terminators into blocks that have multiple incoming edges
The old code was just wrong: It would add validation on paths that don't even come from the call, and it would add multiple validations if multiple calls end return to the same block.
