debuginfo: add an unstable flag to write split DWARF to an explicit directory
Bazel requires knowledge of outputs from actions at analysis time, including file or directory name. In order to work around the lack of predictable output name for dwo files, we group the dwo files in a subdirectory of --out-dir as a post-processing step before returning control to bazel. Unfortunately some debugging workflows rely on directly opening the dwo file rather than loading the merged dwp file, and our trick of moving the files breaks those users. We can't just hardlink the file or copy it, because with remote build execution we wouldn't end up with the un-moved file copied back to the developer's workstation. As a fix, we add this unstable flag that causes dwo files to be written to a build-system-controllable location, which then lets bazel hoover up the dwo files, but the objects also have the correct path for the dwo files.
r? `@davidtwco`
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146653 (improve diagnostics for empty attributes)
- rust-lang/rust#146987 (impl Ord for params and use unstable sort)
- rust-lang/rust#147101 (Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library )
- rust-lang/rust#147123 (Fix removed version numbers of `doc_auto_cfg` and `doc_cfg_hide`)
- rust-lang/rust#147149 (add joboet to library review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix removed version numbers of `doc_auto_cfg` and `doc_cfg_hide`
Tracking issue: https://github.com/rust-lang/rust/issues/43781
The `doc_auto_cfg` and `doc_cfg_hide` features were removed in a recent nightly (by https://github.com/rust-lang/rust/pull/138907).
I believe that the rustc version numbers at which the features were declared to be removed were incorrect, however, and should both be "1.92" (±1). As evidence in favour of this, the error we get from using this was:
```text
error[E0557]: feature has been removed
--> src/lib.rs:22:29
|
22 | #![cfg_attr(docsrs, feature(doc_auto_cfg))]
| ^^^^^^^^^^^^ feature has been removed
|
= note: removed in 1.58.0; see <https://github.com/rust-lang/rust/pull/138907> for more information
= note: merged into `doc_cfg`
```
Note especially the "removed in 1.58" claim. Further evidence is found in the comment further up this file: 4ffeda10e1/compiler/rustc_feature/src/removed.rs (L49-L53)
I've chosen 1.92 as that was the milestone which https://github.com/rust-lang/rust/pull/138907 was added to.
cc `@GuillaumeGomez`
Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library
Now that rust-lang/rust#137122 has landed, we can replace stuff that looks like:
```rust
let a: &[T];
let b: &[T];
let eq = a.len() == b.len() && a.iter().zip(b).all(|(a,b)| a == b)
```
with the much simpler `a.iter().eq(b)`, without losing the perf benefit of the different-length-fast-path.
Also dogfooded `Iterator::eq_by` (cc rust-lang/rust#64295 ) while I'm at it.
First commit (4d1b6fad230f8a5ccceccc7562eadc4ea50059da) should be very straightforward to review, second one (049a4606cb3906787aedf508ee8eea09c2bb3b9a) is slightly more creative, but IMHO a nice cleanup.
impl Ord for params and use unstable sort
AFAICT we are only sorting to find duplicates, so unstable sort should work fine, and maybe is a tiny bit faster?
improve diagnostics for empty attributes
Adds a note about them not having any effect. This was previously done for `feature` attributes but no other attributes. In [converting the `feature` parser](https://github.com/rust-lang/rust/pull/146652) I removed that note. This PR adds it back in and makes it so all attributes benefit from it.
Not blocked on rust-lang/rust#146652, either can merge first
remove explicit deref of AbiAlign for most methods
Much of the compiler calls functions on Align projected from AbiAlign. AbiAlign impls Deref to its inner Align, so we can simplify these away. Also, it will minimize disruption when AbiAlign is removed.
For now, preserve usages that might resolve to PartialOrd or PartialEq, as those have odd inference.
compiler: remove AbiAlign inside TargetDataLayout
AbiAlign is a thin wrapper around Align, extant mostly because we used to track a separate quasi-notion of alignment that was never a real notion of alignment and removing all of it at once was too churny. This PR maintains AbiAlign usage in public API and most of the compiler, but direct access of these fields for TargetDataLayout is now in terms of Align only.
Detect tuple structs that are unconstructable due to re-export
When a tuple-struct is re-exported that has inaccessible fields at the `use` scope, the type's constructor cannot be accessed through that re-export. We now account for this case and extend the resulting resolution error. We also check if the constructor would be accessible directly, not through the re-export, and if so, we suggest using the full path instead.
```
error[E0423]: cannot initialize a tuple struct which contains private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:12:33
|
LL | let crate::Foo(x) = crate::Foo(42);
| ^^^^^^^^^^
|
note: the type is accessed through this re-export, but the type's constructor is not visible in this import's scope due to private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:3:9
|
LL | pub use my_mod::Foo;
| ^^^^^^^^^^^
help: the type can be constructed directly, because its fields are available from the current scope
|
LL | let crate::Foo(x) = crate::my_mod::Foo(42);
| ~~~~~~~~~~~~~~~~~~
```
Fix#133343.
Much of the compiler calls functions on Align projected from AbiAlign.
AbiAlign impls Deref to its inner Align, so we can simplify these away.
Also, it will minimize disruption when AbiAlign is removed.
For now, preserve usages that might resolve to PartialOrd or PartialEq,
as those have odd inference.
When a tuple-struct is re-exported that has inaccessible fields at the `use` scope, the type's constructor cannot be accessed through that re-export. We now account for this case and extend the resulting resolution error. We also check if the constructor would be accessible directly, not through the re-export, and if so, we suggest using the full path instead.
```
error[E0423]: cannot initialize a tuple struct which contains private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:12:33
|
LL | let crate::Foo(x) = crate::Foo(42);
| ^^^^^^^^^^
|
note: the type is accessed through this re-export, but the type's constructor is not visible in this import's scope due to private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:3:9
|
LL | pub use my_mod::Foo;
| ^^^^^^^^^^^
help: the type can be constructed directly, because its fields are available from the current scope
|
LL | let crate::Foo(x) = crate::my_mod::Foo(42);
| ~~~~~~~~~~~~~~~~~~
```
Fix#133343.
Reland "Add LSX accelerated implementation for source file analysis"
This patch introduces an LSX-optimized version of `analyze_source_file` for the `loongarch64` target. Similar to existing SSE2 implementation for x86, this version:
- Processes 16-byte chunks at a time using LSX vector intrinsics.
- Quickly identifies newlines in ASCII-only chunks.
- Falls back to the generic implementation when multi-byte UTF-8 characters are detected or in the tail portion.
Reland rust-lang/rust#145963
r? ``@lqd``
Allow `&raw [mut | const]` for union field in safe code
fixesrust-lang/rust#141264
r? ``@Veykril``
Unresolved questions:
- [x] Any edge cases?
- [x] How this works with rust-analyzer (because all I've did is prevent compiler from emitting error in `&raw` context) (rust-lang/rust-analyzer#19867)
- [x] Should we allow `addr_of!` and `addr_of_mut!` as well? In current version they both (`&raw` and `addr_of!`) are allowed (They are the same)
- [x] Is chain of union fields is a safe? (Yes)
fix rebasing cycle heads when not reaching a fixpoint
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/232
annoyingly subtle, imagine the following proof tree
- A (no cycle head usages, final result Y)
- *ignored* B (depends on A with provisional result X)
- A (cycle, provisional result X)
- B (using the cache entry here incorrectly assumes A has final result X)
r? ``@BoxyUwU``
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 5)
- Part of rust-lang/rust#134001
- Follow-up to rust-lang/rust#146673
---
This is another batch of LLVMDIBuilder binding migrations, replacing some our own LLVMRust bindings with bindings to upstream LLVM-C APIs.
Some of these are a little more complex than most of the previous migrations, because they split one LLVMRust binding into multiple LLVM bindings, but nothing too fancy.
This appears to be the last of the low-hanging fruit. As noted in https://github.com/rust-lang/rust/issues/134001#issuecomment-2524979268, the remaining bindings are difficult or impossible to migrate at present.
Clarified error note for usize range matching
Fixesrust-lang/rust#146476
This is kinda rough, but it gets the point across a little better and stays short.
This patch introduces an LSX-optimized version of `analyze_source_file`
for the `loongarch64` target. Similar to existing SSE2 implementation
for x86, this version:
- Processes 16-byte chunks at a time using LSX vector intrinsics.
- Quickly identifies newlines in ASCII-only chunks.
- Falls back to the generic implementation when multi-byte UTF-8
characters are detected or in the tail portion.
Make `def_path_hash_to_def_id` not panic when passed an invalid hash
I'm using this function in a third-party application (Creusot) to access private items (by reverse engineering their hash). This works in the happy path, but it panics when an item does not exist. There is no way to hack it downstream because the hook `def_path_hash_to_def_id_extern` must always return a `DefId` and its implementation uses `def_path_hash_to_def_index` which is internal and which is where the panic happens.
Introduce CoerceShared lang item and trait, and basic Reborrow tests
Part of rust-lang/rust#145612: This introduces the `CoerceShared` trait which is the `Reborrow` equivalent of a `&mut T` -> `&T` coercion. The trait has a `Target` GAT which makes this (currently) unique in the `core/src/marker.rs`; I'm not sure if this can be considered problematic. Maybe this is not the way such things should be done at the marker trait level? Or maybe it is fine.
Improtantly, this PR introduces a battery of basic `Reborrow` and `CoerceShared` tests. These test the very basics of the feature; custom marker types intended to have exclusive semantics (`Custom<'a>(PhantomData<&'a mut ()>)`), custom exclusive reference wrappers, and standard library exclusive reference wrappers (`Pin<&mut T>` and `Option<&mut T>`). None of these of course work since the implementation for `Reborrow` and `CoerceShared` is entirely missing, but this is the first step towards making these work.
Future PRs will introduce more tests, such as "recursive" reborrowing (ie. reborrowing structs that contain multiple reborrowable fields) and checks around the lifetime semantics of reborrowing ie. that a reborrow produces a new type with the same lifetime as the original.
Implement RFC 3631: add rustdoc doc_cfg features
Implementation of https://github.com/rust-lang/rfcs/pull/3631.
This implementation actually resulted in a lot of simplifications:
* All `cfg` computation is now done in one place: `propagate_doc_cfg.rs`. Because (trait) `impl`s are not retrieved at the same time as the other items, we cannot perform this computation in the clean process, it needs to be after.
* Because there is `cfg` inheritance, we can keep track of them in one place (in `propagate_doc_cfg.rs`), meaning we don't need to copy an item's attributes to its children anymore. Only exception: impl items. For them we clone only `cfg` attributes.
* `propagate_doc_cfg.rs` is also now much simpler, much less need to keep track of parents, since everything we need is handled by the new `CfgInfo` type.
* I also suspect that `Cfg::simplify_with` could either be removed or at least used directly into `propagate_doc_cfg.rs` when we compute `cfg`s. Considering how big the PR already is, I'll do it in a follow-up.
I didn't remove the `doc_cfg*` features in this PR because some dependencies used in `rustc` (like `stdarch`) are using it, so we need to have a nightly released with this PR before I can switch to the new feature.
r? ghost
JumpThreading: Avoid computing dominators to identify loop headers.
JumpThreading tries to avoid threading through loop headers to avoid creating irreducible CFGs.
However, computing dominators is expensive, and accounts up to 20 % of the runtime of the JumpThreading pass for some cases like serde.
This PR proposes to approximate according to the post-order traversal order. We define a "maybe" loop header as a block which is visited after its predecessor in post-order.
Bazel requires knowledge of outputs from actions at analysis time,
including file or directory name. In order to work around the lack of
predictable output name for dwo files, we group the dwo files in a
subdirectory of --out-dir as a post-processing step before returning
control to bazel. Unfortunately some debugging workflows rely on
directly opening the dwo file rather than loading the merged dwp file,
and our trick of moving the files breaks those users. We can't just
hardlink the file or copy it, because with remote build execution we
wouldn't end up with the un-moved file copied back to the developer's
workstation. As a fix, we add this unstable flag that causes dwo files
to be written to a build-system-controllable location, which then lets
bazel hoover up the dwo files, but the objects also have the correct
path for the dwo files.
