| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 4 pull requests
Successful merges:
- #131790 (Document textual format of SocketAddrV{4,6})
- #131983 (Stabilize shorter-tail-lifetimes)
- #132097 (sanitizer.md: LeakSanitizer is not supported on aarch64 macOS)
- #132107 (Remove visit_expr_post from ast Visitor)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Document textual format of SocketAddrV{4,6}
This commit adds new "Textual representation" documentation sections to SocketAddrV4 and SocketAddrV6, by analogy to the existing "textual representation" sections of Ipv4Addr and Ipv6Addr.
Rationale: Without documentation about which formats are actually accepted, it's hard for a programmer to be sure that their code will actually behave as expected when implementing protocols that require support (or rejection) for particular representations. This lack of clarity can in turn can lead to ambiguities and security problems like those discussed in RFC 6942.
(I've tried to describe the governing RFCs or standards where I could, but it's possible that the actual implementers had something else in mind. I could not find any standards that corresponded _exactly_ to the one implemented in SocketAddrv6, but I have linked the relevant documents that I could find.)
|
|
|
|
This commit adds new "Textual representation" documentation sections to
SocketAddrV4 and SocketAddrV6, by analogy to the existing
"textual representation" sections of Ipv4Addr and Ipv6Addr.
Rationale: Without documentation about which formats are actually
accepted, it's hard for a programmer to be sure that their code
will actually behave as expected when implementing protocols that
require support (or rejection) for particular representations.
This lack of clarity can in turn can lead to ambiguities and
security problems like those discussed in RFC 6942.
(I've tried to describe the governing RFCs or standards where I
could, but it's possible that the actual implementers had something
else in mind. I could not find any standards that corresponded
_exactly_ to the one implemented in SocketAddrv6, but I have linked
the relevant documents that I could find.)
|
|
|
|
Rename Receiver -> LegacyReceiver
As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait.
This PR renames the old trait to get it out the way. Naming is hard. Options considered included:
* HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver
These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether.
Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages.
It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency.
This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874
r? `@wesleywiser`
|
|
Fix a typo in documentation of `pointer::sub_ptr()`
Just a typo in docs.
|
|
Clarify documentation of `ptr::dangling()` function
Also fixes the safety comment in `NonNull::dangling()` function.
Fixes #132004.
|
|
"innermost", "outermost", "leftmost", and "rightmost" don't need hyphens
These are all standard dictionary words and don't require hyphenation.
-----
Encountered an instance of this in error messages and it bugged me, so I
figured I'd fix it across the entire codebase.
|
|
Vectorized SliceContains
Godbolt for the u32 case: https://rust.godbolt.org/z/exT9xYWGs
Unsure about:
- Should align_to be used? It didn't seem to matter in my benchmark but maybe I was lucky with alignment?
- Should u8/i8 also be implemented? Currently uses memchr (SWAR)
Some benchmarks on x86 (contains called on an array with no matches, worst case may be slightly worse):
## Large N
## Small N
|
|
|
|
|
|
|
|
move derive_smart_pointer into removed set
|
|
|
|
|
|
These are all standard dictionary words and don't require hyphenation.
|
|
Run most `core::num` tests in const context too
This adds some infrastructure for something I was going to use in #131566, but it felt worthwhile enough on its own to merge/discuss separately.
Essentially, right now we tend to rely on UI tests to ensure that things work in const context, rather than just using library tests. This uses a few simple macro tricks to make it *relatively* painless to execute tests in both runtime and compile-time context. And this only applies to the numeric tests, and not anything else.
Recommended to review without whitespace in the diff.
cc `@RalfJung`
|
|
As part of the "arbitrary self types v2" project, we are going to
replace the current `Receiver` trait with a new mechanism based on a
new, different `Receiver` trait.
This PR renames the old trait to get it out the way. Naming is hard.
Options considered included:
* HardCodedReceiver (because it should only be used for things in the
standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver
These are all bad names, but fortunately this will be temporary.
Assuming the new mechanism proceeds to stabilization as intended, the
legacy trait will be removed altogether.
Although we expect this trait to be used only in the standard library,
we suspect it may be in use elsehwere, so we're landing this change
separately to identify any surprising breakages.
It's known that this trait is used within the Rust for Linux project; a
patch is in progress to remove their dependency.
This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874
r? @wesleywiser
|
|
`rt::Argument`: elide lifetimes
`@rustbot` label +C-cleanup
|
|
update ABI compatibility docs for new option-like rules
Documents the rules decided [here](https://github.com/rust-lang/rust/pull/130628#issuecomment-2402761599) for our ABI compatibility rules.
Long-term this should be moved to the reference, but for now this is what we got.
Cc `@rust-lang/lang` `@rust-lang/opsem`
|
|
|
|
|
|
This comes with a big docs rewrite.
|
|
|
|
|
|
AnthonyMikh:AnthonyMikh/repeat_n-is-not-that-special-anymore, r=jhpratt
Remove outdated documentation for `repeat_n`
After #106943, which made `Take<Repeat<I>>` implement `ExactSizeIterator`, part of documentation about difference from `repeat(x).take(n)` is no longer valid.
````@rustbot```` labels: +A-docs, +A-iterators
|
|
Partially stabilize const_pin
Tracking issue #76654.
Eight of these methods can be made const-stable. The remainder are blocked on #73255.
|
|
Missing parenthesis
the line was missing closing parenthesis
|
|
After rust/#106943 the part about `ExactSizeIterator` is no longer valid
|
|
Avoid superfluous UB checks in `IndexRange`
`IndexRange::len` is justified as an overall invariant, and
`take_prefix` and `take_suffix` are justified by local branch
conditions. A few more UB-checked calls remain in cases that are only
supported locally by `debug_assert!`, which won't do anything in
distributed builds, so those UB checks may still be useful.
We generally expect core's `#![rustc_preserve_ub_checks]` to optimize
away in user's release builds, but the mere presence of that extra code
can sometimes inhibit optimization, as seen in #131563.
|
|
the line was missing closing parenthesis
|
|
r=Noratrieb
Do not run test where it cannot run
This was seen on Ferrocene, where we have a custom test target that does not have unwind support
|
|
optimize str.replace
Adds a fast path for str.replace for the ascii to ascii case. This allows for autovectorizing the code. Also should this instead be done with specialization? This way we could remove one branch. I think it is the kind of branch that is easy to predict though.
Benchmark for the fast path (replace all "a" with "b" in the rust wikipedia article, using criterion) :
| N | Speedup | Time New (ns) | Time Old (ns) |
|----------|---------|---------------|---------------|
| 2 | 2.03 | 13.567 | 27.576 |
| 8 | 1.73 | 17.478 | 30.259 |
| 11 | 2.46 | 18.296 | 45.055 |
| 16 | 2.71 | 17.181 | 46.526 |
| 37 | 4.43 | 18.526 | 81.997 |
| 64 | 8.54 | 18.670 | 159.470 |
| 200 | 9.82 | 29.634 | 291.010 |
| 2000 | 24.34 | 81.114 | 1974.300 |
| 20000 | 30.61 | 598.520 | 18318.000 |
| 1000000 | 29.31 | 33458.000 | 980540.000 |
|
|
This was seen on Ferrocene, where we have a custom test target that does not have unwind support
|
|
Rollup of 9 pull requests
Successful merges:
- #130989 (Don't check unsize goal in MIR validation when opaques remain)
- #131657 (Rustfmt `for<'a> async` correctly)
- #131691 (Delay ambiguous intra-doc link resolution after `Cache` has been populated)
- #131730 (Refactor some `core::fmt` macros)
- #131751 (Rename `can_coerce` to `may_coerce`, and then structurally resolve correctly in the probe)
- #131753 (Unify `secondary_span` and `swap_secondary_and_primary` args in `note_type_err`)
- #131776 (Emscripten: Xfail backtrace ui tests)
- #131777 (Fix trivially_copy_pass_by_ref in stable_mir)
- #131778 (Fix needless_lifetimes in stable_mir)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Refactor some `core::fmt` macros
While looking at the macros in `core::fmt`, find that the macros are not well organized. So I created a patch to fix it.
[`core/src/fmt/num.rs`](https://github.com/rust-lang/rust/blob/master/library/core/src/fmt/num.rs)
* `impl_int!` and `impl_uint!` macro are **completly** same. It would be better to combine for readability
* `impl_int!` has a problem that the indenting is not uniform. It has unified into 4 spaces
* `debug` macro in `num` renamed to `impl_Debug`, And it was moved to a position close to the `impl_Display`.
[`core/src/fmt/float.rs`](https://github.com/rust-lang/rust/blob/master/library/core/src/fmt/float.rs)
[`core/src/fmt/nofloat.rs`](https://github.com/rust-lang/rust/blob/master/library/core/src/fmt/nofloat.rs)
* `floating` macro now receive multiple idents at once. It makes the code cleaner.
* Modified the panic message more clearly in fallback function of `cfg(no_fp_fmt_parse)`
|
|
Rollup of 8 pull requests
Successful merges:
- #130822 (Add `from_ref` and `from_mut` constructors to `core::ptr::NonNull`.)
- #131381 (Implement edition 2024 match ergonomics restrictions)
- #131594 (rustdoc: Rename "object safe" to "dyn compatible")
- #131686 (Add fast-path when computing the default visibility)
- #131699 (Try to improve error messages involving aliases in the solver)
- #131757 (Ignore lint-non-snake-case-crate#proc_macro_ on targets without unwind)
- #131783 (Fix explicit_iter_loop in rustc_serialize)
- #131788 (Fix mismatched quotation mark)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add `from_ref` and `from_mut` constructors to `core::ptr::NonNull`.
Relevant tracking issue: #130823
The `core::ptr::NonNull` type should have the convenience constructors `from_ref` and `from_mut` for parity with `core::ptr::from_ref` and `core::ptr::from_mut`.
Although the type in question already implements `From<&T>` and `From<&mut T>`, these new functions also carry the ability to be used in constant expressions (due to not being behind a trait).
|
|
Bump bootstrap compiler to 1.83.0-beta.1
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday
|
|
Mark the unstable LazyCell::into_inner const
Other cell `into_inner` functions are const and there shouldn't be any problem here. Make the unstable `LazyCell::into_inner` const under the same gate as its stability (`lazy_cell_into_inner`).
Tracking issue: https://github.com/rust-lang/rust/issues/125623
|
|
|
|
(cherry picked from commit 567fd9610cbfd220844443487059335d7e1ff021)
|
|
rename RcBox to RcInner for consistency
Arc uses ArcInner too (created in collaboration with `@aDotInTheVoid` and `@WaffleLapkin` )
|
|
Make some float methods unstable `const fn`
Some float methods are now `const fn` under the `const_float_methods` feature gate.
I also made some unstable methods `const fn`, keeping their constness under their respective feature gate.
In order to support `min`, `max`, `abs` and `copysign`, the implementation of some intrinsics had to be moved from Miri to rustc_const_eval (cc `@RalfJung).`
Tracking issue: https://github.com/rust-lang/rust/issues/130843
```rust
impl <float> {
// #[feature(const_float_methods)]
pub const fn recip(self) -> Self;
pub const fn to_degrees(self) -> Self;
pub const fn to_radians(self) -> Self;
pub const fn max(self, other: Self) -> Self;
pub const fn min(self, other: Self) -> Self;
pub const fn clamp(self, min: Self, max: Self) -> Self;
pub const fn abs(self) -> Self;
pub const fn signum(self) -> Self;
pub const fn copysign(self, sign: Self) -> Self;
// #[feature(float_minimum_maximum)]
pub const fn maximum(self, other: Self) -> Self;
pub const fn minimum(self, other: Self) -> Self;
// Only f16/f128 (f32/f64 already const)
pub const fn is_sign_positive(self) -> bool;
pub const fn is_sign_negative(self) -> bool;
pub const fn next_up(self) -> Self;
pub const fn next_down(self) -> Self;
}
```
r? libs-api
try-job: dist-s390x-linux
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #122670 (Fix bug where `option_env!` would return `None` when env var is present but not valid Unicode)
- #131095 (Use environment variables instead of command line arguments for merged doctests)
- #131339 (Expand set_ptr_value / with_metadata_of docs)
- #131652 (Move polarity into `PolyTraitRef` rather than storing it on the side)
- #131675 (Update lint message for ABI not supported)
- #131681 (Fix up-to-date checking for run-make tests)
- #131702 (Suppress import errors for traits that couldve applied for method lookup error)
- #131703 (Resolved python deprecation warning in publish_toolstate.py)
- #131710 (Remove `'apostrophes'` from `rustc_parse_format`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Two macros are exactly the same.
|
