Improve `AdtDef` interning.
This commit makes `AdtDef` use `Interned`. Much of the commit is tedious
changes to introduce getter functions. The interesting changes are in
`compiler/rustc_middle/src/ty/adt.rs`.
r? `@fee1-dead`
This commit makes `AdtDef` use `Interned`. Much the commit is tedious
changes to introduce getter functions. The interesting changes are in
`compiler/rustc_middle/src/ty/adt.rs`.
This updates the standard library's documentation to use the new syntax. The
documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.
A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
Support GATs in Rustdoc
Implements:
1. Rendering GATs in trait definitions and impl blocks
2. Rendering GATs in types (e.g. in the return type of a function)
Fixes#92341
This is my first rustdoc PR, so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful!
I tested locally and things looked correct:
Specifically, rename the `Const` struct as `ConstS` and re-introduce `Const` as
this:
```
pub struct Const<'tcx>(&'tcx Interned<ConstS>);
```
This now matches `Ty` and `Predicate` more closely, including using
pointer-based `eq` and `hash`.
Notable changes:
- `mk_const` now takes a `ConstS`.
- `Const` was copy, despite being 48 bytes. Now `ConstS` is not, so need a
we need separate arena for it, because we can't use the `Dropless` one any
more.
- Many `&'tcx Const<'tcx>`/`&Const<'tcx>` to `Const<'tcx>` changes
- Many `ct.ty` to `ct.ty()` and `ct.val` to `ct.val()` changes.
- Lots of tedious sigil fiddling.
Specifically, change `Region` from this:
```
pub type Region<'tcx> = &'tcx RegionKind;
```
to this:
```
pub struct Region<'tcx>(&'tcx Interned<RegionKind>);
```
This now matches `Ty` and `Predicate` more closely.
Things to note
- Regions have always been interned, but we haven't been using pointer-based
`Eq` and `Hash`. This is now happening.
- I chose to impl `Deref` for `Region` because it makes pattern matching a lot
nicer, and `Region` can be viewed as just a smart wrapper for `RegionKind`.
- Various methods are moved from `RegionKind` to `Region`.
- There is a lot of tedious sigil changes.
- A couple of types like `HighlightBuilder`, `RegionHighlightMode` now have a
`'tcx` lifetime because they hold a `Ty<'tcx>`, so they can call `mk_region`.
- A couple of test outputs change slightly, I'm not sure why, but the new
outputs are a little better.
Specifically, change `Ty` from this:
```
pub type Ty<'tcx> = &'tcx TyS<'tcx>;
```
to this
```
pub struct Ty<'tcx>(Interned<'tcx, TyS<'tcx>>);
```
There are two benefits to this.
- It's now a first class type, so we can define methods on it. This
means we can move a lot of methods away from `TyS`, leaving `TyS` as a
barely-used type, which is appropriate given that it's not meant to
be used directly.
- The uniqueness requirement is now explicit, via the `Interned` type.
E.g. the pointer-based `Eq` and `Hash` comes from `Interned`, rather
than via `TyS`, which wasn't obvious at all.
Much of this commit is boring churn. The interesting changes are in
these files:
- compiler/rustc_middle/src/arena.rs
- compiler/rustc_middle/src/mir/visit.rs
- compiler/rustc_middle/src/ty/context.rs
- compiler/rustc_middle/src/ty/mod.rs
Specifically:
- Most mentions of `TyS` are removed. It's very much a dumb struct now;
`Ty` has all the smarts.
- `TyS` now has `crate` visibility instead of `pub`.
- `TyS::make_for_test` is removed in favour of the static `BOOL_TY`,
which just works better with the new structure.
- The `Eq`/`Ord`/`Hash` impls are removed from `TyS`. `Interned`s impls
of `Eq`/`Hash` now suffice. `Ord` is now partly on `Interned`
(pointer-based, for the `Equal` case) and partly on `TyS`
(contents-based, for the other cases).
- There are many tedious sigil adjustments, i.e. adding or removing `*`
or `&`. They seem to be unavoidable.
Remove defaultness from ImplItem.
This information is not really used anywhere, except HIR pretty-printing. This makes ImplItem and TraitItem more similar.
Lazy type-alias-impl-trait
Previously opaque types were processed by
1. replacing all mentions of them with inference variables
2. memorizing these inference variables in a side-table
3. at the end of typeck, resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type
This worked okayish for `impl Trait` in return position, but required lots of roundabout type inference hacks and processing.
This PR instead stops this process of replacing opaque types with inference variables, and just keeps the opaque types around.
Whenever an opaque type `O` is compared with another type `T`, we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it, we grab the recorded type (`T`) and compare that against `U`. This makes implementing
* https://github.com/rust-lang/rfcs/pull/2515
much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities).
r? `@nikomatsakis`
fixes#93411fixes#88236
by using an opaque type obligation to bubble up comparisons between opaque types and other types
Also uses proper obligation causes so that the body id works, because out of some reason nll uses body ids for logic instead of just diagnostics.
Render more readable macro matcher tokens in rustdoc
Follow-up to #92334.
This PR lifts some of the token rendering logic from https://github.com/dtolnay/prettyplease into rustdoc so that even the matchers for which a source code snippet is not available (because they are macro-generated, or any other reason) follow some baseline good assumptions about where the tokens in the macro matcher are appropriate to space.
The below screenshots show an example of the difference using one of the gnarliest macros I could find. Some things to notice:
- In the **before**, notice how a couple places break in between `$(....)`↵`*`, which is just about the worst possible place that it could break.
- In the **before**, the lines that wrapped are weirdly indented by 1 space of indentation relative to column 0. In the **after**, we use the typical way of block indenting in Rust syntax which is put the open/close delimiters on their own line and indent their contents by 4 spaces relative to the previous line (so 8 spaces relative to column 0, because the matcher itself is indented by 4 relative to the `macro_rules` header).
- In the **after**, macro_rules metavariables like `$tokens:tt` are kept together, which is how just about everybody writing Rust today writes them.
## Before
## After
r? `@camelid`
This is the same idea as #92533, but for `AssocItem` instead
of `VariantDef`/`FieldDef`.
With this change, we no longer have any uses of
`#[stable_hasher(project(...))]`
Replace use of `ty()` on term and use it in more places. This will allow more flexibility in the
future, but slightly worried it allows items which are consts which only accept types.
ProjectionPredicate should be able to handle both associated types and consts so this adds the
first step of that. It mainly just pipes types all the way down, not entirely sure how to handle
consts, but hopefully that'll come with time.
The field is also renamed from `ident` to `name. In most cases,
we don't actually need the `Span`. A new `ident` method is added
to `VariantDef` and `FieldDef`, which constructs the full `Ident`
using `tcx.def_ident_span()`. This method is used in the cases
where we actually need an `Ident`.
This makes incremental compilation properly track changes
to the `Span`, without all of the invalidations caused by storing
a `Span` directly via an `Ident`.
This commit removes the first of nine Clean impls on tuples, converting
it to a function instead.
The fact that these are impls causes several problems:
1. They are nameless, so it's unclear what they do.
2. It's hard to find where they're used apart from removing them and
seeing what errors occur (this applies to all Clean impls, not just
the tuple ones).
3. Rustc doesn't currently warn when impls are unused, so dead code
can accumulate easily (all Clean impls).
4. Their bodies often use tuple field indexing syntax (e.g., `self.1`)
to refer to their "arguments", which makes reading the code more
difficult.
As I noted, some of these problems apply to all Clean impls, but even
those problems are exacerbated by the tuple impls since they make
general understanding of the code harder.
Converting the impls to functions solves all four of these problems.
I would like to rename it to `Type::Path`, but then it can't be
re-exported since the name would conflict with the `Path` struct.
Usually enum variants are referred to using their qualified names in
Rust (and parts of rustdoc already do that with `clean::Type`), so this
is also more consistent with the language.
Avoid documenting top-level private imports
PR #88447 aimed to make rustdoc's `--document-private-items` mode only document imports that are visible outside the importing module. Unfortunately, I inadvertently set things up so that imports at the crate top-level are always documented, regardless of their visibility. This behavior was unintended and is [not desirable](https://github.com/rust-lang/rust/issues/90865#issuecomment-971172649).
This PR treats top-level imports as never being visible outside their parent module. In practice, the only way a top-level import can be visible externally is if it's fully public, and there's a seperate check for that.
It's worth calling attention to the fact that this change means that `pub(crate)` imports will be visible in lower level modules, but not at the top-level. This is because, at the top level of the crate, `pub(crate)` means the same thing as `pub(self)`.
It turned out that there were existing tests checking for the only behavior, which I didn't notice at the time of my previous PR. I have updated them to check for the new behavior and substantially extended them to handle differences between the top-level module and lower level modules. I may have gone overboard, so please tell me if there's anything I should cut.
r? `@jyn514`
Fixes#90865.
rustdoc: Replace where-bounded Clean impl with simple function
This is the first step in removing the Clean impls for tuples. Either way, this
significantly simplifies the code since it reduces the amount of "trait magic".
(To clarify, I'm referring to impls like `impl Clean for (A, B)`, not Clean impls
that work on tuples in the user's program.)
cc ``@jyn514``
This function parameter attribute was introduced in https://github.com/rust-lang/rust/pull/44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself.
Otherwise, rustdoc panics with messages like this:
thread 'rustc' panicked at 'assertion failed: cx.impl_trait_bounds.is_empty()',
src/librustdoc/clean/utils.rs:462:5
This ordering requirement is unrelated to the `clean_fn_decl_with_args`
refactoring, but the requirement was uncovered as part of that change.
I'm not sure if *all* of these places have the requirement, but I added
comments to them just in case.
Basically, this entails moving the arguments cleaning to the call site.
I extracted several local variables because:
1. It makes the code easier to read and understand.
2. If I hadn't, the extra `clean()` calls would have caused complicated
tuples to be split across several lines.
3. I couldn't just extract local variables for `args` because then the
arguments would be cleaned *before* the generics, while rustdoc expects
them to be cleaned *after*. Only extracting `args` caused panics like
this:
thread 'rustc' panicked at 'assertion failed: cx.impl_trait_bounds.is_empty()',
src/librustdoc/clean/utils.rs:462:5
Extracting variables makes the control flow -- and the required
order of cleaning -- more explicit.
This was the only Clean impl I found with `where` bounds.
This impl was doubly-confusing: it was implemented on a tuple and it
was polymorphic. Combined, this caused a "spooky action at a distance"
effect to make the code very confusing.
Merge `DocContext.{ty,lt,ct}_substs` into one map
It should be impossible to have more than one entry with a particular
key across the three maps, so they should be one map. In addition to
making it impossible for multiple entries to exist, this should improve
memory usage since now only one map is allocated on the stack and heap.
r? `@GuillaumeGomez`
This change has two advantages:
1. It makes the possible states clearer, and it makes it impossible to
construct invalid states, such as a blanket impl that is also an auto
trait impl.
2. It shrinks the size of `Impl` a bit, since now there is only one
field, rather than two.
It should be impossible to have more than one entry with a particular
key across the three maps, so they should be one map. In addition to
making it impossible for multiple entries to exist, this should improve
memory usage since now only one map is allocated on the stack and heap.
It should be preferred over `def_id_no_primitives()`, so it should have
a shorter name. I also put it before `def_id_no_primitives()` so that it
shows up first in the docs.
This reduces the size of `GenericParamDef` a bit, but some of the size
savings are hidden because of the `ty` field of the `Const` variant.
I will box that in the next commit.
* Move call location logic from function constructor to rendering
* Fix issue with macro spans in scraping examples
* Clean up example loading logic
Documentation / newtype for DecorationInfo
Fix line number display
Serialize edition of call site, other small cleanup
Move rendering of examples into
Finalize design
Cleanup, rename found -> scraped
Softer yellow
Clean up dead code
Document scrape_examples
More simplification and documentation
Remove extra css
Test
By adding #![doc(cfg_hide(foobar))] to the crate attributes the cfg
#[cfg(foobar)] (and _only_ that _exact_ cfg) will not be implicitly
treated as a doc(cfg) to render a message in the documentation.
This is only active when the `doc_cfg` feature is active.
The implicit cfg can be overridden via #[doc(cfg(...))], so e.g. to
hide a #[cfg] you can use something like:
```rust
#[cfg(unix)]
#[doc(cfg(all()))]
pub struct Unix;
```
(since `all()` is always true, it is never shown in the docs)
Coerce const FnDefs to implement const Fn traits
You can now pass a FnDef to a function expecting `F` where `F: ~const FnTrait`.
r? ``@oli-obk``
``@rustbot`` label T-compiler F-const_trait_impl
The change to `impl Clean<Path> for hir::TraitRef<'_>` was necessary to
fix a test failure for `src/test/rustdoc/trait-alias-mention.rs`.
Here's why:
The old code path was through `impl Clean<Type> for hir::TraitRef<'_>`,
which called `resolve_type`, which in turn called `register_res`. Now,
because `PolyTrait` uses a `Path` instead of a `Type`, the impl of
`Clean<Path>` was being run, which did not call `register_res`, causing
the trait alias to not be recorded in the `external_paths` cache.
It should only ever be a `ResolvedPath`, so this (a) enforces that, and
(b) reduces the size of `Impl`.
I had to update a test because the order of the rendered auto trait impl
bounds changed. I think the order changed because rustdoc sorts auto
trait bounds using their `Debug` output.
rustdoc: Cleanup `clean` part 2
Split out from #88379. This contains the following commits from that PR:
- Remove `Type::ResolvedPath.is_generic`
- Rename `is_generic()` to `is_assoc_ty()`
r? `@jyn514`
Be explicit about using Binder::dummy
This is somewhat of a late followup to the binder refactor PR. It removes `ToPredicate` and `ToPolyTraitImpls` that hide the use of `Binder::dummy`. While this does make code a bit more verbose, it allows us be more careful about where we create binders.
Another alternative here might be to add a new trait `ToBinder` or something with a `dummy()` fn. Which could still allow grepping but allows doing something like `trait_ref.dummy()` (but I also wonder if longer-term, it would be better to be even more explicit with a `bind_with_vars(ty::List::empty())` *but* that's not clear yet.
r? ``@nikomatsakis``
rustdoc: Cleanup `clean` part 1
Split out from #88379.
These commits are completely independent of each other, and each is a fairly
small change (the last few are new commits; they are not from #88379):
- Remove unnecessary `Cache.*_did` fields
- rustdoc: Get symbol for `TyParam` directly
- Create a valid `Res` in `external_path()`
- Remove unused `hir_id` parameter from `resolve_type`
- Fix redundant arguments in `external_path()`
- Remove unnecessary `is_trait` argument
- rustdoc: Cleanup a pattern match in `external_generic_args()`
r? ``@jyn514``
It was only used for sugaring `Fn` trait bounds, and rustdoc already
checks that the `did` is for a `Fn` (or `FnMut`, `FnOnce`) lang item,
so it's not necessary to also check that the `did` belongs to a trait.
The order of the `where` bounds on auto trait impls changed because
rustdoc currently sorts auto trait `where` bounds based on the `Debug`
output for the bound. Now that the bounds have an actual `Res`, they are
being unintentionally sorted by their `DefId` rather than their path.
So, I had to update a test for the change in ordering of the rendered
bounds.
Split rustc_mir
The `rustc_mir` crate is the second largest in the compiler.
This PR splits it up into 5 crates:
- rustc_borrowck;
- rustc_const_eval;
- rustc_mir_dataflow;
- rustc_mir_transform;
- rustc_monomorphize.
rustdoc: Clean up handling of lifetime bounds
Previously, rustdoc recorded lifetime bounds by rendering them into the
name of the lifetime parameter. Now, it leaves the name as the actual
name and instead records lifetime bounds in an `outlives` list, similar
to how type parameter bounds are recorded.
Also, higher-ranked lifetimes cannot currently have bounds, so I simplified
the code to reflect that.
r? `@GuillaumeGomez`
rustdoc: Box `GenericArg::Const` to reduce enum size
This should reduce the amount of memory allocated in the common cases
where the `GenericArg` is a lifetime or type.
This cleans up the other spot I found where rustdoc was rendering bounds
into the lifetime name itself. However, in this case, I don't think it
could have actually happened because higher-ranked lifetime definitions
aren't currently allowed to have bounds.
Previously, rustdoc recorded lifetime bounds by rendering them into the
name of the lifetime parameter. Now, it leaves the name as the actual
name and instead records lifetime bounds in an `outlives` list, similar
to how type parameter bounds are recorded.
rustdoc: Don't panic on ambiguous inherent associated types
Instead, return `Type::Infer` since compilation should fail anyway.
That's how rustdoc handles `hir::TyKind::Err`s, so this just extends
that behavior to `ty::Err`s when analyzing associated types.
For some reason, the error is printed twice with rustdoc (though only
once with rustc). I'm not sure why that is, but it's better than
panicking.
This commit also makes rustdoc fail early in the non-projection,
non-error case, instead of returning a `Res::Err` that would likely
cause rustdoc to panic later on. This change is originally from #88379.
r? `@GuillaumeGomez`
rustdoc: Box `GenericArgs::Parenthesized.output`
Split out from #88379.
This reduces the size of `GenericArgs` from 104 bytes to 56 bytes,
essentially reducing it by half.
`GenericArgs` is one of the fields of `PathSegment`, so this should
reduce the amount of memory allocated for `PathSegment`s in the cases
where the generics are not for a `Fn`, `FnMut`, or `FnOnce` trait.
r? `@jyn514`
Instead, return `Type::Infer` since compilation should fail anyway.
That's how rustdoc handles `hir::TyKind::Err`s, so this just extends
that behavior to `ty::Err`s when analyzing associated types.
For some reason, the error is printed twice with rustdoc (though only
once with rustc). I'm not sure why that is, but it's better than
panicking.
This commit also makes rustdoc fail early in the non-projection,
non-error case, instead of returning a `Res::Err` that would likely
cause rustdoc to panic later on. This change is originally from #88379.
This reduces the size of `GenericArgs` from 104 bytes to 56 bytes,
essentially reducing it by half.
`GenericArgs` is one of the fields of `PathSegment`, so this should
reduce the amount of memory allocated for `PathSegment`s in the cases
where the generics are not for a `Fn`, `FnMut`, or `FnOnce` trait.
I also added `static_assert_size!`s to `GenericArgs` and `PathSegment`
to ensure they don't increase in size unexpectedly.
Add support for tuple struct field documentation
Fixes #42615.
This is #80320 updated to new codebase and with added tests.
Part of https://github.com/rust-lang/rust/issues/83255.
cc ```@camelid``` (since you were involved on the original PR).
r? ```@jyn514```
These were only used once, in a place where it was trivial to replace.
Also, it's unclear what 'clean' would mean for these, so it seems better
to be explicit.
rustdoc: Render `<Self as X>::Y` type casts properly across crate bounds
My last PR that introduced the type casting did not work for cross-crate re-exported traits, which is fixed in this PR.
Fully resolves#85454
Unify rustc and rustdoc parsing of `cfg()`
This extracts a new `parse_cfg` function that's used between both.
- Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)]
#[doc(cfg(y))]`. Previously it would be completely ignored.
- Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)]
#[doc(cfg(x))]`. Previously, the cfg would be ignored.
- Pass the cfg predicate through to rustc_expand to be validated
Technically this is a breaking change, but doc_cfg is still nightly so I don't think it matters.
Fixes https://github.com/rust-lang/rust/issues/84437.
r? `````````@petrochenkov`````````
This extracts a new `parse_cfg` function that's used between both.
- Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)]
#[doc(cfg(y))]`. Previously it would be completely ignored.
- Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)]
#[doc(cfg(x))]`. Previously, the cfg would be ignored.
- Pass the cfg predicate through to rustc_expand to be validated
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
check item.is_fake() instead of self_id.is_some()
Remove empty branching in Attributes::from_ast
diverse small refacto after Josha review
cfg computation moved in merge_attrs
refacto use from_ast twice for coherence
take cfg out of Attributes and move it to Item
refacto use from_def_id_and_attrs_and_parts instead of an old trick
most of josha suggestions + check if def_id is not fake before using it in a query
Removed usage of Attributes in FnDecl and ExternalCrate. Relocate part of the Attributes fields as functions in AttributesExt.
It can be calculated on-demand even without a TyCtxt.
This also changed `from_item_kind` to take a whole item, which avoids
having to add more and more parameters.
