Inline Windows `OsStrExt::encode_wide`
User crates currently produce much more code than necessary because the optimizer fails to make assumptions about this method.
Remove unsupported options in configure.py
I've seen people using `optimize = false` and `full-bootstrap = true` in the past, without knowing
that they're not recommended. Remove `optimize` and a few other options that are always a bad idea,
and document that full-bootstrap is only for testing reproducible builds.
In practice, this doesn't matter very much because the script takes ~no time to run.
But this makes `CARGO_LOG=info` easier to read, and theoretically saves a few milliseconds.
Fix `x build library/std compiler/rustc`
Previously, this was broken because of improper caching:
1. `StepDescription::maybe_run` builds `Compile::Std`, which only built `std` and not `proc_macro`
1. `Std` calls `builder.ensure(StdLink)`
1. `Rustc` calls `ensure(Std)`, which builds all crates, including `proc_macro`
1. `Rustc` calls `ensure(StdLink)`. `ensure` would see that it had already been run and do nothing. <-- bug is here
1. Cargo gives an error that `proc_macro` doesn't exist.
This fixes the caching by adding `crates` to `StdLink`, so it will get rerun if the crates that are built change.
Fixes https://github.com/rust-lang/rust/issues/99129.
Allow using `download-ci-llvm = true` outside the git checkout
`@bjorn3` noticed that this is already allowed today when download-llvm is disabled, but breaks with it enabled:
```
$ ./rust2/x.py build
fatal: not a git repository (or any of the parent directories): .git
thread 'main' panicked at 'command did not execute successfully: "git" "rev-list" "--author=bors@rust-lang.org" "-n1" "--first-parent" "HEAD" "--" "/home/jnelson/rust-lang/rust2/src/llvm-project" "/home/jnelson/rust-lang/rust2/src/bootstrap/download-ci-llvm-stamp" "/home/jnelson/rust-lang/rust2/src/version"
expected success, got: exit status: 128', src/bootstrap/native.rs:134:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Support it too for consistency. It's unclear to me when anyone would need to use this, but `@bjorn3`
feels we should support it, and it's not much additional effort to get it working.
Previously, this was broken because of improper caching:
1. `StepDescription::maybe_run` builds `Compile::Std`, which only built `std` and not `proc_macro`
1. `Std` calls `builder.ensure(StdLink)`
1. `Rustc` calls `ensure(Std)`, which builds all crates, including `proc_macro`
1. `Rustc` calls `ensure(StdLink)`. `ensure` would see that it had already been run and do nothing. <-- bug is here
1. Cargo gives an error that `proc_macro` doesn't exist.
This fixes the caching by adding `crates` to `StdLink`, so it will get rerun if the crates that are
built change. This also does the same for `RustcLink`; it doesn't matter in practice currently
because nothing uses it except `impl Step for Rustc`, but it will avoid bugs if we start using it in
the future (e.g. to build individual crates for rustfmt).
Fix `download-ci-llvm` NixOS patching for binaries
LLVM tools should also be patched, since they are used in some tests, specially,
- src/test/run-make-fulldeps/cross-lang-lto (llvm-ar)
- src/test/run-make-fulldeps/cross-lang-lto-upstream-rlibs (llvm-ar)
- src/test/run-make-fulldeps/issue-64153 (llvm-objdump)
To be more future proof, we should patch all binaries in `bin`, which is done in this PR.
Group .test-arrow CSS rules and fix rgb/rgba property
Surprisingly, the web browsers were handling the `rgb`/`rgba` typo correctly. At least it now is as expected.
For the rest, it's simply grouping `.test-arrow` rules.
r? ``@Dylan-DPC``
promote placeholder bounds to 'static obligations
In NLL, when we are promoting a bound out from a closure, if we have a requirement that `T: 'a` where `'a` is in a higher universe, we were previously ignoring that, which is totally wrong. We should be promoting those constraints to `'static`, since universes are not expressible across closure boundaries.
Fixes#98693
~~(Marking as WIP because I'm still running tests, haven't add the new test, etc)~~
r? ``@jackh726``
LLVM tools should also be patched, since they are used in some tests,
specially,
- src/test/run-make-fulldeps/cross-lang-lto (llvm-ar)
- src/test/run-make-fulldeps/cross-lang-lto-upstream-rlibs (llvm-ar)
- src/test/run-make-fulldeps/issue-64153 (llvm-objdump)
To be more future proof, we should patch all binaries in `bin`.
@bjorn3 noticed that this is already allowed today when download-llvm is disabled, but breaks with it enabled:
```
$ ./rust2/x.py build
fatal: not a git repository (or any of the parent directories): .git
thread 'main' panicked at 'command did not execute successfully: "git" "rev-list" "--author=bors@rust-lang.org" "-n1" "--first-parent" "HEAD" "--" "/home/jnelson/rust-lang/rust2/src/llvm-project" "/home/jnelson/rust-lang/rust2/src/bootstrap/download-ci-llvm-stamp" "/home/jnelson/rust-lang/rust2/src/version"
expected success, got: exit status: 128', src/bootstrap/native.rs:134:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Support it too for consistency. It's unclear to me when anyone would need to use this, but @bjorn3
feels we should support it, and it's not much additional effort to get it working.
This also updates a bunch of other git commands that were similarly depending on the current directory.
I've seen people using `optimize = false` and `full-bootstrap = true` in the past, without knowing
that they're not recommended. Remove `optimize` and a few other options that are always a bad idea,
and document that full-bootstrap is only for testing reproducible builds.
proc_macro: Fix expand_expr expansion of bool literals
Previously, the expand_expr method would expand bool literals as a
`Literal` token containing a `LitKind::Bool`, rather than as an `Ident`.
This is not a valid token, and the `LitKind::Bool` case needs to be
handled seperately.
Tests were added to more deeply compare the streams in the expand-expr
test suite to catch mistakes like this in the future.
Rollup of 5 pull requests
Successful merges:
- #99045 (improve print styles)
- #99086 (Fix display of search result crate filter dropdown)
- #99100 (Fix binary name in help message for test binaries)
- #99103 (Avoid some `&str` to `String` conversions)
- #99109 (fill new tracking issue for `feature(strict_provenance_atomic_ptr)`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
fill new tracking issue for `feature(strict_provenance_atomic_ptr)`
New tracking issue: #99108.
The generic strict provenance issue has a lot of discussions on its own, so I think it's meaningful to have a separate issue for atomic ptr methods.
Fix binary name in help message for test binaries
Currently the help output for a test binary uses the first argument instead of the binary name in the help output:
```
$ cargo test -- --help
...
Usage: --help [OPTIONS] [FILTERS...]
...
```
This fixes it to use the name of the binary (or `...` if there is no binary name passed on argv):
```
$ cargo test -- --help
...
Usage: /tmp/x/target/debug/deps/x-80c11a15ad4e1bf3 [OPTIONS] [FILTERS...]
...
```
improve print styles
this change removes some interactive elements in ``@media` print` form.
more specifically, it removes the sidebar, source links, the expand/collapse toggle buttons, and the `#copy-path` button.
it also adjusts some spacing and removes the `.top-doc` description completely if it's currently collapsed.
Enforce that layout size fits in isize in Layout
As it turns out, enforcing this _in APIs that already enforce `usize` overflow_ is fairly trivial. `Layout::from_size_align_unchecked` continues to "allow" sizes which (when rounded up) would overflow `isize`, but these are now declared as library UB for `Layout`, meaning that consumers of `Layout` no longer have to check this before making an allocation.
(Note that this is "immediate library UB;" IOW it is valid for a future release to make this immediate "language UB," and there is an extant patch to do so, to allow Miri to catch this misuse.)
See also #95252, [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Layout.20Isn't.20Enforcing.20The.20isize.3A.3AMAX.20Rule).
Fixes https://github.com/rust-lang/rust/issues/95334
Some relevant quotes:
`@eddyb,` https://github.com/rust-lang/rust/pull/95252#issuecomment-1078513769
> [B]ecause of the non-trivial presence of both of these among code published on e.g. crates.io:
>
> 1. **`Layout` "producers" / `GlobalAlloc` "users"**: smart pointers (including `alloc::rc` copies with small tweaks), collections, etc.
> 2. **`Layout` "consumers" / `GlobalAlloc` "providers"**: perhaps fewer of these, but anything built on top of OS APIs like `mmap` will expose `> isize::MAX` allocations (on 32-bit hosts) if they lack extra checks
>
> IMO the only responsible option is to enforce the `isize::MAX` limit in `Layout`, which:
>
> * makes `Layout` _sound_ in terms of only ever allowing allocations where `(alloc_base_ptr: *mut u8).offset(size)` is never UB
> * frees both "producers" and "consumers" of `Layout` from manually reimplementing the checks
> * manual checks can be risky, e.g. if the final size passed to the allocator isn't the one being checked
> * this applies retroactively, fixing the overall soundness of existing code with zero transition period or _any_ changes required from users (as long as going through `Layout` is mandatory, making a "choke point")
>
>
> Feel free to quote this comment onto any relevant issue, I might not be able to keep track of developments.
`@Gankra,` https://github.com/rust-lang/rust/pull/95252#issuecomment-1078556371
> As someone who spent way too much time optimizing libcollections checks for this stuff and tried to splatter docs about it everywhere on the belief that it was a reasonable thing for people to manually take care of: I concede the point, it is not reasonable. I am wholy spiritually defeated by the fact that _liballoc_ of all places is getting this stuff wrong. This isn't throwing shade at the folks who implemented these Rc features, but rather a statement of how impractical it is to expect anyone out in the wider ecosystem to enforce them if _some of the most audited rust code in the library that defines the very notion of allocating memory_ can't even reliably do it.
>
> We need the nuclear option of Layout enforcing this rule. Code that breaks this rule is _deeply_ broken and any "regressions" from changing Layout's contract is a _correctness_ fix. Anyone who disagrees and is sufficiently motivated can go around our backs but the standard library should 100% refuse to enable them.
cc also `@RalfJung` `@rust-lang/wg-allocators.` Even though this technically supersedes #95252, those potential failure points should almost certainly still get nicer panics than just "unwrap failed" (which they would get by this PR).
It might additionally be worth recommending to users of the `Layout` API that they should ideally use `.and_then`/`?` to complete the entire layout calculation, and then `panic!` from a single location at the end of `Layout` manipulation, to reduce the overhead of the checks and optimizations preserving the exact location of each `panic` which are conceptually just one failure: allocation too big.
Probably deserves a T-lang and/or T-libs-api FCP (this technically solidifies the [objects must be no larger than `isize::MAX`](https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#isize-and-usize) rule further, and the UCG document says this hasn't been RFCd) and a crater run. Ideally, no code exists that will start failing with this addition; if it does, it was _likely_ (but not certainly) causing UB.
Changes the raw_vec allocation path, thus deserves a perf run as well.
I suggest hiding whitespace-only changes in the diff view.
Partially stabilize const_slice_from_raw_parts
This doesn't stabilize methods working on mutable pointers.
This pull request continues from #94946.
Pinging `@rust-lang/wg-const-eval` this because I use `rustc_allow_const_fn_unstable`. I believe this is justifiable as it's already possible to use `slice::from_raw_parts` in stable by abusing `transmute`. The stable alternative to this would be to provide a stable const implementation of `std::ptr::from_raw_parts` (as it can already be implemented in stable).
```rust
use std::mem;
#[repr(C)]
struct Slice<T> {
data: *const T,
len: usize,
}
fn main() {
let data: *const i32 = [1, 2, 3, 4].as_ptr();
let len = 4;
println!("{:?}", unsafe {
mem::transmute::<Slice<i32>, &[i32]>(Slice { data, len })
});
}
```
`@rustbot` modify labels: +T-libs-api
