| Age | Commit message (Collapse) | Author | Lines |
|
|
|
0.1.142 fixes an issue parsing optimization flags, and 0.1.143 changes
`__rust_[ui]128_*` builtins to use a C-safe signature.
|
|
0.1.141 syncs changes from `libm`. Most of the `libm` changes are
testing- or configuration-related.
|
|
sync_cg_clif-2025-01-05
|
|
Nothing significant here, just syncing the following small changes:
- https://github.com/rust-lang/compiler-builtins/pull/727
- https://github.com/rust-lang/compiler-builtins/pull/730
- https://github.com/rust-lang/compiler-builtins/pull/736
- https://github.com/rust-lang/compiler-builtins/pull/737
|
|
sync_cg_clif-2024-12-06
|
|
sync_cg_clif-2024-11-09
|
|
sync_cg_clif-2024-11-02
|
|
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features
This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.
Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.
The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.
Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
|
|
|
|
sync_cg_clif-2024-09-22
|
|
sync_cg_clif-2024-08-09
|
|
sync_cg_clif-2024-06-30
|
|
PR #125443 will reformat all the use declarations in the repo. This
would break a patch kept in `rustc_codegen_cranelift` that gets applied
to `library/std/src/sys/pal/windows/rand.rs`.
So this commit formats the use declarations in
`library/std/src/sys/pal/windows/rand.rs` in advance of #125443 and
updates the patch file accordingly.
The motivation is that #125443 is a huge change and we want to get
fiddly little changes like this out of the way so it can be nothing more
than an `x fmt --all`.
|
|
sync_cg_clif-2024-05-13
|
|
sync_cg_clif-2024-04-23
|
|
|
|
sync_cg_clif-2024-04-11
|
|
sync_cg_clif-2024-03-28
|
|
sync_cg_clif-2024-03-16
|
|
sync_cg_clif-2024-03-08
|
|
|
|
sync_cg_clif-2024-01-26
|
|
|
|
sync_cg_clif-2023-12-19
|
|
sync_cg_clif-2023-11-10
|
|
sync_cg_clif-2023-10-29
|
|
sync_cg_clif-2023-10-24
|
|
sync_cg_clif-2023-10-21
|
|
sync_cg_clif-2023-10-09
|
|
sync_cg_clif-2023-09-06
|
|
sync_cg_clif-2023-08-09
|
|
sync_cg_clif-2023-07-22
|
|
sync_cg_clif-2023-06-15
|
|
|
|
sync_cg_clif-2023-03-15
|
|
sync_cg_clif-2023-01-24
|
|
sync_cg_clif-2022-10-23
|
|
sync_cg_clif-2022-08-24
|
|
Updates #32976.
Updates #99069.
|
|
sync_cg_clif-2022-05-15
|
|
sync_cg_clif-2022-04-22
|
|
It is UB for LLVM and results in a compile error for Cranelift
|
|
sync_cg_clif-2022-03-20
|
|
sync_cg_clif-2022-02-23
|
|
sync_cg_clif-2021-12-20
|
|
sync_cg_clif-2021-09-19
|
|
sync_cg_clif-2021-08-06
|
|
sync_cg_clif-2021-07-07
|
|
sync_cg_clif-2021-05-27
|