| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fast-math flags
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #121208 (Convert `delayed_bug`s to `bug`s.)
- #121288 (make rustc_expand translatable)
- #121304 (Add docs for extension proc-macro)
- #121328 (Make --verbose imply -Z write-long-types-to-disk=no)
- #121338 (Downgrade ambiguous_wide_pointer_comparisons suggestions to MaybeIncorrect)
- #121361 (diagnostic items for legacy numeric modules)
- #121375 (Print proper relative path for descriptive name check)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add "algebraic" fast-math intrinsics, based on fast-math ops that cannot return poison
Setting all of LLVM's fast-math flags makes our fast-math intrinsics very dangerous, because some inputs are UB. This set of flags permits common algebraic transformations, but according to the [LangRef](https://llvm.org/docs/LangRef.html#fastmath), only the flags `nnan` (no nans) and `ninf` (no infs) can produce poison.
And this uses the algebraic float ops to fix https://github.com/rust-lang/rust/issues/120720
cc `@orlp`
|
|
diagnostic items for legacy numeric modules
For https://github.com/rust-lang/rust-clippy/pull/12312
Missed these in #121272
r? `@Nilstrieb`
|
|
|
|
|
|
Co-authored-by: Nilstrieb <48135649+Nilstrieb@users.noreply.github.com>
|
|
|
|
docs: add missing "the" to `str::strip_prefix` doc
Fix #121348
|
|
Refactor trait implementations in `core::convert::num`.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
Implement conversion traits using generic `NonZero` type, and refactor all macros to use a consistent format/order of parameters.
r? `@dtolnay`
|
|
Correct the simd_masked_{load,store} intrinsic docs
Explains the uniform pointer being used for these two operations and how elements are offset from it.
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #121167 (resolve: Scale back unloading of speculatively loaded crates)
- #121196 (Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions))
- #121241 (Implement `NonZero` traits generically.)
- #121278 (Remove the "codegen" profile from bootstrap)
- #121286 (Rename `ConstPropLint` to `KnownPanicsLint`)
- #121291 (target: Revert default to the medium code model on LoongArch targets)
- #121302 (Remove `RefMutL` hack in `proc_macro::bridge`)
- #121318 (Trigger `unsafe_code` lint on invocations of `global_asm`)
Failed merges:
- #121206 (Top level error handling)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Implement `NonZero` traits generically.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
r? ````@dtolnay````
|
|
Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions)
The current complexities in `assert_unsafe_precondition` are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying.
To avoid this, we always inline the check when building with debug assertions.
Numbers (compiling stage1 library after touching core):
- master: 80s
- just adding `#[inline(always)]` to the `cfg(bootstrap)` `debug_assertions` (equivalent to a bootstrap bump (uhh, i just realized that i was on a slightly outdated master so this bump might have happened already), (#121112)): 67s
- this: 54s
So this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding `#[rustc_no_mir_inline]` #121114) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow".
Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)!
r? ```@saethlin``` (or anyone else if someone wants to review this)
fixes #121110, supposedly
|
|
Use intrinsics::debug_assertions in debug_assert_nounwind
This is the first item in https://github.com/rust-lang/rust/issues/120848.
Based on the benchmarking in this PR, it looks like, for the programs in our benchmark suite, enabling all these additional checks does not introduce significant compile-time overhead, with the single exception of `Alignment::new_unchecked`. Therefore, I've added `#[cfg(debug_assertions)]` to that one call site, so that it remains compiled out in the distributed standard library.
The trailing commas in the previous calls to `debug_assert_nounwind!` were causing the macro to expand to `panic_nouwnind_fmt`, which requires more work to set up its arguments, and that overhead alone is measured between this perf run and the next: https://github.com/rust-lang/rust/pull/120863#issuecomment-1937423502
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Per @dtolnay suggestion in https://github.com/serde-rs/serde/pull/2697#issuecomment-1940376414 - attempt to speed up performance in the cases of a simple string format without arguments:
```rust
write!(f, "text") -> f.write_str("text")
```
|
|
|
|
|
|
It showed up with 3% execution time in a compiler profile.
|
|
This change was prompted by the stage1 compiler spending 4% of its time
when compiling the polymorphic-recursion MIR opt test in `unlikely`.
Intrinsic fallback bodies like `unlikely` should always be inlined, it's
very silly if they are not. To do this, we enable the fallback bodies to
be cross-crate inlineable. Not that this matters for our workloads since
the compiler never actually _uses_ the "fallback bodies", it just uses
whatever was cfg(bootstrap)ped, so I've also added `#[inline]` to those.
|
|
The current complexities in `assert_unsafe_precondition` are delicately
balancing several concerns, among them compile times for the cases where
there are no debug assertions. This comes at a large runtime cost when
the assertions are enabled, making the debug assertion compiler a lot
slower, which is very annoying.
To avoid this, we always inline the check when building with debug
assertions.
Numbers (compiling stage1 library after touching core):
- master: 80s
- just adding `#[inline(always)]` to the `cfg(bootstrap)`
`debug_assertions`: 67s
- this: 54s
So this seems like a good solution. I think we can still get
the same run-time perf improvements for other users too by
massaging this code further (see my other PR about adding
`#[rustc_no_mir_inline]`) but this is a simpler step that
solves the imminent problem of "holy shit my rustc is sooo slow".
Funny consequence: This now means compiling the standard library with
dbeug assertions makes it faster (than without, when using debug
assertions downstream)!
|
|
Add diagnostic items for legacy numeric constants
For rust-lang/rust-clippy#12312
|
|
Add `Future` and `IntoFuture` to the 2024 prelude
Implements rust-lang/rfcs#3509.
|
|
r=Mark-Simulacrum
Store core::str::CharSearcher::utf8_size as u8
This is already relied on being smaller than u8 due to the `safety invariant: utf8_size must be less than 5`, so this helps LLVM optimize and maybe improve copies due to padding instead of unused bytes.
|
|
|
|
Implements RFC 3509.
|
|
|
|
|
|
Specialize flattening iterators with only one inner item
For iterators like `Once` and `option::IntoIter` that only ever have a
single item at most, the front and back iterator states in `FlatMap` and
`Flatten` are a waste, as they're always consumed already. We can use
specialization for these types to simplify the iterator methods.
It's a somewhat common pattern to use `flatten()` for options and
results, even recommended by [multiple][1] [clippy][2] [lints][3]. The
implementation is more efficient with `filter_map`, as mentioned in
[clippy#9377], but this new specialization should close some of that
gap for existing code that flattens.
[1]: https://rust-lang.github.io/rust-clippy/master/#filter_map_identity
[2]: https://rust-lang.github.io/rust-clippy/master/#option_filter_map
[3]: https://rust-lang.github.io/rust-clippy/master/#result_filter_map
[clippy#9377]: https://github.com/rust-lang/rust-clippy/issues/9377
|
|
|
|
Give some intrinsics fallback bodies
cc #93145
|
|
r=Nilstrieb
Add examples to document the return type of quickselect functions
Currently, `select_nth_unstable`, `select_nth_unstable_by`, and `select_nth_unstable_by_key`'s examples do not show how to use the return values of the functions in an example, so this PR adds that in.
Note: I didn't know what to call the parameters, so I settled on lesser, median, greater because the example is used for median finding so I retained that naming for the pivot, but lesser and greater are poor names for the example that sorts in descending order, because lesser and greater are then flipped.
I think it's common to say "lo" and "hi" for low and high respectively, but that's also not great when the comparator flips the elements. Otherwise, "left" and "right" are also commonly used but I think that's poor naming because some languages read right to left so those names are also unintuitive.
Lesser and greater are also not that great but I found a test that used `less`, `equal`, `greater` so I took that: https://github.com/rust-lang/rust/blob/dfa88b328f969871d12dba3b2c0257ab3ea6703a/library/core/tests/slice.rs#L1962
|
|
Make `NonZero::get` generic.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
Depends on https://github.com/rust-lang/rust/pull/120521.
r? `@dtolnay`
|
|
Make `io::BorrowedCursor::advance` safe
This also keeps the old `advance` method under `advance_unchecked` name.
This makes pattern like `std::io::default_read_buf` safe to write.
|
|
|
|
|
|
|
|
For iterators like `Once` and `option::IntoIter` that only ever have a
single item at most, the front and back iterator states in `FlatMap` and
`Flatten` are a waste, as they're always consumed already. We can use
specialization for these types to simplify the iterator methods.
It's a somewhat common pattern to use `flatten()` for options and
results, even recommended by [multiple][1] [clippy][2] [lints][3]. The
implementation is more efficient with `filter_map`, as mentioned in
[clippy#9377], but this new specialization should close some of that
gap for existing code that flattens.
[1]: https://rust-lang.github.io/rust-clippy/master/#filter_map_identity
[2]: https://rust-lang.github.io/rust-clippy/master/#option_filter_map
[3]: https://rust-lang.github.io/rust-clippy/master/#result_filter_map
[clippy#9377]: https://github.com/rust-lang/rust-clippy/issues/9377
|
|
`select_nth_unstable_by`, and `select_nth_unstable_by_key`.
|
