I had the epiphany that now that fragments are "semantic" -- rather than
just strings -- they fill the role that used to be handled by the side
channel. I think I may be able to get rid of the other uses of the side
channel using this technique too.
Rollup of 7 pull requests
Successful merges:
- #92058 (Make Run button visible on hover)
- #92288 (Fix a pair of mistyped test cases in `std::net::ip`)
- #92349 (Fix rustdoc::private_doc_tests lint for public re-exported items)
- #92360 (Some cleanups around check_argument_types)
- #92389 (Regression test for borrowck ICE #92015)
- #92404 (Fix font size for [src] links in headers)
- #92443 (Rustdoc: resolve associated traits for non-generic primitive types)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
cg: split dwarf for crate dependencies
Fixes#81024.
- In #79570, `-Z split-dwarf-kind={none,single,split}` was replaced by `-C split-debuginfo={off,packed,unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split, respectively.
On Unix, `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it.
In the initial implementation of Split DWARF, split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode, sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However, both split and single modes could be packaged or not, the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file).
In the first commit of this PR, I re-introduce a `-Z split-dwarf-kind` flag, which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked).
- Split DWARF packaging requires all of the object files to exist, including those in dependencies. ~~Therefore, the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place), then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single`, and dwarf objects if `SplitDwarfKind::Split`.~~
~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223, I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach.
- ~~There's still a dependency on `llvm-dwp` after this change, which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally, Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change, it depends whether or not switching away from `llvm-dwp` later would break any guarantees, or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867.
r? `@nagisa`
cc `@alexcrichton`
Rustdoc: resolve associated traits for non-generic primitive types
Fixes#90703
This seems to work:
<img width="457" alt="image" src="https://user-images.githubusercontent.com/2807772/147774059-9556ff96-4519-409e-8ed0-c33ecc436171.png">
I'm just afraid I might have missed some cases / broken previous functionality.
I also have not written tests yet, I will have to take a look to see where tests are and how they are structured, but any help there is also appreciated.
Some cleanups around check_argument_types
Split out in ways from my rebase/continuation of #71827
Commits are mostly self-explanatory and these changes should be fairly straightforward
Fix rustdoc::private_doc_tests lint for public re-exported items
Closes#72081
This involves changing the lint to check the access level is exported, rather than public.
The [exported access level](e91ad5fc62/compiler/rustc_middle/src/middle/privacy.rs (L24)) accounts for public items and items accessible to other crates with the help of `pub use` re-exports.
The pattern of re-exporting public items from a private module is usage seen in a number of popular crates.
`thorin` is a Rust implementation of a DWARF packaging utility that
supports reading DWARF objects from archive files (i.e. rlibs) and
therefore is better suited for integration into rustc.
Signed-off-by: David Wood <david.wood@huawei.com>
In #79570, `-Z split-dwarf-kind={none,single,split}` was replaced by `-C
split-debuginfo={off,packed,unpacked}`. `-C split-debuginfo`'s packed
and unpacked aren't exact parallels to single and split, respectively.
On Unix, `-C split-debuginfo=packed` will put debuginfo into object
files and package debuginfo into a DWARF package file (`.dwp`) and
`-C split-debuginfo=unpacked` will put debuginfo into dwarf object files
and won't package it.
In the initial implementation of Split DWARF, split mode wrote sections
which did not require relocation into a DWARF object (`.dwo`) file which
was ignored by the linker and then packaged those DWARF objects into
DWARF packages (`.dwp`). In single mode, sections which did not require
relocation were written into object files but ignored by the linker and
were not packaged. However, both split and single modes could be
packaged or not, the primary difference in behaviour was where the
debuginfo sections that did not require link-time relocation were
written (in a DWARF object or the object file).
This commit re-introduces a `-Z split-dwarf-kind` flag, which can be
used to pick between split and single modes when `-C split-debuginfo` is
used to enable Split DWARF (either packed or unpacked).
Signed-off-by: David Wood <david.wood@huawei.com>
By avoiding formatting and allocations in the no-ident case, and by making the span mandatory if the ident exists.
Use the optimized `opt_item_ident` to cleanup `fn each_child_of_item`
Rollup of 7 pull requests
Successful merges:
- #92092 (Drop guards in slice sorting derive src pointers from &mut T, which is invalidated by interior mutation in comparison)
- #92388 (Fix a minor mistake in `String::try_reserve_exact` examples)
- #92442 (Add negative `impl` for `Ord`, `PartialOrd` on `LocalDefId`)
- #92483 (Stabilize `result_cloned` and `result_copied`)
- #92574 (Add RISC-V detection macro and more architecture instructions)
- #92575 (ast: Always keep a `NodeId` in `ast::Crate`)
- #92583 (⬆️ rust-analyzer)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fixes#92266
In some `HashStable` impls, we use a cache to avoid re-computing
the same `Fingerprint` from the same structure (e.g. an `AdtDef`).
However, the `StableHashingContext` used can be configured to
perform hashing in different ways (e.g. skipping `Span`s). This
configuration information is not included in the cache key,
which will cause an incorrect `Fingerprint` to be used if
we hash the same structure with different `StableHashingContext`
settings.
To fix this, the configuration settings of `StableHashingContext`
are split out into a separate `HashingControls` struct. This
struct is used as part of the cache key, ensuring that our caches
always produce the correct result for the given settings.
With this in place, we now turn off `Span` hashing during the
entire process of computing the hash included in legacy symbols.
This current has no effect, but will matter when a future PR
starts hashing more `Span`s that we currently skip.
Add RISC-V detection macro and more architecture instructions
This pull request includes:
- Update `stdarch` dependency to include ratified RISC-V supervisor and hypervisor instruction intrinsics which is useful in Rust kernel development
- Add macro `is_riscv_feature_detected!`
- Modify impl of `core::hint::spin_loop` to comply with latest version of `core::arch`
After this update, users may now develop RISC-V kernels and user applications more freely.
r? `@Amanieu`
Fix a minor mistake in `String::try_reserve_exact` examples
The examples of `String::try_reserve_exact` didn't actually use `try_reserve_exact`, which was probably a minor mistake, and this PR fixed it.
Drop guards in slice sorting derive src pointers from &mut T, which is invalidated by interior mutation in comparison
I tried to run https://github.com/rust-lang/miri-test-libstd on `alloc` with `-Zmiri-track-raw-pointers`, and got a failure on the test `slice::panic_safe`. The test failure has nothing to do with panic safety, it's from how the test tests for panic safety.
I minimized the test failure into this very silly program:
```rust
use std::cell::Cell;
use std::cmp::Ordering;
#[derive(Clone)]
struct Evil(Cell<usize>);
fn main() {
let mut input = vec![Evil(Cell::new(0)); 3];
// Hits the bug pattern via CopyOnDrop in core
input.sort_unstable_by(|a, _b| {
a.0.set(0);
Ordering::Less
});
// Hits the bug pattern via InsertionHole in alloc
input.sort_by(|_a, b| {
b.0.set(0);
Ordering::Less
});
}
```
To fix this, I'm just removing the mutability/uniqueness where it wasn't required.
Extract init_env_logger to crate
I've been doing some work on rustc_ast_pretty using an out-of-tree main.rs and Cargo.toml with the following:
```toml
[dependencies]
rustc_ast = { path = "../rust/compiler/rustc_ast" }
rustc_ast_pretty = { path = "../rust/compiler/rustc_ast_pretty" }
rustc_span = { path = "../rust/compiler/rustc_span" }
```
Rustc_ast_pretty helpfully uses `tracing::debug!` but I found that in order to enable the debug output, my test crate must depend on rustc_driver which is an enormously bigger dependency than what I have been using so far, and slows down iteration time because an enormous dependency tree between rustc_ast and rustc_driver must now be rebuilt after every ast change.
I pulled out the tracing initialization to a new minimal rustc_log crate so that projects depending on the other rustc crates, like rustc_ast_pretty, can access the `debug!` messages in them without building all the rest of rustc.
