Port `#[allow_internal_unsafe]` to the new attribute system (attempt 2)
This is a slightly modified version of ae1487aa9922de7642c448cc0908584026699e1c, which caused a performance regression (reverted in https://github.com/rust-lang/rust/pull/145086#issue-3303428759). The diff between this PR and the previous one can be seen in 027a1def.
r? ```````@jdonszelmann``````` 💖
Implement `stability_implications` without a visitor.
Since https://github.com/rust-lang/rust/pull/143845, the `Annotator` visitor was a no-op when the crate is not staged_api. This PR avoids using a visitor altogether, making `stability_implications` truly a no-op in most cases.
Remove the omit_gdb_pretty_printer_section attribute
Disabling loading of pretty printers in the debugger itself is more reliable. Before this commit the .gdb_debug_scripts section couldn't be included in dylibs or rlibs as otherwise there is no way to disable the section anymore without recompiling the entire standard library.
Improve formatting of doc code blocks
We don't currently apply automatic formatting to doc comment code blocks. As a
result, it has built up various idiosyncracies, which make such automatic
formatting difficult. Some of those idiosyncracies also make things harder for
human readers or other tools.
This PR makes a few improvements to doc code formatting, in the hopes of making
future automatic formatting easier, as well as in many cases providing net
readability improvements.
I would suggest reading each commit separately, as each commit contains one
class of changes.
Disabling loading of pretty printers in the debugger itself is more
reliable. Before this commit the .gdb_debug_scripts section couldn't be
included in dylibs or rlibs as otherwise there is no way to disable the
section anymore without recompiling the entire standard library.
Ensure correct aligement of rustc_hir::Lifetime on platforms with lower default alignments.
The compiler relies on `hir::Lifetime` being aligned to at least 4 bytes(for the purposes of pointer tagging).
However, on some systems(like m68k) with lower alignment requirements(eg. usize / u32 aligned to 2 bytes),`hir::Lifetime` will be aligned to only 2 bytes.
This causes the compilation to fail on those systems - a const assert in the compiler fails.
This PR makes the aligement requriement of hir::Lifetime explict. This has no effect on platforms where that already is the case(repr align can only raise alignment), but ensures the alignment will stay correct no matter what.
Because doc code does not get automatically formatted, some doc code has
creative placements of comments that automatic formatting can't handle.
Reformat those comments to make the resulting code support standard Rust
formatting without breaking; this is generally an improvement to
readability as well.
Some comments are not indented to the prevailing indent, and are instead
aligned under some bit of code. Indent them to the prevailing indent,
and put spaces *inside* the comments to align them with code.
Some comments span several lines of code (which aren't the line the
comment is about) and expect alignment. Reformat them into one comment
not broken up by unrelated intervening code.
Some comments are placed on the same line as an opening brace, placing
them effectively inside the subsequent block, such that formatting would
typically format them like a line of that block. Move those comments to
attach them to what they apply to.
Some comments are placed on the same line as a one-line braced block,
effectively attaching them to the closing brace, even though they're
about the code inside the block. Reformat to make sure the comment will
stay on the same line as the code it's commenting.
These examples feature Rust code that's presented primarily to
illustrate how its compilation would be handled, and these examples are
formatted to highlight those aspects in ways that rustfmt wouldn't
preserve. Turn formatting off in those examples.
(Doc code isn't formatted yet, but this will make it easier to enable
doc code formatting in the future.)
Only inherit local hash for paths
`DefPathHash`, as the counterpart of `DefId` that is stable across compiler invocations, is comprised of 2 parts. The first one is the `StableCrateId`, stable form of `CrateNum`. The second is 64 complementary bits to identify the crate-local definition.
The current implementation always hashes the full 128 bits when (1) trying to create a new child `DefPathHash` or (2) hashing a `CrateNum` or a `LocalDefId`. But we only need half that information: `LocalDefId` means that the `StableCrateId` is always the current crate's ; `CrateNum` means that we do not care about the local part.
As stable hashing is very hot in the query system, in particular hashing definitions, this is a big deal.
We still want the local part to change when the `StableCrateId` changes, to make incr-compilation errors less painful, ie. increase the likelihood that if will magically disappear by changing some code.
This PR sprinkles some `#[inline]` attributes on small functions that appeared in profiles.
There are many places that join path segments with `::` to produce a
string. A lot of these use `join("::")`. Many in rustdoc use
`join_with_double_colon`, and a few use `.joined("..")`. One in Clippy
uses `itertools::join`. A couple of them look for `kw::PathRoot` in the
first segment, which can be important.
This commit introduces `rustc_ast::join_path_{syms,ident}` to do the
joining for everyone. `rustc_ast` is as good a location for these as
any, being the earliest-running of the several crates with a `Path`
type. Two functions are needed because `Ident` printing is more complex
than simple `Symbol` printing.
The commit also removes `join_with_double_colon`, and
`estimate_item_path_byte_length` with it.
There are still a handful of places that join strings with "::" that are
unchanged. They are not that important: some of them are in tests, and
some of them first split a path around "::" and then rejoin with "::".
This fixes one test case where `{{root}}` shows up in an error message.
Fix some comments and related types and locals where it is obvious, e.g.
- bare_fn -> fn_ptr
- LifetimeBinderKind::BareFnType -> LifetimeBinderKind::FnPtrType
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
Remove support for `dyn*` from the compiler
This PR removes support for `dyn*` (https://github.com/rust-lang/rust/issues/102425), which are a currently un-RFC'd experiment that was opened a few years ago to explore a component that we thought was necessary for AFIDT (async fn in dyn trait).
It doesn't seem like we are going to need `dyn*` types -- even in an not-exposed-to-the-user way[^1] -- for us to implement AFIDT. Given that AFIDT was the original motivating purpose of `dyn*` types, I don't really see a compelling reason to have to maintain their implementation in the compiler.
[^1]: Compared to, e.g., generators whih are an unstable building block we use to implement stable syntax like `async {}`.
We've learned quite a lot from `dyn*`, but I think at this point its current behavior leads to more questions than answers. For example, `dyn*` support today remains somewhat fragile; it ICEs in many cases where the current "normal" `dyn Trait` types rely on their unsizedness for their vtable-based implementation to be sound I wouldn't be surprised if it's unsound in other ways, though I didn't play around with it too much. See the examples below.
```rust
#![feature(dyn_star)]
trait Foo {
fn hello(self);
}
impl Foo for usize {
fn hello(self) {
println!("hello, world");
}
}
fn main() {
let x: dyn* Foo = 1usize;
x.hello();
}
```
And:
```rust
#![feature(dyn_star)]
trait Trait {
type Out where Self: Sized;
}
fn main() {
let x: <dyn* Trait as Trait>::Out;
}
```
...and probably many more problems having to do with the intersection of dyn-compatibility and `Self: Sized` bounds that I was too lazy to look into like:
* GATs
* Methods with invalid signatures
* Associated consts
Generally, `dyn*` types also end up getting in the way of working with [normal `dyn` types](https://github.com/rust-lang/rust/issues/102425#issuecomment-1712604409) to an extent that IMO outweighs the benefit of experimentation.
I recognize that there are probably other, more creative usages of `dyn*` that are orthogonal to AFIDT. However, I think any work along those lines should first have to think through some of the more fundamental interactions between `dyn*` and dyn-compatibility before we think about reimplementing them in the type system.
---
I'm planning on removing the `DynKind` enum and the `PointerLike` built-in trait from the compiler after this PR lands.
Closesrust-lang/rust#102425.
cc `@eholk` `@rust-lang/lang` `@rust-lang/types`
Closesrust-lang/rust#116979.
Closesrust-lang/rust#119694.
Closesrust-lang/rust#134591.
Closesrust-lang/rust#104800.
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#136801 (Implement `Random` for tuple)
- rust-lang/rust#141867 (Describe Future invariants more precisely)
- rust-lang/rust#142760 (docs(fs): Touch up grammar on lock api)
- rust-lang/rust#143181 (Improve testing and error messages for malformed attributes)
- rust-lang/rust#143210 (`tests/ui`: A New Order [19/N] )
- rust-lang/rust#143212 (`tests/ui`: A New Order [20/N])
- rust-lang/rust#143230 ([COMPILETEST-UNTANGLE 2/N] Make some compiletest errors/warnings/help more visually obvious)
- rust-lang/rust#143240 (Port `#[rustc_object_lifetime_default]` to the new attribute parsing …)
- rust-lang/rust#143255 (Do not enable LLD by default in the dist profile)
- rust-lang/rust#143262 (mir: Mark `Statement` and `BasicBlockData` as `#[non_exhaustive]`)
- rust-lang/rust#143269 (bootstrap: make comment more clear)
- rust-lang/rust#143279 (Remove `ItemKind::descr` method)
Failed merges:
- rust-lang/rust#143237 (Port `#[no_implicit_prelude]` to the new attribute parsing infrastructure)
r? `@ghost`
`@rustbot` modify labels: rollup
Start moving wf checking away from HIR
I'm trying to only access the HIR in the error path. My hope is that once we move significant portions of wfcheck off HIR that incremental will be able to cache wfcheck queries significantly better.
I think I am reaching a blocker because we normally need to provide good spans to `ObligationCause`, so that the trait solver can report good errors. In some cases I have been able to use bad spans and improve them depending on the `ObligationCauseCode` (by loading HIR in the case where we actually want to error). To scale that further we'll likely need to remove spans from the `ObligationCause` entirely (leaving it to some variants of `ObligationCauseCode` to have a span when they can't recompute the information later). Unsure this is the right approach, but we've already been using it. I will create an MCP about it, but that should not affect this PR, which is fairly limited in where it does those kind of tricks.
Especially b862d8828e is interesting here, because I think it improves spans in all cases
