Box Item::Attributes
This reduces the size of Item from 128 to 40 bytes. I think this is as small as it needs to get 🎉
Builds on https://github.com/rust-lang/rust/pull/80339 and should not be merged before.
r? `@GuillaumeGomez`
Rework diagnostics for wrong number of generic args (fixes#66228 and #71924)
This PR reworks the `wrong number of {} arguments` message, so that it provides more details and contextual hints.
This makes it possible to pass the `Impl` directly to functions, instead
of having to pass each of the many fields one at a time. It also
simplifies matches in many cases.
- Adds optional default values to const generic parameters in the AST
and HIR
- Parses these optional default values
- Adds a `const_generics_defaults` feature gate
[rustdoc] Box ItemKind to reduce the size of `Item`
This brings the size of `Item` from
```
[src/librustdoc/lib.rs:103] std::mem::size_of::<Item>() = 536
```
to
```
[src/librustdoc/lib.rs:103] std::mem::size_of::<Item>() = 136
```
This is an alternative to https://github.com/rust-lang/rust/pull/79967; I don't think it makes sense to make both changes.
Helps with #79103.
This brings the size of `Item` from
```
[src/librustdoc/lib.rs:103] std::mem::size_of::<Item>() = 680
```
to
```
[src/librustdoc/lib.rs:103] std::mem::size_of::<Item>() = 280
```
Remove `DefPath` from `Visibility` and calculate it on demand
Depends on #80090 and should not be merged before. Helps with https://github.com/rust-lang/rust/issues/79103 and https://github.com/rust-lang/rust/issues/76382.
cc https://github.com/rust-lang/rust/pull/80014#issuecomment-746810284 - `@nnethercote` I figured it out! It was simpler than I expected :)
This brings the size of `clean::Visibility` down from 40 bytes to 8.
Note that this does *not* remove `clean::Visibility`, even though it's now basically the same as `ty::Visibility`, because the `Invsible` variant means something different from `Inherited` and I thought it would be be confusing to merge the two. See the new comments on `impl Clean for ty::Visibility` for details.
Make BoundRegion have a kind of BoungRegionKind
Split from #76814
Also includes making `replace_escaping_bound_vars` only return `T`
Going to r? `@lcnr`
Feel free to reassign
Continue String to Symbol conversion in rustdoc
Follow-up of https://github.com/rust-lang/rust/pull/80091.
This PR is already big enough so I'll stop here before the next one.
r? `@jyn514`
Use more symbols in rustdoc
Builds on https://github.com/rust-lang/rust/pull/80044 and should not be merged before.
I want to test if this is actually faster before merging it, there was a lot of `to_string()` calls so I'm not sure it will actually help. That means I have to wait for 80044 to get merged before running perf.
r? `@ghost`
This was always questionable, and removing it doesn't fail any tests, so
I think this was not affecting the behavior. It dates all the way back
to the very first commit of rustdoc: 268f3f0ff5
Pass around Symbols instead of Idents in doctree
The span was unused.
Vaguely related to https://github.com/rust-lang/rust/pull/78082 - currently working on converting `visit_ast` to use `hir::intravisit` and this makes that a little easier.
r? ``@GuillaumeGomez``
Render Markdown in search results
Fixes#32040.
Previously Markdown documentation was not rendered to HTML for search results,
which led to the output not being very readable, particularly for inline code.
This PR fixes that by rendering Markdown to HTML with the help of pulldown-cmark
(the library rustdoc uses to parse Markdown for the main text of documentation).
However, the text for the title attribute (the text shown when you hover over an
element) still uses the plain-text rendering since it is displayed in browsers
as plain-text.
Only these styles will be rendered; everything else is stripped away:
* *italics*
* **bold**
* `inline code`
Previously Markdown documentation was not rendered to HTML for search results,
which led to the output not being very readable, particularly for inline code.
This PR fixes that by rendering Markdown to HTML with the help of pulldown-cmark
(the library rustdoc uses to parse Markdown for the main text of documentation).
However, the text for the title attribute (the text shown when you hover over an
element) still uses the plain-text rendering since it is displayed in browsers
as plain-text.
Only these styles will be rendered; everything else is stripped away:
* *italics*
* **bold**
* `inline code`
Remove doctree::Macro and distinguish between `macro_rules!` and `pub macro`
This is a part of #78082, removing doctree::Macro. Uses the changes in #79372Fixes#76761
Extend doc keyword feature by allowing any ident
Part of #51315.
As suggested by ``@danielhenrymantilla`` in [this comment](https://github.com/rust-lang/rust/issues/51315#issuecomment-733879934), this PR extends `#[doc(keyword = "...")]` to allow any ident to be used as keyword. The final goal is to allow (proc-)macro crates' owners to write documentation of the keywords they might introduce.
r? ``@jyn514``
- Take `String` instead of `Symbol` - this avoids having to intern then
immediately stringify the existing string.
- Remove unused `get_stability` and `get_deprecation`
- Remove unused `attrs` field from `primitives`
- Only run for `QPath::Resolved` with `Some` self parameter (`<X as Y>::T`)
- Fall back to the previous behavior if the path can't be resolved
- Show what the behavior is if the type can't be normalized
- Run `resolve_vars_if_possible`
It's not clear whether or not this is necessary. See
https://github.com/rust-lang/rust/pull/77616 for more context.
- Add a test for cross-crate re-exports
- Use the same code for both `hir::Ty` and `Ty`
They can be derived directly from the `hir::Item`, there's no special
logic.
- TypeDef
- OpaqueTy
- Constant
- Static
- TraitAlias
- Enum
- Union
- Struct
- Add `Item::from_hir_id_and_kind` convenience wrapper
- Make name parameter mandatory
`tcx.opt_item_name` doesn't handle renames, so this is necessary
for any item that could be renamed, which is almost all of them.
- Override visibilities to be `Inherited` for enum variants
`tcx.visibility` returns the effective visibility, not the visibility
that was written in the source code. `pub enum E { A, B }` always has
public variants `A` and `B`, so there's no sense printing `pub` again.
- Don't duplicate handling of `Visibility::Crate`
Instead, represent it as just another `Restricted` path.
Visibility needs much less information than a full path, since modules
can never have generics. This allows constructing a Visibility from only
a DefId.
Note that this means that paths are now normalized to their DefPath.
In other words, `pub(self)` or `pub(super)` now always shows `pub(in
path)` instead of preserving the original text.
Remove duplicate `Trait::auto` field
It was exactly the same as `is_auto`.
I found this while working on #78082, but it's not required for that PR.
r? `@GuillaumeGomez`
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.
A few of the trivial functions (like `Path::new`) are fine to leave
outside of closures.
The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
Previously the [src] link on types defined by a macro
pointed to the macro definition.
This commit makes the Clean-Implementation for Spans
aware of macro defined types,
so that the link points to the invocation instead.
Use rebind instead of Binder::bind when possible
These are really only the easy places. I just searched for `Binder::bind` and replaced where it straightforward.
r? `@lcnr`
cc. `@nikomatsakis`
- Add `parent_module` to `DocFragment`
- Require the `parent_module` of the item being inlined
- Preserve the hir_id for ExternCrates so rustdoc can find the parent module later
- Take an optional `parent_module` for `build_impl` and `merge_attrs`.
Preserve the difference between parent modules for each doc-comment.
- Support arbitrarily many re-exports in from_ast. In retrospect this is
probably not used and could be simplified to a single
`Option<(Attrs, DefId)>`.
- Don't require the parent_module for all `impl`s, just inlined items
In particular, this will be `None` whenever the attribute is not on a
re-export.
- Only store the parent_module, not the HirId
When re-exporting a re-export, the HirId is not available. Fortunately,
`collect_intra_doc_links` doesn't actually need all the info from a
HirId, just the parent module.
Use `is_unstable_const_fn` instead of `is_min_const_fn` in rustdoc where appropriate
This closes#76501. Specifically, it allows for nightly users with the `#![feature(const_fn)]` flag enabled to still have their `const fn` declarations documented as such, while retaining the desired behavior that rustdoc *not* document functions that have the `rustc_const_unstable` attribute as `const`.
This commit adds support for cleaning `QPath::LangItem` and
`hir::GenericBound::LangItemTrait` in rustdoc. `QPath::LangItem`
does not require lowering, and `hir::GenericBound::LangItemTrait`
is lowered to a `GenericBound::TraitBound`.
Signed-off-by: David Wood <david@davidtw.co>
For consistency with `Attribute::has_name` which doesn't mark the attribute as used either.
Replace all uses of `check_name` with `has_name` outside of rustc
Note that the output of `unpretty-debug.stdout` has changed. In that
test the hash values are normalized from a symbol numbers to small
numbers like "0#0" and "0#1". The increase in the number of static
symbols must have caused the original numbers to contain more digits,
resulting in different pretty-printing prior to normalization.
Add all remaining `DefKind`s.
r? @eddyb or @Centril
~~I'm not sure if this is what you were thinking of. There are also a few places where I'm not sure what the correct choice is because I don't fully understand the meaning of some variants.~~
~~In general, it feels a bit odd to add some of these as `DefKind`s (e.g. `Arm`) because they don't feel like definitions. Are there things that it makes sense not to add?~~
rustdoc: Don't try to load source files from external crates
Local items defined in external macros shouldn't generate rendered source files and should link to the external crate's docs instead.
Part of #70757
r? @GuillaumeGomez
cc @eddyb
use is_empty() instead of len comparison (clippy::len_zero)
use if let instead of while let loop that never loops (clippy::never_loop)
remove redundant returns (clippy::needless_return)
remove redundant closures (clippy::redundant_closure)
use if let instead of match and wildcard pattern (clippy::single_match)
don't repeat field names redundantly (clippy::redundant_field_names)
Remove spotlight
I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes, the result is very clear: it's not useful. Considering the amount of code we have just to run it, I think it's definitely worth it to remove it.
r? @kinnison
cc @ollie27
Rename `libsyntax` to `librustc_ast`
This was the last rustc crate that wasn't following the `rustc_*` naming convention.
Follow-up to https://github.com/rust-lang/rust/pull/67763.
We now make `'empty` indexed by a universe index, resulting
in a region lattice like this:
```
static ----------+-----...------+ (greatest)
| | |
early-bound and | |
free regions | |
| | |
scope regions | |
| | |
empty(root) placeholder(U1) |
| / |
| / placeholder(Un)
empty(U1) -- /
| /
... /
| /
empty(Un) -------- (smallest)
```
Therefore, `exists<A> { forall<B> { B: A } }` is now unprovable,
because A must be at least Empty(U1) and B is placeholder(U2), and hence
the two regions are unrelated.
Rustdoc mutability removal
Fixes#67470.
As discussed in another PR, the `clean::Mutability` type in rustdoc is useless. So let's remove it!
r? @Centril
Add simpler entry points to const eval for common usages.
I found the `tcx.const_eval` API to be complex/awkward to work with, because of the inherent complexity from all of the different situations it is called from. Though it mainly used in one of the following ways:
- Evaluates the value of a constant without any substitutions, e.g. evaluating a static, discriminant, etc.
- Evaluates the value of a resolved instance of a constant. this happens when evaluating unevaluated constants or normalising trait constants.
- Evaluates a promoted constant.
This PR adds three new functions `const_eval_mono`, `const_eval_resolve`, and `const_eval_promoted` to `TyCtxt`, which each cater to one of the three ways `tcx.const_eval`
is normally used.
Allocate HIR on an arena 1/4
This PR is the first in a series of 4, aiming at allocating the HIR on an arena, as a memory optimisation.
1. This first PR lays the groundwork and migrates some low-hanging fruits.
2. The second PR will migrate `hir::Expr`, `hir::Pat` and related.
3. The third PR will migrate `hir::Ty` and related.
4. The final PR will be dedicated to eventual cleanups.
In order to make the transition as gradual as possible, some lowering routines receive `Box`-allocated data and move it into the arena. This is a bit wasteful, but hopefully temporary.
Nonetheless, special care should be taken to avoid double arena allocations.
Work mentored by @Zoxc.
Make GATs less ICE-prone.
After this PR simple lifetime-generic associated types can now be used in a compiling program. There are two big limitations:
* #30472 has not been addressed in any way (see src/test/ui/generic-associated-types/iterable.rs)
* Using type- and const-generic associated types errors because bound types and constants aren't handled by trait solving.
* The errors are technically non-fatal, but they happen in a [part of the compiler](4abb0ad273/src/librustc_typeck/lib.rs (L298)) that fairly aggressively stops compiling on errors.
closes#47206closes#49362closes#62521closes#63300closes#64755closes#67089
support issue = "none" in unstable attributes
This works towards fixing #41260.
This PR allows the use of `issue = "none"` in unstable attributes and makes changes to internally store the issue number as an `Option<NonZeroU32>`. For example:
```rust
#[unstable(feature = "unstable_test_feature", issue = "none")]
fn unstable_issue_none() {}
```
It was not made optional because feedback seen here #60860 suggested that people might forget the issue field if it was optional.
I could not remove the current uses of `issue = "0"` (of which there are a lot) because the stage 0 compiler expects the old syntax. Once this is available in the stage 0 compiler we can replace all uses of `"0"` with `"none"` and no longer allow `"0"`. This is my first time contributing, so I'm not sure what the protocol is with two-part things like this, so some guidance would be appreciated.
r? @varkor
`AttrKind` is a new type with two variants, `Normal` and `DocComment`. It's a
big performance win (over 10% in some cases) because `DocComment` lets doc
comments (which are common) be represented very cheaply.
`Attribute` gets some new helper methods to ease the transition:
- `has_name()`: check if the attribute name matches a single `Symbol`; for
`DocComment` variants it succeeds if the symbol is `sym::doc`.
- `is_doc_comment()`: check if it has a `DocComment` kind.
- `{get,unwrap}_normal_item()`: extract the item from a `Normal` variant;
panic otherwise.
Fixes#60935.
Remove `InternedString`
This PR removes `InternedString` by converting all occurrences to `Symbol`. There are a handful of places that need to use the symbol chars instead of the symbol index, e.g. for stable sorting; local conversions `LocalInternedString` is used in those places.
r? @eddyb
rustc: arena-allocate the slice in `ty::GenericsPredicate`, not the whole struct.
While rebasing #59789 I noticed we can do this now. However, it doesn't help much without changing `inferred_outlives_of` to the same type, which I might try next.
Rename `subst::Kind` to `subst::GenericArg`
And `subst::UnpackedKind` to `subst::GenericArgKind`. Individual variable names (e.g. `kind`) are not renamed, which would be an infeasible mission.
Fixes https://github.com/rust-lang/rust/issues/64352.
r? @eddyb
reserve `impl<T> From<!> for T`
this is necessary for never-type stabilization.
cc #57012#35121
I think we wanted a crater run for this @nikomatsakis?
r? @nikomatsakis
There's not really any reason to not have the visibility default to
inherited, and this saves us the trouble of checking everywhere for
whether we have a visibility or not.
This allows us to pass it a `&mut DocContext` which will allow removal
of RefCells, etc. in the following commits. It's also somewhat a unique
Clean impl in that it previously ignored `self` (re-retriveing
hir::Crate), which it no longer needs to do.
Don't special case the `Self` parameter by name
This results in a couple of small diagnostic regressions. They could be avoided by keeping the special case just for diagnostics, but that seems worse.
closes#50125
cc #60869
This drops the parking_lot dependency; the ReentrantMutex type appeared
to be unused (at least, no compilation failures occurred).
This is technically a possible change in behavior of its users, as
lock() would wait on other threads releasing their guards, but since we
didn't actually remove any threading or such in this code, it appears
that we never used that behavior (the behavior change is only noticeable
if the type previously was used in two threads, in a single thread
ReentrantMutex is useless).
Use doc comments from 'pub use' statements
Split off from #62855
Currently, rustdoc ignores any doc comments found on 'pub use'
statements. As described in issue #58700, this makes it impossible to
properly document procedural macros. Any doc comments must be written on
the procedural macro definition, which must occur in a dedicated
proc-macro crate. This means that any doc comments or doc tests cannot
reference items defined in re-exporting crate, despite the fact that
such items may be required to use the procedural macro.
To solve this issue, this commit allows doc comments to be written on
'pub use' statements. For consistency, this applies to *all* 'pub use'
statements, not just those importing procedural macros.
When inlining documentation, documentation on 'pub use' statements will
be prepended to the documentation of the inlined item. For example,
the following items:
```rust
mod other_mod {
/// Doc comment from definition
pub struct MyStruct;
}
/// Doc comment from 'pub use'
///
pub use other_mod::MyStruct;
```
will caues the documentation for the re-export of 'MyStruct' to be
rendered as:
```
Doc comment from 'pub use'
Doc comment from definition
```
Note the empty line in the 'pub use' doc comments - because doc comments
are concatenated as-is, this ensure that the doc comments on the
definition start on a new line.
Split off from #62855
Currently, rustdoc ignores any doc comments found on 'pub use'
statements. As described in issue #58700, this makes it impossible to
properly document procedural macros. Any doc comments must be written on
the procedural macro definition, which must occur in a dedicated
proc-macro crate. This means that any doc comments or doc tests cannot
reference items defined in re-exporting crate, despite the fact that
such items may be required to use the procedural macro.
To solve this issue, this commit allows doc comments to be written on
'pub use' statements. For consistency, this applies to *all* 'pub use'
statements, not just those importing procedural macros.
When inlining documentation, documentation on 'pub use' statements will
be prepended to the documentation of the inlined item. For example,
the following items:
```rust
mod other_mod {
/// Doc comment from definition
pub struct MyStruct;
}
/// Doc comment from 'pub use'
///
pub use other_mod::MyStruct;
```
will caues the documentation for the re-export of 'MyStruct' to be
rendered as:
```
Doc comment from 'pub use'
Doc comment from definition
```
Note the empty line in the 'pub use' doc comments - because doc comments
are concatenated as-is, this ensure that the doc comments on the
definition start on a new line.
It's internal to resolve and always results in `Res::Err` outside of resolve.
Instead put `DefKind::Fn`s themselves into the macro namespace, it's ok.
Proc macro stubs are items placed into macro namespase for functions that define proc macros.
https://github.com/rust-lang/rust/pull/52383
The rustdoc test is changed because the old test didn't actually reproduce the ICE it was supposed to reproduce.
The (almost) culmination of HirIdification
It's finally over.
This PR removes old `FIXME`s and renames some functions so that the `HirId` variant has the shorter name.
All that remains (and rightfully so) is stuff in `resolve`, `save_analysis` and (as far as I can tell) in a few places where we can't replace `NodeId` with `HirId`.
Previously we would only generate a list of synthetic implementations
for two well known traits – Send and Sync. With this patch all the auto
traits known to rustc are considered. This includes such traits like
Unpin and user’s own traits.
Sadly the implementation still iterates through the list of crate items
and checks them against the traits, which for non-std crates containing
their own auto-traits will still not include types defined in std/core.
It is an improvement nontheless.
This commit removes the `HirId` from `ArgSource::AsyncFn`, relying on
the fact that only `simple_ident` is used in each of the locations that
previously took the original pattern from the `ArgSource::AsyncFn`.
This commit re-implements the async fn drop order lowering changes so
that it all takes place in HIR lowering, building atop the work done by
`@eddyb` to refactor `Res::Upvar`.
Previously, this types involved in the lowering were constructed in
libsyntax as they had to be used during name resolution and HIR
lowering. This was awful because none of that logic should have existed
in libsyntax.
This commit also changes `ArgSource` to keep a `HirId` to the original
argument pattern rather than a cloned copy of the pattern.
We are going to uniform the terminology of all associated items.
Methods that may or may not have `self` are called "associated
functions". Because `AssociatedFn` is a bit long, we rename `Associated`
to `Assoc`.
Fix lints handling in rustdoc
Part of #60664: now lints are handled just like any other lints you would setup in rustc. Still remains to handle `missing code examples` and `missing_docs` as part of the same group.
r? @oli-obk
rustdoc: remove def_ctor hack.
~~No longer necessary since we have `describe_def`.~~
Turns out `def_ctor` was used in conjunction with abusing `tcx.type_of(def_id)` working on both type definitions and `impl`s (specifically, of builtin types), but also reimplementing a lot of the logic that `Clean` already provides on `Ty` / `ty::TraitRef`.
The first commit now does the minimal refactor to keep it working, while the second commit contains the rest of the refactor I started (parts of which I'm not sure we need to keep).
Don't try to render auto-trait bounds with any inference variables
Previously, we checked if the target of a projection type was itself an
inference variable. However, for Rustdoc rendering purposes, there's no
distinction between an inference variable ('_') and a type containing
one (e.g. (MyStruct<u8, _>)) - we don't want to render either of them.
Fixes#60269
Due to the complexity of the original bug, which spans three different
crates (hyper, tower-hyper, and tower), I have been unable to create a
minimized reproduction for the issue.
Previously, we checked if the target of a projection type was itself an
inference variable. However, for Rustdoc rendering purposes, there's no
distinction between an inference variable ('_') and a type containing
one (e.g. (MyStruct<u8, _>)) - we don't want to render either of them.
Fixes#60269
Due to the complexity of the original bug, which spans three different
crates (hyper, tower-hyper, and tower), I have been unable to create a
minimized reproduction for the issue.
[wg-async-await] Drop `async fn` arguments in async block
Fixes#54716.
This PR modifies the HIR lowering (and some other places to make this work) so that unused arguments to a async function are always dropped inside the async move block and not at the end of the function body.
```
async fn foo(<pattern>: <type>) {
async move {
}
} // <-- dropped as you "exit" the fn
// ...becomes...
fn foo(__arg0: <ty>) {
async move {
let <pattern>: <ty> = __arg0;
} // <-- dropped as you "exit" the async block
}
```
However, the exact ordering of drops is not the same as a regular function, [as visible in this playground example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=be39af1a58e5d430be1eb3c722cb1ec3) - I believe this to be an unrelated issue. There is a [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/187312-t-compiler.2Fwg-async-await/topic/.2354716.20drop.20order) for this.
r? @cramertj
cc @nikomatsakis
Fix invalid bounds string generation in rustdoc
Fixes#58737.
Very weird and I'm not sure this is the best fix around. However, trying to fix it beforehand seems overly complicated compared to the gain (in `clean`, it wouldn't change anything since we **have to** return something so that wouldn't work, and in `hir`, I'm afraid I'd break something else for very little gain).
Also, I wasn't able to make a small code to reproduce the issue. The only way to test is to document `crossbeam` directly and check the `Scope` struct...
r? @QuietMisdreavus
This commit makes two changes - separating the `NodeId` that identifies
an enum variant from the `NodeId` that identifies the variant's
constructor; and no longer creating a `NodeId` for `Struct`-style enum
variants and structs.
Separation of the variant id and variant constructor id will allow the
rest of RFC 2008 to be implemented by lowering the visibility of the
variant's constructor without lowering the visbility of the variant
itself.
No longer creating a `NodeId` for `Struct`-style enum variants and
structs mostly simplifies logic as previously this `NodeId` wasn't used.
There were various cases where the `NodeId` wouldn't be used unless
there was an unit or tuple struct or enum variant but not all uses of
this `NodeId` had that condition, by removing this `NodeId`, this must
be explicitly dealt with. This change mostly applied cleanly, but there
were one or two cases in name resolution and one case in type check
where the existing logic required a id for `Struct`-style enum variants
and structs.
Add const generics to rustdoc
Split out from #53645. This work is a collaborative effort with @yodaldevoid.
The `FIXME`s are waiting on a refactor to `LazyConst`. I'll address these in a follow up, but I thought it would be better to implement the rest now to avoid bitrot.
r? @QuietMisdreavus
Revert the `LazyConst` PR
The introduction of `LazyConst` did not actually achieve the code simplicity improvements that were the main reason it was introduced. Especially in the presence of const generics, the differences between the "levels of evaluatedness" of a constant become less clear. As it can be seen by the changes in this PR, further simplifications were possible by folding `LazyConst` back into `ConstValue`. We have been able to keep all the advantages gained during the `LazyConst` refactoring (like `const_eval` not returning an interned value, thus making all the `match` code simpler and more performant).
fixes https://github.com/rust-lang/rust/issues/59209
r? @eddyb @varkor
