Make missed precondition-free float intrinsics safe
So, in my defence, these were both separated out from the other intrinsics in the file *and* had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and `fabs` is needed for those too, so, I don't really have an excuse.
Extra follow-up to rust-lang/rust#146683.
r? ```@RalfJung``` who reviewed the previous one
These don't appear to be used anywhere outside of the standard locations, at least.
Fix uses of "adaptor"
These docs are in en_US, so "adapter" is the correct spelling (and indeed used in the next line.)
A second commit comes along for the ride to fix other instances in non-rustdoc comments.
Add panic=immediate-abort
MCP: https://github.com/rust-lang/compiler-team/issues/909
This adds a new panic strategy, `-Cpanic=immediate-abort`. This panic strategy essentially just codifies use of `-Zbuild-std-features=panic_immediate_abort`. This PR is intended to just set up infrastructure, and while it will change how the compiler is invoked for users of the feature, there should be no other impacts.
In many parts of the compiler, `PanicStrategy::ImmediateAbort` behaves just like `PanicStrategy::Abort`, because actually most parts of the compiler just mean to ask "can this unwind?" so I've added a helper function so we can say `sess.panic_strategy().unwinds()`.
The panic and unwind strategies have some level of compatibility, which mostly means that we can pre-compile the sysroot with unwinding panics then the sysroot can be linked with aborting panics later. The immediate-abort strategy is all-or-nothing, enforced by `compiler/rustc_metadata/src/dependency_format.rs` and this is tested for in `tests/ui/panic-runtime/`. We could _technically_ be more compatible with the other panic strategies, but immediately-aborting panics primarily exist for users who want to eliminate all the code size responsible for the panic runtime. I'm open to other use cases if people want to present them, but not right now. This PR is already large.
`-Cpanic=immediate-abort` sets both `cfg(panic = "immediate-abort")` _and_ `cfg(panic = "abort")`. bjorn3 pointed out that people may be checking for the abort cfg to ask if panics will unwind, and also the sysroot feature this is replacing used to require `-Cpanic=abort` so this seems like a good back-compat step. At least for the moment. Unclear if this is a good idea indefinitely. I can imagine this being confusing.
The changes to the standard library attributes are purely mechanical. Apart from that, I removed an `unsafe` we haven't needed for a while since the `abort` intrinsic became safe, and I've added a helpful diagnostic for people trying to use the old feature.
To test that `-Cpanic=immediate-abort` conflicts with other panic strategies, I've beefed up the core-stubs infrastructure a bit. There is now a separate attribute to set flags on it.
I've added a test that this produces the desired codegen, called `tests/run-make-cargo/panic-immediate-abort-codegen/` and also a separate run-make-cargo test that checks that we can build a binary.
Mark float intrinsics with no preconditions as safe
Note: for ease of reviewing, the list of safe intrinsics is sorted in the first commit, and then safe intrinsics are added in the second commit.
All *recently added* float intrinsics have been correctly marked as safe to call due to the fact that they have no preconditions. This adds the remaining float intrinsics which are safe to call to the safe intrinsic list, and removes the unsafe blocks around their calls.
---
Side note: this may want a try run before being added to the queue, since I'm not sure if there's any tier-2 code that uses these intrinsics that might not be tested on the usual PR flow. We've already uncovered a few places in subtrees that do this, and it's worth double-checking before clogging up the queue.
add `[const] PartialEq` bound to `PartialOrd`
This change is included for discussion purposes.
The PartialOrd bound on PartialEq is not strictly necessary. It is, rather, logical: anything which is orderable should by definition have equality. Is the same true for constness? Should every type which is const orderable also have const equality?
This change is included for discussion purposes.
The PartialOrd bound on PartialEq is not strictly necessary. It
is, rather, logical: anything which is orderable should by
definition have equality. Is the same true for constness? Should
every type which is const orderable also have const equality?
Remove Rvalue::Len again.
Now that we have `RawPtrKind::FakeForPtrMetadata`, we can reimplement `Rvalue::Len` using `PtrMetadata(&raw const (fake) place)`.
r? ``@scottmcm``
initial implementation of the darwin_objc unstable feature
Tracking issue: https://github.com/rust-lang/rust/issues/145496
This feature makes it possible to reference Objective-C classes and selectors using the same ABI used by native Objective-C on Apple/Darwin platforms. Without it, Rust code interacting with Objective-C must resort to loading classes and selectors using costly string-based lookups at runtime. With it, these references can be loaded efficiently at dynamic load time.
r? ```@tmandry```
try-job: `*apple*`
try-job: `x86_64-gnu-nopt`
Migrate `UnsizedConstParamTy` to unstable impl of `ConstParamTy_`
Now that we have ``#[unstable_feature_bound]``, we can remove ``UnsizedConstParamTy`` that was meant to be an unstable impl of stable type and ``ConstParamTy_`` trait.
r? `@BoxyUwU`
Note some previous attempts to change the Default impl for `[T; 0]`
Recently, rust-lang/rust#145457 experimented with changing the Default impl for `[T; 0]`.
Subsequently, rust-lang/rust#146531 also aimed to perform a similar experiment.
It seems like a good idea to add some links to the relevant source code, so that the historical context of this tricky topic is easier to find.
Remove `div_rem` from `core::num::bignum`
This fixes very old fixme that sounds like this
```
Stupid slow base-2 long division taken from
https://en.wikipedia.org/wiki/Division_algorithm
FIXME use a greater base ($ty) for the long division.
```
By deleting this method since it was never used
document `core::ffi::VaArgSafe`
tracking issue: https://github.com/rust-lang/rust/issues/44930
A modification of https://github.com/rust-lang/rust/pull/146454, keeping just the documentation changes, but not unsealing the trait.
Although conceptually we'd want to unseal the trait, there are many edge cases to supporting arbitrary types. We'd need to exhaustively test that all targets/calling conventions support all types that rust might generate (or generate proper error messages for unsupported cases). At present, many of the `va_arg` implementations assume that the argument is a scalar, and has an alignment of at most 8. That is totally sufficient for an MVP (accepting all of the "standard" C types), but clearly does not cover all rust types.
This PR also adds some various other tests for edge cases of c-variadic:
- the `#[inline]` attribute in its various forms. At present, LLVM is unable to inline c-variadic functions, but the attribute should still be accepted. `#[rustc_force_inline]` already rejects c-variadic functions.
- naked functions should accept and work with a C variable argument list. In the future we'd like to allow more ABIs with naked functions (basically, any ABI for which we accept defining foreign c-variadic functions), but for now only `"C"` and `"C-unwind` are supported
- guaranteed tail calls: c-variadic functions cannot be tail-called. That was already rejected, but there was not test for it.
r? `@workingjubilee`
core::ptr: deduplicate docs for as_ref, addr, and as_uninit_ref
also add INFO.md file explaining the purpose of the ptr/docs dir, and give some pointers (heh) to future maintainers.
follow up to rust-lang/rust#142101
part of rust-lang/rust#139190
r? `@workingjubilee`
simplify the declaration of the legacy integer modules (`std::u32` etc.)
This PR removes some duplicated code from the declaration of the legacy integer modules by expanding the macro which is already used to generate `MIN` and `MAX` to now generate the whole module.
This would also make the remaining steps listed in rust-lang/rust#68490 such as fully deprecating the modules or placing `#[doc(hidden)]` on them easier.
const-eval: disable pointer fragment support
This fixes https://github.com/rust-lang/rust/issues/146291 by disabling pointer fragment support for const-eval. I want to properly fix this eventually, but won't get to it in the next few weeks, so this is an emergency patch to prevent the buggy implementation from landing on stable. The beta cutoff is on Sep 12th so if this PR lands after that, we'll need a backport.
mark `format_args_nl!` as `#[doc(hidden)]`
The `#[unstable]` attribute of the macro already says:
> `format_args_nl` is only for internal language use and is subject to change
It does seem plausible to hide it from the `std` docs accordingly.
The PR also removes the single usage of the macro outside of `std` as it does not seem like the macro is actually needed there.
Implement `Sum` and `Product` for `f16` and `f128`.
Tracking issue: rust-lang/rust#116909.
This PR implements `core::iter::{Sum, Product}` for `f16` and `f128`.
I'm curious as to why these two traits aren't already implemented. I've been unable to find any information about it at all, so if there is anything that currently blocks them, I would appreciate if someone could fill me in.
Fix typo in default.rs
This sentence currently reads:
> Rust implements `Default` for various primitives types.
I think it should just be "primitive types".
