| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Make {integer}::from_str_radix constant
This commit makes FromStr on integers constant so that `const x: u32 = "23".parse();` works. More practical use-case is with environment variables at build time as discussed in https://github.com/rust-lang/rfcs/issues/1907.
Tracking issue #59133.
ACP: https://github.com/rust-lang/libs-team/issues/74
|
|
Improve wording in std::any explanation
Prefer 'log' over 'log out' to avoid confusion, and use backticks consistently.
|
|
|
|
This is just one part of the MCP, but it's the one that IMHO removes the most noise from the standard library code.
Seems net simpler this way, since MIR already supported heterogeneous shifts anyway, and thus it's not more work for backends than before.
|
|
This is an alternative to #121920
|
|
Stabilize `unchecked_{add,sub,mul}`
Tracking issue: #85122
I think we might as well just stabilize these basic three. They're the ones that have `nuw`/`nsw` flags in LLVM.
Notably, this doesn't include the potentially-more-complex or -more-situational things like `unchecked_neg` or `unchecked_shr` that are under different feature flags.
To quote Ralf https://github.com/rust-lang/rust/issues/85122#issuecomment-1681669646,
> Are there any objections to stabilizing at least `unchecked_{add,sub,mul}`? For those there shouldn't be any surprises about what their safety requirements are.
*Semantially* these are [already available on stable, even in `const`, via](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bdb1ff889b61950897f1e9f56d0c9a36) `checked_*`+`unreachable_unchecked`. So IMHO we might as well just let people write them directly, rather than try to go through a `let Some(x) = x.checked_add(y) else { unsafe { hint::unreachable_unchecked() }};` dance.
I added additional text to each method to attempt to better describe the behaviour and encourage `wrapping_*` instead.
r? rust-lang/libs-api
|
|
|
|
Add detection of [Partial]Ord methods in the `ambiguous_wide_pointer_comparisons` lint
Partially addresses https://github.com/rust-lang/rust/issues/121264 by adding diagnostics items for PartialOrd and Ord methods, detecting such diagnostics items as "binary operation" and suggesting the correct replacement.
I also took the opportunity to change the suggestion to use new methods `.cast()` on `*mut T` an d `*const T`.
|
|
|
|
Prefer 'log' over 'log out' to avoid confusion, and use backticks consistently.
|
|
Because `HashMap::with_hasher` constness is being stabilized this will
in turn allow creating empty HashMap<K,V,BuildHasherDefault<H>> in const
context for any H: Default + Hasher.
|
|
|
|
|
|
Optimize `core::char::CaseMappingIter`
Godbolt says this saves a few instructions…
`@rustbot` label T-libs A-layout C-optimization
|
|
Useful for debugging
|
|
Eliminate `UbChecks` for non-standard libraries
The purpose of this PR is to allow other passes to treat `UbChecks` as constants in MIR for optimization after #122629.
r? RalfJung
|
|
Codegen const panic messages as function calls
This skips emitting extra arguments at every callsite (of which there
can be many). For a librustc_driver build with overflow checks enabled,
this cuts 0.7MB from the resulting shared library (see [perf]).
A sample improvement from nightly:
```
leaq str.0(%rip), %rdi
leaq .Lalloc_d6aeb8e2aa19de39a7f0e861c998af13(%rip), %rdx
movl $25, %esi
callq *_ZN4core9panicking5panic17h17cabb89c5bcc999E@GOTPCREL(%rip)
```
to this PR:
```
leaq .Lalloc_d6aeb8e2aa19de39a7f0e861c998af13(%rip), %rdi
callq *_RNvNtNtCsduqIKoij8JB_4core9panicking11panic_const23panic_const_div_by_zero@GOTPCREL(%rip)
```
[perf]: https://perf.rust-lang.org/compare.html?start=a7e4de13c1785819f4d61da41f6704ed69d5f203&end=64fbb4f0b2d621ff46d559d1e9f5ad89a8d7789b&stat=instructions:u
|
|
Split off part of <https://github.com/rust-lang/rust/pull/122470> so the
compiler doesn't ICE because it expects primitives to have some minimal
traits.
Fixes <https://github.com/rust-lang/rust/issues/123074>
|
|
Bump Unicode printables to version 15.1, align to unicode_data
r? `@Manishearth`
Thanks!
|
|
|
|
`num::NonZero::get` can be 1 transmute instead of 2
Just something I noticed in passing. No need for a `match` in here to call `unreachable_unchecked`, as `transmute_unchecked` will add the appropriate `llvm.assume` <https://rust.godbolt.org/z/W5hjeETnc>.
|
|
chore: fix some comments
|
|
Clarify atomic bit validity
The previous definition used the phrase "representation", which is ambiguous given the current state of memory model nomenclature in Rust. For integer types and for `AtomicPtr<T>`, the new wording clarifies that size and bit validity are guaranteed to match the corresponding native integer type/`*mut T`. For `AtomicBool`, the new wording clarifies that size, alignment, and bit validity are guaranteed to match `bool`.
Note that we use the phrase "size and alignment" rather than "layout" since the latter term also implies that the field types are the same. This isn't true - `AtomicXxx` doesn't store an `xxx`, but rather an `UnsafeCell<xxx>`. This distinction is important for some `unsafe` code, which needs to reason about the presence or absence of interior mutability in order to ensure that their code is sound (see e.g. https://github.com/google/zerocopy/issues/251).
|
|
|
|
Signed-off-by: xiaoxiangxianzi <zhaoyizheng@outlook.com>
|
|
|
|
See also https://github.com/rust-lang/rust/issues/74465#issuecomment-1676522051
Signed-off-by: tison <wander4096@gmail.com>
|
|
Soft-destabilize `RustcEncodable` & `RustcDecodable`, remove from prelude in next edition
cc rust-lang/libs-team#272
Any use of `RustcEncodable` and `RustcDecodable` now triggers a deny-by-default lint. The derives have been removed from the 2024 prelude. I specifically chose **not** to document this in the module-level documentation, as the presence in existing preludes is not documented (which I presume is intentional).
This does not implement the proposed change for `rustfix`, which I will be looking into shortly.
With regard to the items in the preludes being stable, this should not be an issue because #15702 has been resolved.
r? libs-api
|
|
Require `DerefMut` and `DerefPure` on `deref!()` patterns when appropriate
Waiting on the deref pattern syntax pr to merge
r? nadrieril
|
|
|
|
|
|
|
|
Import the 2021 prelude in the core crate
The `core` crate currently imports the v1 prelude
https://github.com/rust-lang/rust/blob/b3df0d7e5ef5f7dbeeca3fb289c65680ad013f87/library/core/src/lib.rs#L285-L287
This recently caused an issue when updating the `portable-simd` subtree since it was using a trait that was added to the 2021 prelude: https://github.com/rust-lang/rust/pull/122905#discussion_r1536228822
To make it easier to have a consistent build environment for subtrees and submodules that get included in `core`, we will now import the 2021 prelude into `core`.
Fixes #122912
r? `@Nilstrieb`
|
|
Update stdarch submodule
r? ```@Amanieu```
|
|
|
|
|
|
Clarify transmute example
The example claims using an iterator will copy the entire vector, but this is not true in practice thanks to internal specializations in the stdlib (see https://godbolt.org/z/cnxo3MYs5 for confirmation that this doesn't reallocate nor iterate over the vec's elements). Since neither the copy nor the optimization is guaranteed I opted for saying that they _may_ happen.
|
|
|
|
This saves some debug and scope metadata in every single function that calls it.
Normally wouldn't be worth it, but with the derives there's *so* many of these.
|
|
Rename `Arguments::as_const_str` to `as_statically_known_str`
While `const` has a particular meaning about language guarantees, here
we need a fuzzier notion like whether constant propagation was
effective, and `statically_known` is the best term we have for now.
r? ``@RalfJung``
|
|
|
|
|
|
fix typo of endianness
fix typo
endianess -> endianness
|
|
While `const` has a particular meaning about language guarantees, here
we need a fuzzier notion like whether constant propagation was
effective, and `statically_known` is the best term we have for now.
|
|
|
|
core/panicking: fix outdated comment
Looks like this function got renamed/changed at some point and the comment did not get updated.
r? `@m-ou-se`
|
|
transmute: caution against int2ptr transmutation
This came up in https://github.com/rust-lang/rust/pull/121282.
Cc ```@saethlin``` ```@scottmcm```
Eventually we'll add a proper description of provenance that we can reference, but that's a bunch of work and it's unclear who will have the time to do that when. Meanwhile, let's at least do what we can without mentioning provenance explicitly.
|
|
|
|
refactor check_{lang,library}_ub: use a single intrinsic
This enacts the plan I laid out [here](https://github.com/rust-lang/rust/pull/122282#issuecomment-1996917998): use a single intrinsic, called `ub_checks` (in aniticpation of https://github.com/rust-lang/compiler-team/issues/725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library.
This makes it easier to do something like https://github.com/rust-lang/rust/pull/122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time.
The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics.
r? `@saethlin`
|
|
|
