We will want to remove many cases of `.abi`, including `.abi.thing`,
so this may simplify future PRs and certainly doesn't hurt.
We omit DerefMut because mutation is much rarer and localized.
In PR 90877 T-lang decided not to remove `intrinsics::pref_align_of`.
However, the intrinsic and its supporting code
1. is a nightly feature, so can be removed at compiler/libs discretion
2. requires considerable effort in the compiler to support, as it
necessarily complicates every single site reasoning about alignment
3. has been justified based on relevance to codegen, but it is only a
requirement for C++ (not C, not Rust) stack frame layout for AIX,
in ways Rust would not consider even with increased C++ interop
4. is only used by rustc to overalign some globals, not correctness
5. can be adequately replaced by other rules for globals, as it mostly
affects alignments for a few types under 16 bytes of alignment
6. has only one clear benefactor: automating C -> Rust translation
for GNU extensions like `__alignof`
7. such code was likely intended to be `alignof` or `_Alignof`,
because the GNU extension is a "false friend" of the C keyword,
which makes the choice to support such a mapping very questionable
8. makes it easy to do incorrect codegen in the compiler by its mere
presence as usual Rust rules of alignment (e.g. `size == align * N`)
do not hold with preferred alignment
The implementation is clearly damaging the code quality of the compiler.
Thus it is within the compiler team's purview to simply rip it out.
If T-lang wishes to have this intrinsic restored for c2rust's benefit,
it would have to use a radically different implementation that somehow
does not cause internal incorrectness.
Until then, remove the intrinsic and its supporting code, as one tool
and an ill-considered GCC extension cannot justify risking correctness.
Because we touch a fair amount of the compiler to change this at all,
and unfortunately the duplication of AbiAndPrefAlign is deep-rooted,
we keep an "AbiAlign" type which we can wean code off later.
Simplify and optimize `VecCache`'s `SlotIndex::from_index`
Simplify and optimize `SlotIndex::from_index`
Break out bucket 0 (containing `idx < 4096`) as an early return, which
simplifies the remainder of the function, and allows optimizing the
`checked_ilog2` since it can no longer return `None`.
This reduces the runtime of `vec_cache::tests::slot_index_exhaustive`
(which calls `SlotIndex::from_index` for every `u32`, twice) from ~15.5s
to ~13.3s.
Separately, simplify the test case as well. (The old and new code passes with
the old and new test case.)
---
Noticed because `slot_index_exhaustive` stood out as taking unusually long compared to other tests, so I started investigating what it was doing.
Don't walk into `Certainty::Yes` goals
Don't walk into `Certainty::Yes` goals in the pending obligation finding code, since they will not have been stalled on an infer var anyways
Remove CollectItemTypesVisitor
I always felt like we were very unnecessarily walking the HIR, let's see if perf agrees
There is lots to ~~improve~~ consolidate further here, as we still have 3 item wfchecks:
* check_item (matching on the hir::ItemKind)
* actually doing trait solver based checks (by using HIR spans)
* lower_item (matching on the hir::ItemKind after loading it again??)
* just ensure_ok-ing a bunch of queries
* check_item_type (matching on DefKind)
* some type based checks, mostly ensure_ok-ing a bunch of queries
fixesrust-lang/rust#121429
compiler: Treat ForceWarning as a Warning for diagnostic level
This silences an ICE.
No idea if this is the correct solution though tbh.
Fixesrust-lang/rust#142144
compiler: Sort and doc ExternAbi variants
My personal brainworms found this ordering made the most sense while writing the CanonAbi PR. It is *an* ordering, at least, unlike the current mess. There has been no particular reason for the previous order ever since rust-lang/rust#136901, despite the comment I delete here. I just didn't change it.
Because I feel weird just fussing with variant ordering in the source definition, I also documented a bunch to the best of my ability.
Treat normalizing consts like normalizing types in deeply normalize
...so that we don't end up putting a top-level normalizes-to goal in the fulfillment context, which ICEs. This basically just models the normalize-const code off of the normalize-ty code above it, which uses an alias-relate goal instead.
Fixesrust-lang/rust#140571
r? lcnr
Make the `dangerous_implicit_autorefs` lint deny-by-default
I intended for the `dangerous_implicit_autorefs` lint to be deny-by-default, the [T-lang nomination comment](https://github.com/rust-lang/rust/pull/123239#issuecomment-2727551097) even clearly mentioned deny-by-default, but somehow I and other missed that it is only warn-by-default.
I think the lint should still be deny-by-default as the implicit aliasing requirements can be quite dangerous.
In any-case, opening this PR for T-lang awareness.
`@rustbot` label +I-lang-nominated +T-lang
r? `@traviscross`
Allow `#![doc(test(attr(..)))]` everywhere
This PR adds the ability to specify [`#![doc(test(attr(..)))]`](https://doc.rust-lang.org/nightly/rustdoc/write-documentation/the-doc-attribute.html#testattr) ~~at module level~~ everywhere in addition to allowing it at crate-root.
This is motivated by a recent PR #140323 (by ````@tgross35)```` where we have to duplicate 2 attributes to every single `f16` and `f128` doctests, by allowing `#![doc(test(attr(..)))]` at module level (and everywhere else) we can omit them entirely and just have (in both module):
```rust
#![doc(test(attr(feature(cfg_target_has_reliable_f16_f128))))]
#![doc(test(attr(expect(internal_features))))]
```
Those new attributes are appended to the one found at crate-root or at a previous module. Those "global" attributes are compatible with merged doctests (they already were before).
Given the small addition that this is, I'm proposing to insta-stabilize it, but I can feature-gate it if preferred.
Best reviewed commit by commit.
r? ````@GuillaumeGomez````
Move coroutine_by_move_body_def_id into the big check_crate body owner loop
This avoids starting a parallel loop in sequence and instead runs all the queries for a specific DefId together.
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#137992 (Stabilise `os_string_pathbuf_leak`)
- rust-lang/rust#141558 (Limit the size of cgu names when using the `-Zhuman-readable-cgu-name…)
- rust-lang/rust#141797 (compiler: set Apple frame pointers by architecture)
- rust-lang/rust#141857 (coretests: move float tests from num to floats module and use a more flexible macro to generate them)
- rust-lang/rust#142045 (Make obligation cause code suggestions verbose)
- rust-lang/rust#142076 (Check documentation of bootstrap in PR CI)
- rust-lang/rust#142110 (Add solaris targets to build-manifest)
- rust-lang/rust#142131 (Make cast suggestions verbose)
r? `@ghost`
`@rustbot` modify labels: rollup
Check documentation of bootstrap in PR CI
It's annoying when wrong doc comments in bootstrap [break](https://github.com/rust-lang/rust/pull/141272#issuecomment-2943614152) `auto` CI. This has happened a few times recently, and documenting bootstrap with the stage0 compiler should be pretty quick, so let's add it to PR CI.
r? ``@marcoieni``
Make obligation cause code suggestions verbose
```
error[E0277]: `()` is not a future
--> $DIR/unnecessary-await.rs:28:10
|
LL | e!().await;
| ^^^^^ `()` is not a future
|
= help: the trait `Future` is not implemented for `()`
= note: () must be a future or must implement `IntoFuture` to be awaited
= note: required for `()` to implement `IntoFuture`
help: remove the `.await`
|
LL - e!().await;
LL + e!();
|
```
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/const-fn-in-vec.rs:1:47
|
LL | static _MAYBE_STRINGS: [Option<String>; 5] = [None; 5];
| ^^^^ the trait `Copy` is not implemented for `String`
|
= note: required for `Option<String>` to implement `Copy`
= note: the `Copy` trait is required because this value will be copied for each element of the array
help: create an inline `const` block
|
LL | static _MAYBE_STRINGS: [Option<String>; 5] = [const { None }; 5];
| +++++++ +
```
Part of rust-lang/rust#141973
coretests: move float tests from num to floats module and use a more flexible macro to generate them
This makes some progress on https://github.com/rust-lang/rust/issues/141726 by moving the float tests in `num` to `floats` and using a newer, more flexible macro to generate them. We also newly run these tests on f16 and f128 in const, and at runtime in Miri and for hosts where that works well enough.
I didn't yet deduplicate any tests or port the existing `floats::f*` tests to the macro, that can happen in a future PR.
try-job: x86_64-gnu-aux
compiler: set Apple frame pointers by architecture
All Apple targets stop overriding this configuration and instead use the default base of FramePointer::NonLeaf, which means some Apples will have less frame pointers in leaf functions.
r? ``@madsmtm``
cc ``@thomcc``
Limit the size of cgu names when using the `-Zhuman-readable-cgu-name…
…s` option
Prior to this change, cgu names could be generated which would result in filenames longer than the limit imposed by the OS.
Compute number of digits instead of relying on constant value for u128 display code
As discussed in https://github.com/rust-lang/rust/pull/142098/files#r2132084991, the code should reuse the same logic as the rest of file instead of using a constant value.
r? `@tamird`
Reduce confusion of some drop order tests
In addition to adhering to normal Rust casing idioms, I ran `rustfmt`.
Closesrust-lang/rust#141604
r? `@jieyouxu`
Verbose suggestion to make param `const`
```
error[E0747]: type provided when a constant was expected
--> $DIR/invalid-const-arguments.rs:10:19
|
LL | impl<N> Foo for B<N> {}
| ^
|
help: consider changing this type parameter to a const parameter
|
LL - impl<N> Foo for B<N> {}
LL + impl<const N: u8> Foo for B<N> {}
|
```
Part of rust-lang/rust#141973.
unsafe keyword docs: emphasize that an unsafe fn in a trait does not get to choose its safety contract
Inspired by discussion in https://github.com/rust-lang/rust/issues/139368.
Cc `@hanna-kruppe`
