| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fix OsString::from_encoded_bytes_unchecked description
fixes #133010
|
|
Add an example of using `carrying_mul_add` to write wider multiplication
Just the basic quadratic version that you wouldn't actually use for really-big integers, but it's nice and short so is useful as for a demonstration of why you might find `carrying_mul_add` useful :)
cc #85532 ``````@clarfonthey``````
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Introduce a way to ignore the results of icount regression tests, by
specifying `allow-regressions` in the pull request body. This should
apply to both pull requests and the merges based on them, since `gh pr
view` automatically handles both.
|
|
Similar to changes for `icount` benchmarks, this ensures we aren't
testing the throughput of architecture instructions.
|
|
These benchmarks are fast to run, so the time cost here is pretty
minimal. Running softfloat benchmarks just ensures that we don't e.g.
test the performance of `_mm_sqrt_ss` rather than our implementation,
and running without softfloat gives us a way to see the effect of arch
intrinsics.
|
|
Outline panicking code for `LocalKey::with`
See https://github.com/rust-lang/rust/pull/115491 for prior related modifications.
https://godbolt.org/z/MTsz87jGj shows a reduction of the code size for TLS accesses.
|
|
Enable `unreachable_pub` lint in core
This PR enables the [`unreachable_pub`](https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unreachable-pub) as warn in `core`, `rtstartup` and `panic_unwind`.
The motivation is similar to the compiler [MCP: Enable deny(unreachable_pub) on `rustc_*` crates](https://github.com/rust-lang/compiler-team/issues/773#issue-2467219005) :
> "Where is this thing used?" is a question I ask all the time when reading unfamiliar code. Because of this, I generally find it annoying when things are marked with a more permissive visibility than necessary. "This thing marked pub, which other crates is it used in? Oh, it's not used in any other crates."
Another motivation is to help to lint by utilizing it in-tree and seeing it's limitation in more complex scenarios.
The diff was mostly generated with `./x.py fix --stage 1 library/core/ -- --broken-code`, as well as manual edits for code in macros, generated code and other targets.
r? libs
|
|
The free arm64 Linux runners are now available [1]. Switch to using this
image in CI, and enable tests against MPFR since this is now a native
platform.
[1]: https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/
|
|
Recognise new IPv6 documentation range from IETF RFC 9637
This PR adds the `3fff::/20` range defined by [IETF RFC 9637](https://datatracker.ietf.org/doc/rfc9637/) to those ranges which `Ipv6Addr::is_documentation` recognises as a documentation IP.
See also: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
Unstable tracking issue: #27709
|
|
Reexport likely/unlikely in std::hint
Since `likely`/`unlikely` should be working now, we could reexport them in `std::hint`. I'm not sure if this is already approved or if it requires approval
Tracking issue: #26179
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Correct counting to four in cell module docs
It could also be argued that `OnceCell<T>` and `LazyCell<T>` don't really provide safe interior mutability in different ways. But it's a vague enough claim that I'm not sure it's worth being pedantic about.
|
|
doc: Point to methods on `Command` as alternatives to `set/remove_var`
Make these methods more discoverable, as configuring a child process is a common reason for manipulating the environment.
|
|
|
|
RalfJung:remove-dead-rustc_allowed_through_unstable_modules, r=Mark-Simulacrum
Remove dead rustc_allowed_through_unstable_modules for std::os::fd contents
As far as I was able to reconstruct, the history here is roughly as follows:
- https://github.com/rust-lang/rust/pull/99723 added some `rustc_allowed_through_unstable_modules` to the types in `std::os::fd::raw` since they were accessible on stable via the unstable `std::os::wasi::io::AsRawFd` path. (This was needed to fix https://github.com/rust-lang/rust/issues/99502.)
- Shortly thereafter, https://github.com/rust-lang/rust/pull/98368 re-organized things so that instead of re-exporting from an internal `std::os::wasi::io::raw`, `std::os::wasi::io::AsRawFd` is now directly re-exported from `std::os::fd`. This also made `library/std/src/os/wasi/io/raw.rs` entirely dead code as far as I can tell, it's not imported by anything any more.
- Shortly thereafter, https://github.com/rust-lang/rust/pull/103308 stabilizes `std::os::wasi::io`, so `rustc_allowed_through_unstable_modules` is not needed any more to access `std::os::wasi::io::AsRawFd`. There is even a comment in `library/std/src/os/wasi/io/raw.rs` saying the attribute can be removed now, but that file is dead code so it is not touched as part of the stabilization.
I did a grep for `pub use crate::os::fd` and all the re-exports I could find are in stable modules. So given all that, we can remove the `rustc_allowed_through_unstable_modules` (hoping they are not also re-exported somewhere else, it's really hard to be sure about this).
I have checked that std still builds after this PR on the wasm32-wasip2 target.
|
|
further improve panic_immediate_abort by removing rtprintpanic! messages
Reduces binary size using `panic_immediate_abort` by removing strings used by `rtprintpanic!`.
for `main.rs`
```rust
fn main() {
println!("Hello, world!");
}
```
with `Cargo.toml`
```toml
[package]
name = "tst"
version = "0.1.0"
edition = "2024"
[dependencies]
[profile.release]
lto = true
codegen-units = 1
panic = "abort"
```
and build with `RUSTFLAGS="-Zlocation-detail=none -Zfmt-debug=none" cargo +stage-1 b -r -Z build-std=std,panic_abort -Z build-std-features=optimize_for_size,panic_immediate_abort` for `x86_64-unknown-linux-gnu`
This reduces size:
| before | after | type |
| - | - | - |
| 25256 | 21880 | unstripped |
| 18072 | 15288 | stripped |
|
|
Just the basic quadratic version that you wouldn't actually want for a true bigint, but it's nice and short so is useful as an example :)
|
|
This commit adds the 3fff::/20 range defined by RFC9637 to those ranges which Ipv6Addr::is_documentation recognises as a documentation IP.
|
|
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 13 packages to latest compatible versions
Updating anstyle-wincon v3.0.6 -> v3.0.7
Updating bitflags v2.7.0 -> v2.8.0
Updating chrono-tz v0.10.0 -> v0.10.1
Updating js-sys v0.3.76 -> v0.3.77
Updating log v0.4.22 -> v0.4.25
Updating miniz_oxide v0.8.2 -> v0.8.3
Updating uuid v1.11.1 -> v1.12.0
Updating valuable v0.1.0 -> v0.1.1
Updating wasm-bindgen v0.2.99 -> v0.2.100
Updating wasm-bindgen-backend v0.2.99 -> v0.2.100
Updating wasm-bindgen-macro v0.2.99 -> v0.2.100
Updating wasm-bindgen-macro-support v0.2.99 -> v0.2.100
Updating wasm-bindgen-shared v0.2.99 -> v0.2.100
note: pass `--verbose` to see 41 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating miniz_oxide v0.8.2 -> v0.8.3
note: pass `--verbose` to see 4 unchanged dependencies behind latest
rustbook dependencies:
Locking 12 packages to latest compatible versions
Updating anstyle-wincon v3.0.6 -> v3.0.7
Updating bitflags v2.7.0 -> v2.8.0
Updating cc v1.2.8 -> v1.2.10
Updating js-sys v0.3.76 -> v0.3.77
Updating log v0.4.22 -> v0.4.25
Updating miniz_oxide v0.8.2 -> v0.8.3
Adding rustversion v1.0.19
Updating wasm-bindgen v0.2.99 -> v0.2.100
Updating wasm-bindgen-backend v0.2.99 -> v0.2.100
Updating wasm-bindgen-macro v0.2.99 -> v0.2.100
Updating wasm-bindgen-macro-support v0.2.99 -> v0.2.100
Updating wasm-bindgen-shared v0.2.99 -> v0.2.100
```
|
|
fixes 135710
|
|
Improve `select_nth_unstable` documentation clarity
* Instead uses `before` and `after` variable names in the example
where `greater` and `lesser` are flipped.
* Uses `<=` and `>=` instead of "less than or equal to" and "greater
than or equal to" to make the docs more concise.
* General attempt to remove unnecessary words and be more precise. For
example it seems slightly wrong to say "its final sorted position",
since this implies there is only one sorted position for this element.
|
|
Temporarily bring back `Rvalue::Len`
r? `@compiler-errors` as requested in https://github.com/rust-lang/rust/issues/135671#issuecomment-2599580364
> However, in the mean time, I'd rather we not crunch trying to find and more importantly validate the soundness of a solution 🤔
Agreed. To fix the IMO P-critical #135671 for which we somehow didn't have test coverage, this PR temporarily reverts:
- https://github.com/rust-lang/rust/pull/133734
- its bugfix https://github.com/rust-lang/rust/pull/134371
- https://github.com/rust-lang/rust/pull/134330
cc `@scottmcm`
I added the few samples from that issue as a test, but we can add more in the future, in particular it seems `@steffahn` [will work on that](https://github.com/rust-lang/rust/issues/135671#issuecomment-2599714354).
Fixes #135671. And if we want to land this, it should also be nominated for beta backport.
|
|
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
|
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
|
