| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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`
|
|
|
|
|
|
library
|
|
These macros and functions are not intrinsics, after all.
|
|
Rollup of 11 pull requests
Successful merges:
- #120577 (Stabilize slice_split_at_unchecked)
- #122698 (Cancel `cargo update` job if there's no updates)
- #122780 (Rename `hir::Local` into `hir::LetStmt`)
- #122915 (Delay a bug if no RPITITs were found)
- #122916 (docs(sync): normalize dot in fn summaries)
- #122921 (Enable more mir-opt tests in debug builds)
- #122922 (-Zprint-type-sizes: print the types of awaitees and unnamed coroutine locals.)
- #122927 (Change an ICE regression test to use the original reproducer)
- #122930 (add panic location to 'panicked while processing panic')
- #122931 (Fix some typos in the pin.rs)
- #122933 (tag_for_variant follow-ups)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix some typos in the pin.rs
|
|
add panic location to 'panicked while processing panic'
Fixes https://github.com/rust-lang/rust/issues/97181
r? `@Amanieu`
|
|
Stabilize slice_split_at_unchecked
Greetings!
I took the opportunity, and I tried to stabilize the `slice_split_at_unchecked` feature. I followed the guidelines, and I hope everything was done correctly :crossed_fingers: .
Closes #76014
|
|
Let codegen decide when to `mem::swap` with immediates
Making `libcore` decide this is silly; the backend has so much better information about when it's a good idea.
Thus this PR introduces a new `typed_swap` intrinsic with a fallback body, and replaces that fallback implementation when swapping immediates or scalar pairs.
r? oli-obk
Replaces #111744, and means we'll never need more libs PRs like #111803 or #107140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 binary.
|
|
Add `NonNull::<[T]>::is_empty`.
As per https://github.com/rust-lang/rust/issues/71146#issuecomment-2008373983
I figured this should be fine to be insta-stable (with an FCP), but I can edit if that is not desired.
r? ```@Amanieu```
|
|
Remove SpecOptionPartialEq
With the recent LLVM bump, the specialization for Option::partial_eq on types with niches is no longer necessary. I kept the manual implementation as it still gives us better codegen than the derive (will look at this seperately).
Also implemented PartialOrd/Ord by hand as it _somewhat_ improves codegen for #49892: https://godbolt.org/z/vx5Y6oW4Y
|
|
r=compiler-errors
Implement `FusedIterator` for `gen` block
cc #117078
|
|
|
|
|
|
Stop using `box PAT` syntax for deref patterns, as it's misleading and
also causes their semantics being tangled up.
|
|
|
|
Make `type_ascribe!` not a built-in
The only weird thing is the macro expansion note. I wonder if we should suppress these :thinking:
r? ````@fmease```` since you told me about builtin# lol
|
|
|
|
Relax SeqCst ordering in standard library.
Every single SeqCst in the standard library is unnecessary. In all cases, Relaxed or Release+Acquire was sufficient.
As I [wrote](https://marabos.nl/atomics/memory-ordering.html#common-misconceptions) in my book on atomics:
> [..] when reading code, SeqCst basically tells the reader: "this operation depends on the total order of every single SeqCst operation in the program," which is an incredibly far-reaching claim. The same code would likely be easier to review and verify if it used weaker memory ordering instead, if possible. For example, Release effectively tells the reader: "this relates to an acquire operation on the same variable," which involves far fewer considerations when forming an understanding of the code.
>
> It is advisable to see SeqCst as a warning sign. Seeing it in the wild often means that either something complicated is going on, or simply that the author did not take the time to analyze their memory ordering related assumptions, both of which are reasons for extra scrutiny.
r? ````@Amanieu```` ````@joboet````
|
|
|
|
fix typos
|
|
Bump to 1.78 bootstrap compiler
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
|
|
|
|
it seems LLVM doesn't realize that `curr` is always decremented at least
once in either loop formatting characters of the input string by their
appropriate radix, and so the later `&buf[curr..]` generates a check for
out-of-bounds access and panic. this is unreachable in reality as even
for `x == T::zero()` we'll produce at least the character
`Self::digit(T::zero())` for at least one character output, and `curr`
will always be at least one below `buf.len()`.
adjust `fmt_int` to make this fact more obvious to the compiler, which
fortunately (or unfortunately) results in a measurable performance
improvement for workloads heavy on formatting integers.
|
|
|
|
[doc]:fix error code example
fixs #122716
|
|
|
