Fix AIX build
Fixrust-lang/rust#141543.
`getenv` was moved out of this file to `sys::env::getenv` in rust-lang/rust#140143. Replace its usage with `std::env::var_os`, the publicly exposed version. This matches the other usages of the same function in this file.
Optimize `Seek::stream_len` impl for `File`
It uses the file metadata on Unix with a fallback for files incorrectly reported as zero-sized. It uses `GetFileSizeEx` on Windows.
This reduces the number of syscalls needed for determining the file size of an open file from 3 to 1.
It uses the file metadata on Unix with a fallback for files incorrectly
reported as zero-sized. It uses `GetFileSizeEx` on Windows.
This reduces the number of syscalls needed for determining the file size
of an open file from 3 to 1.
UnsafePinned: also include the effects of UnsafeCell
This tackles https://github.com/rust-lang/rust/issues/137750 by including an `UnsafeCell` in `UnsafePinned`, thus imbuing it with all the usual properties of interior mutability (no `noalias` nor `dereferenceable` on shared refs, special treatment by Miri's aliasing model). The soundness issue is not fixed yet because coroutine lowering does not use `UnsafePinned`.
The RFC said that `UnsafePinned` would not permit mutability on shared references, but since then, https://github.com/rust-lang/rust/issues/137750 has demonstrated that this is not tenable. In the face of those examples, I propose that we do the "obvious" thing and permit shared mutable state inside `UnsafePinned`. This seems loosely consistent with the fact that we allow going from `Pin<&mut T>` to `&T` (where the former can be aliased with other pointers that perform mutation, and hence the same goes for the latter) -- but the `as_ref` example shows that we in fact would need to add this `UnsafeCell` even if we didn't have a safe conversion to `&T`, since for the compiler and Miri, `&T` and `Pin<&T>` are basically the same type.
To make this possible, I had to remove the `Copy` and `Clone` impls for `UnsafePinned`.
Tracking issue: https://github.com/rust-lang/rust/issues/125735
Cc ``@rust-lang/lang`` ``@rust-lang/opsem`` ``@Sky9x``
I don't think this needs FCP since the type is still unstable -- we'll finally decide whether we like this approach when `UnsafePinned` is moved towards stabilization (IOW, this PR is reversible). However, I'd still like to make sure that the lang team is okay with the direction I am proposing here.
This was introduced before `#[panic_handler]` was stable, but should no
longer be needed. Additionally, we only need it for
`builtins-test-intrinsics`, not as a dependency of `compiler-builtins`.
Create a crate that handles pulling from and pushing to rust-lang/rust.
This can be invoked with the following:
$ cargo run -p josh-sync -- rustc-pull
$ RUSTC_GIT=/path/to/rust/checkout cargo run -p josh-sync -- rustc-push <username>
The submodule was causing issues in rust-lang/rust, so eliminiate it
here. `build-musl` is also removed from `libm-test`'s default features
so the crate doesn't need to be built by default.
exact_div: add tests
tracking issue: rust-lang/rust#139911
I neglected to add tests in my last PR (rust-lang/rust#141237), so I've added them here.
r? ``@workingjubilee`` (Feel free to reroll, I just picked you since you reviewed the last one.)
Lightly tweak docs for BTree{Map,Set}::extract_if
- Move explanations into comments to match style
- Explain the second examples
- Make variable names match the data structure
Related rust-lang/rust#70530
make `OsString::new` and `PathBuf::new` unstably const
Since #129041, `String::into_bytes` is `const`, which allows making `OsString::new` and `PathBuf::new` unstably const now.
Not sure what the exact process for this is; does it need an ACP?
Improve the documentation of `Display` and `FromStr`, and their interactions
In particular:
- `Display` is not necessarily lossless
- The output of `Display` might not be parseable by `FromStr`, and might
not produce the same value if it is.
- Calling `.parse()` on the output of `Display` is usually a mistake
unless a type's documented output and input formats match.
- The input formats accepted by `FromStr` depend on the type.
This documentation adds no API surface area and makes no guarantees about stability. To the best of my knowledge, everything it says is already established to be true. As such, I don't think it needs an FCP.
- Drop the phrasing "usually a mistake".
- Mention that `Display` may not be lossless.
- Drop a misplaced parenthetical about round-tripping that didn't fit
the paragraph it was in.
In particular:
- `Display` is not necessarily lossless
- The output of `Display` might not be parseable by `FromStr`, and might
not produce the same value if it is.
- Calling `.parse()` on the output of `Display` is usually a mistake
unless a type's documented output and input formats match.
- The input formats accepted by `FromStr` depend on the type.
Remove bootstrap cfgs from library/
These `cfg(bootstrap)` are always false now that rust-lang/rust#119899 has landed, and likewise `cfg(not(bootstrap))` is always true. Therefore, we don't need to wait for the usual stage0 bump to clean these up.
std: abort the process on failure to allocate a TLS key
The panic machinery uses TLS, so panicking if no TLS keys are left can lead to infinite recursion (see https://github.com/rust-lang/rust/issues/140798#issuecomment-2872307377). Rather than having separate logic for the panic count and the thread name, just always abort the process if a TLS key allocation fails. This also has the benefit of aligning the key-based TLS implementation with the documentation, which does not mention that a panic could also occur because of resource exhaustion.
Merge `compiler-builtins` as a Josh subtree
Use the Josh [1] utility to add `compiler-builtins` as a subtree, which
will allow us to stop using crates.io for updates. This is intended to
help resolve some problems when unstable features change and require
code changes in `compiler-builtins`, which sometimes gets trapped in a
bootstrap cycle.
This was done using `josh-filter` built from the r24.10.04 tag:
git fetch https://github.com/rust-lang/compiler-builtins.git 233434412fe7eced8f1ddbfeddabef1d55e493bd
josh-filter ":prefix=library/compiler-builtins" FETCH_HEAD
git merge --allow-unrelated FILTERED_HEAD
The HEAD in the `compiler-builtins` repository is 233434412f ("fix an if
statement that can be collapsed").
[1]: https://github.com/josh-project/josh
This adds an `iter!` macro that can be used to create movable
generators.
This also adds a yield_expr feature so the `yield` keyword can be used
within iter! macro bodies. This was needed because several unstable
features each need `yield` expressions, so this allows us to stabilize
them separately from any individual feature.
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
Co-authored-by: Travis Cross <tc@traviscross.com>
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#141554 (Improve documentation for codegen options)
- rust-lang/rust#141817 (rustc_llvm: add Windows system libs only when cross-compiling from Wi…)
- rust-lang/rust#141843 (Add `visit_id` to ast `Visitor`)
- rust-lang/rust#141881 (Subtree update of `rust-analyzer`)
- rust-lang/rust#141898 ([rustdoc-json] Implement PartialOrd and Ord for rustdoc_types::Id)
- rust-lang/rust#141921 (Disable f64 minimum/maximum tests for arm 32)
- rust-lang/rust#141930 (Enable triagebot `[concern]` functionality)
- rust-lang/rust#141936 (Decouple "reporting in deps" from `FutureIncompatibilityReason`)
- rust-lang/rust#141949 (move `test-float-parse` tool into `src/tools` dir)
r? `@ghost`
`@rustbot` modify labels: rollup
Disable f64 minimum/maximum tests for arm 32
This disables the f64 minimum/maximum tests for the arm-unknown-linux-gnueabihf job. The next release will be supporting cross-compiled doctests, and these tests fail on that platform.
It looks like this was just fixed via https://github.com/llvm/llvm-project/pull/142170, but I assume that will not trickle down to our copy of llvm in the next couple of weeks. Assuming that does get fixed when llvm is updated, then these can be removed.
cc https://github.com/rust-lang/rust/issues/141087
Clarify &mut-methods' docs on sync::OnceLock
Three small changes to the docs of `sync::OnceLock`:
* The docs for `OnceLock::take()` used to [say](https://doc.rust-lang.org/std/sync/struct.OnceLock.html#method.take) "**Safety** is guaranteed by requiring a mutable reference." (emphasis mine). While technically correct, imho its not necessary to even mention safety - as opposed to unsafety - here: Safety never comes up wrt `OnceLock`, as there is (currently) no way to interact with a `OnceLock` in an unsafe way; there are no unsafe methods on `OnceLock`, so there is "safety" guarantee required anywhere. What we simply meant to say is "**Synchronization** is guaranteed...".
* I've add that phrase to the other methods of `OnceLock` which take a `&mut self`, to highlight the fact that having a `&mut OnceLock` guarantees that synchronization with other threads is not required. This is the same as with [`Mutex::get_mut()`](https://doc.rust-lang.org/std/sync/struct.Mutex.html#method.get_mut), [`Cell::get_mut()`](https://doc.rust-lang.org/std/cell/struct.Cell.html#method.get_mut), and others.
* In that spirit, the half-sentence "or being initialized" was removed from `get_mut()`, as there is no way that the `OnceLock` is being initialized while we are holding `&mut` to it. Probably a copy&paste from `.get()`
compiler-builtins has a symlink to the `libm` source directory so the
two crates can share files but still act as two separate crates. This
causes problems with some sysroot-related tooling, however, since
directory symlinks seem to not be supported.
The reason this was a symlink in the first place is that there isn't an
easy for Cargo to publish two crates that share source (building works
fine but publishing rejects `include`d files from parent directories, as
well as nested package roots). However, after the switch to a subtree,
we no longer need to publish compiler-builtins; this means that we can
eliminate the link and just use `#[path]`.
Similarly, the LICENSE file was symlinked so it could live in the
repository root but be included in the package. This is also removed as
it caused problems with the dist job (error from bootstrap's
`tarball.rs`, "generated a symlink in a tarball").
If we need to publish compiler-builtins again for any reason, it would
be easy to revert these changes in a preprocess step.
`binop_common` emits a `SKIP` that is intended to apply only to
`copysign`, but is instead applying to all binary operators. Correct the
general case but leave the currently-failing `maximum_num` tests as a
FIXME, to be resolved separately in [1].
Also simplify skip logic and NaN checking, and add a few more `copysign`
checks.
[1]: https://github.com/rust-lang/compiler-builtins/pull/939
iai-callgrind now correctly exits with error if regressions were found
[1], so we no longer need to check for regressions manually. Remove this
check and instead exit based on the exit status of the benchmark run.
[1] https://github.com/iai-callgrind/iai-callgrind/issues/337
This disables the f64 minimum/maximum tests for the
arm-unknown-linux-gnueabihf job. The next release will be supporting
cross-compiled doctests, and these tests fail on that platform.
It looks like this was just fixed via
https://github.com/llvm/llvm-project/pull/142170, but I assume that will
not trickle down to our copy of llvm in the next couple of weeks.
Assuming that does get fixed when llvm is updated, then these can be
removed.
cc https://github.com/rust-lang/rust/issues/141087
