| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rustc: Remove `#[rustc_synthetic]`
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.
Noticed while reviewing https://github.com/rust-lang/rust/pull/90947.
|
|
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.
|
|
* Remove outdated comment
* Remove duplicated code
* Extract helper function
|
|
This should be the last bit of the transition to computed visibility,
rather than syntactic visibility.
|
|
This change should make the code a bit clearer and easier to change.
|
|
|
|
|
|
Remove unneeded FIXMEs comments in search index generation
Original comment:
> Instead of recreating a new `vec` for each arguments, we re-use the same. The impact on performance should be minor but worth a try.
After testing it, we reached the conclusion that the code readability drop wasn't worth the almost unnoticeable performance improvement.
r? `@camelid`
|
|
Delete rustdoc::doctree
close https://github.com/rust-lang/rust/issues/90864
|
|
Rollup of 3 pull requests
Successful merges:
- #90771 (Fix trait object error code)
- #90840 (relate lifetime in `TypeOutlives` bounds on drop impls)
- #90853 (rustdoc: Use an empty Vec instead of Option<Vec>)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: use Type::def_id() instead of Type::def_id_no_primitives()
For: #90187
r? `@jyn514`
|
|
Signed-off-by: hi-rustin <rustin.liu@gmail.com>
|
|
|
|
Add more comments to explain the code to generate the search index
Fixes #90766.
I tried to put comments when the code wasn't easy to understand at first sight and added more documentation on the recursive function. Please tell me if I misused the terminology or if comments can be improved or added into other places.
r? `@notriddle`
|
|
|
|
conclusion that the code readibility wasn't worth the almost unnoticeable perf improvement
|
|
Use Vec extend and collect instead of repeatedly calling push
|
|
|
|
rustdoc: Go back to loading all external crates unconditionally
This *continues* to cause regressions. This code will be unnecessary
once access to the resolver happens fully before creating the tyctxt
(#83761), so load all crates unconditionally for now. To minimize churn, this leaves in the code for loading crates selectively.
"Fixes" https://github.com/rust-lang/rust/issues/84738. Previously: https://github.com/rust-lang/rust/pull/83738, https://github.com/rust-lang/rust/pull/85749, https://github.com/rust-lang/rust/pull/88215
r? `@petrochenkov` cc `@camelid` (this should fix the "index out of bounds" error you had while looking up `crate_name`).
|
|
Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
|
|
GuillaumeGomez:remove-potential-useless-search-index-data, r=notriddle,camelid
Remove potential useless data for search index
I uncovered this case when working on https://github.com/rust-lang/rust/pull/90726 to debug https://github.com/rust-lang/rust/pull/90385.
Explanations: if we have a full generic, we check if it has generics then we do the following:
* If it has only one generic, we remove one nested level in order to not keep the "parent" generic (since it has empty name, it's useless after all).
* Otherwise we add it alongside its generics.
However, I didn't handle the case where a generic had no generics. Meaning that we were adding items with empty names in the search index. So basically useless data in the search index.
r? `@camelid`
|
|
|
|
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.
|
|
Type inference for inline consts
Fixes #78132
Fixes #78174
Fixes #81857
Fixes #89964
Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure.
Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts.
The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure.
With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME.
Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck).
cc `````@spastorino````` `````@lcnr`````
r? `````@nikomatsakis`````
`````@rustbot````` label A-inference F-inline_const T-compiler
|
|
Don't abort compilation after giving a lint error
The only reason to use `abort_if_errors` is when the program is so broken that either:
1. later passes get confused and ICE
2. any diagnostics from later passes would be noise
This is never the case for lints, because the compiler has to be able to deal with `allow`-ed lints.
So it can continue to lint and compile even if there are lint errors.
Closes https://github.com/rust-lang/rust/issues/82761. This is a WIP because I have a feeling it will exit with 0 even if there were lint errors; I don't have a computer that can build rustc locally at the moment.
|
|
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 *continues* to cause regressions. This code will be unnecessary
once access to the resolver happens fully before creating the tyctxt
(#83761), so load all crates unconditionally for now.
|
|
This helps with (but does not fix)
https://github.com/rust-lang/rust/issues/84738. I tested on
https://github.com/jyn514/objr/commit/edcee7b8124abf0e4c63873e8422ff81beb11ebb
and still hit ICEs.
|
|
The `ImplKind` methods can just be used directly instead.
|
|
Rustdoc is special as usual and doesn't go through RunCompiler, so it
needs its own explicit checks. The rest of the tools go through
RunCompiler, so they should be fine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 can be computed on-demand in `Item::span()`.
|
|
|
|
|
|
rustdoc: clippy::complexity fixes
|
|
|
|
Fix ICE when rustdoc is scraping examples inside of a proc macro
This PR provides a clearer semantics for how --scrape-examples interacts with macros. If an expression's span AND it's enclosing item's span both are not `from_expansion`, then the example will be scraped. The added test case `rustdoc-scrape-examples-macros` shows a variety of situations.
* A macro-rules macro that takes a function call as input: good
* A macro-rules macro that generates a function call as output: bad
* A proc-macro that generates a function call as output: bad
* An attribute macro that generates a function call as output: bad
* An attribute macro that takes a function call as input: good, if the proc macro is designed to propagate the input spans
I ran this updated rustdoc on pyo3 and confirmed that it successfully scrapes examples from inside a proc macro, eg
<img width="1013" alt="Screen Shot 2021-11-04 at 1 11 28 PM" src="https://user-images.githubusercontent.com/663326/140412691-81a3bb6b-a448-4a1b-a293-f7a795553634.png">
(cc `@mejrs)`
Additionally, this PR fixes an ordering bug in the highlighting logic.
Fixes https://github.com/rust-lang/rust/issues/90567.
r? `@jyn514`
|
