This just prints a message but continues on if a fallback is missing,
which can happen when we're building a partial set of builders and
producing a dev-static build from it (e.g., when no Apple builder runs
at all).
Probably the more extensive fix is to allow the build-manifest invoker
to specify the expected set of targets & hosts, but that's a far more
extensive change. The main risk from this is that we accidentally start
falling back to linux docs across all platforms without noticing. I'm
not sure that we can do much about that though at this time.
std: use `sync::RwLock` for internal statics
Since `sync::RwLock` is now `const`-constructible, it can be used for internal statics, removing the need for `sys_common::StaticRwLock`. This adds some extra allocations on platforms which need to box their locks (currently SGX and some UNIX), but these will become unnecessary with the lock improvements tracked in #93740.
This patch updates sanitizier support definitions for Android inside the
compiler. It also adjusts the logic to make sure no pre-built sanitizer
runtime libraries are emitted as these are instead provided dynamically
on Android targets.
First try to use the system preferred RNG but if that fails (e.g. due to a broken system configuration) then fallback to manually opening an algorithm handle.
Make the `normalize-overflow` rustdoc test actually do something
Since https://github.com/rust-lang/rust/pull/88679, rustdoc doesn't load crates eagerly. Add an explicit `extern crate` item to make sure the crate is loaded and the bug reproduces.
You can verify this fix by adding `// compile-flags: -Znormalize-docs` and running the test to make sure it gives an error.
rustdoc: remove no-op CSS `h1-6 { border-bottom-color }`
For this rule to have an actual effect, the border-bottom width needs specified, elsewhere, without also specifying the color. This doesn't happen. Ever since 88b137d5fe0cbe28dab4f9af61045c726f831872, every spot where headers get a border assigned to them also assigns the color.
Preview: https://notriddle.com/notriddle-rustdoc-test/border-bottom/rustc_monomorphize/collector/index.html
rustdoc: remove `docblock` class from `item-decl`
This class was originally added in 73b97c7e7c9cfac4dfa4804654b1db6ab687b589 to support hiding and showing the item, because `main.js` went through all `docblock` elements in the DOM and added toggles to them.
73b97c7e7c/src/librustdoc/html/static/main.js (L1856-L1867)
The `item-decl` is no longer auto-hidden since c96f86de3026f864e78397aff9097e885f2f8fdf removed it.
`item-decl` used to be called `type-decl`: that name was changed in 8b7a2dd4626acf164e1ce8397878b3f5af83d585.
The `docblock` class is no longer used for implementing toggles, since rustdoc switched to using `<details>` elements.
Preview: https://notriddle.com/notriddle-rustdoc-test/docblock-item-decl/rustdoc/clean/types/enum.Type.html
Improve error for when query is unsupported by crate
This is an improvement to the error message mentioned on #101666. It seems like a good idea to also add [this link to the rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/query.html), if explaining the query system in detail is a concern here, but I'm unsure if there is any restrictions on adding links to error messages.
State up-front and center what shape the returned extension will have, without
making the user read through the description and examples.
Rationale: Various frameworks and libraries for different platforms have their
different conventions as to whether an "extension" is ".ext" or just "ext" and
anyone that's had to deal with this ambiguity in the past is always double- or
triple-checking to make sure the function call returns an extension that matches
the expected semantics. Offer the answer to this important question right off
the bat instead of making them dig to find it.
remove Windows TERM env var hack and -Zmiri-env-exclude
The hack should not be needed any more since https://github.com/rust-lang/rust/pull/100206. And that also mostly removes the need for `-Zmiri-env-exclude` -- if needed, users can still achieve the same by running `(unset VAR; cargo miri test)`.
I am keeping `-Zmiri-env-forward` since it is still useful, e.g. to have RUST_BACKTRACE=full set in an otherwise deterministic execution.
`@rust-lang/miri` any objections to removing `-Zmiri-env-exclude`?
avoid thread-local var indirection for non-halting diagnostics
This hack used to be necessary because Stacked Borrows did not have access to enough parts of the machine. But that got fixed a while ago, so now we can just emit diagnostics directly, which is a lot more reliable.
Needs https://github.com/rust-lang/rust/pull/101985
Fixes https://github.com/rust-lang/miri/issues/2538
`.into_iter()` on arrays was slower than it needed to be (especially compared to slice iterator) since it uses `Range<usize>`, which needs to handle degenerate ranges like `10..4`.
This PR adds an internal `IndexRange` type that's like `Range<usize>` but with a safety invariant that means it doesn't need to worry about those cases -- it only handles `start <= end` -- and thus can give LLVM more information to optimize better.
I added one simple demonstration of the improvement as a codegen test.
