| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Don't run `everybody_loops` for rustdoc; instead ignore resolution errors
r? @eddyb
cc @petrochenkov, @GuillaumeGomez, @Manishearth, @ecstatic-morse, @marmeladema
~~Blocked on https://github.com/rust-lang/rust/pull/73743~~ Merged.
~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](https://github.com/rust-lang/rust/pull/73566#issuecomment-656934851)). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html), [ICEs](https://github.com/rust-lang/rust/pull/73566#issuecomment-653619212).
~~Blocked on #74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged.
Closes #71820, closes #71104, closes #65863.
## What is the motivation for this change?
As seen from a lengthy trail of PRs and issues (https://github.com/rust-lang/rust/pull/73532, https://github.com/rust-lang/rust/pull/73103, https://github.com/rust-lang/rust/issues/71820, https://github.com/rust-lang/rust/issues/71104), `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree, meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see https://github.com/rust-lang/rust/pull/73101).
This PR starts by removing `everybody_loops`, fixing #71104 and #71820. However, that brings back the bugs seen originally in https://github.com/rust-lang/rust/pull/43348: Since libstd documents items for all platforms, the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes:
```rust
error[E0433]: failed to resolve: could not find `handle` in `sys`
--> src/libstd/sys/windows/ext/process.rs:13:27
|
13 | let handle = sys::handle::Handle::new(handle as *mut _);
| ^^^^^^ could not find `handle` in `sys`
error[E0425]: cannot find function `symlink_inner` in module `sys::fs`
--> src/libstd/sys/windows/ext/fs.rs:544:14
|
544 | sys::fs::symlink_inner(src.as_ref(), dst.as_ref(), false)
| ^^^^^^^^^^^^^ not found in `sys::fs`
error[E0425]: cannot find function `symlink_inner` in module `sys::fs`
--> src/libstd/sys/windows/ext/fs.rs:564:14
|
564 | sys::fs::symlink_inner(src.as_ref(), dst.as_ref(), true)
| ^^^^^^^^^^^^^ not found in `sys::fs`
```
## Why does this need changes to `rustc_resolve`?
Normally, this could be avoided by simply not calling the `typeck_item_bodies` pass. However, the errors above happen before type checking, in name resolution itself. Since name resolution is intermingled with macro expansion, and rustdoc needs expansion to happen before it knows all items to be documented, there needs to be someway to ignore _resolution_ errors in function bodies.
An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues, but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve:
- Functions containing a nested `DefId` (https://github.com/rust-lang/rust/issues/71104)
- ~~Functions returning `impl Trait` (https://github.com/rust-lang/rust/pull/43878)~~ These ended up not resolving anyway with this PR.
- ~~`const fn`, because `loop {}` in `const fn` is unstable (https://github.com/rust-lang/rust/issues/43636)~~ `const_loop` was just stabilized.
This also isn't exactly what rustdoc wants, which is to avoid looking at function bodies in the first place.
## What changes were made?
The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored, the MIR generated will be invalid, as can be seen in the following ICE:
```rust
error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) ("return type"): bad type [type error]
--> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1
|
51 | / pub unsafe fn uses_target_feature() {
52 | | content::should::be::irrelevant();
53 | | }
| |_^
```
Fortunately, rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help, because it causes the typechecking pass to be run, bringing back the errors from #24658:
```
error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope
--> src/libstd/sys/windows/ext/process.rs:71:27
|
71 | self.into_inner().into_handle().into_raw() as *mut _
| ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe`
|
```
Because of #73743, we only run typeck on demand. So this only causes an issue for functions returning `impl Trait`, which were already special cased by `ReplaceFunctionWithBody`. However, it now considers `async fn f() -> T` to be considered `impl Future<Output = T>`, where before it was considered to have a concrete `T` type.
## How will this affect future changes to rustdoc?
- Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies.
+ As a corollary, any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand, see for example #73743.
+ As a corollary, rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether.
## Current status
- ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking, which would probably be another rabbit hole.~~ The opt-out was implemented in https://github.com/rust-lang/rust/pull/73743. However, of the rustc lints, now _only_ missing_docs is run and no other lints: https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058. We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure`, etc). **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237
- ~~The implementation of optional errors in `rustc_resolve` is very brute force, it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now.
- This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run, all of which (that I looked at) didn't compile when run with rustc directly. In other words, it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237
- ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior, but needs the changes from https://github.com/rust-lang/rust/pull/74070 in order to be fixed.~~ Reverted.
|
|
Initialize default providers only once
This avoids copying a new `Providers` struct for each downstream crate
that wants to use it.
Follow-up to https://github.com/rust-lang/rust/pull/74283 without the perf hit.
r? @eddyb
|
|
Just use a boolean instead.
|
|
- Remove unnecessary `should_loop` variable
- Report errors for trait implementations
These should give resolution errors because they are visible outside the
current scope. Without these errors, rustdoc will give ICEs:
```
thread 'rustc' panicked at 'attempted .def_id() on invalid res: Err', /home/joshua/src/rust/src/libstd/macros.rs:16:9
15: rustc_hir::def::Res<Id>::def_id
at /home/joshua/src/rust/src/librustc_hir/def.rs:382
16: rustdoc::clean::utils::register_res
at src/librustdoc/clean/utils.rs:627
17: rustdoc::clean::utils::resolve_type
at src/librustdoc/clean/utils.rs:587
```
- Add much more extensive tests
+ fn -> impl -> fn
+ fn -> impl -> fn -> macro
+ errors in function parameters
+ errors in trait bounds
+ errors in the type implementing the trait
+ unknown bounds for the type
+ unknown types in function bodies
+ errors generated by macros
- Use explicit state instead of trying to reconstruct it from random info
- Use an enum instead of a boolean
- Add example of ignored error
|
|
- Explicitly check for missing docs
- Don't run any lints except those we explicitly specified
|
|
Instead, ignore resolution errors that occur in item bodies.
The reason this can't ignore item bodies altogether is because
`const fn` could be used in generic types, for example `[T; f()]`
|
|
This avoids copying a new `Providers` struct for each downstream crate
that wants to use it.
|
|
|
|
|
|
|
|
|
|
Print environment variables accessed by rustc as special comments into depinfo files
So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes.
---
I've recently observed one more forgotten environment variable in a build script https://github.com/rust-lang/rust/pull/71314/commits/8a77d1ca3fc2df789157f7986ddbaf2a377ff0fe and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo.
Unsurprisingly, I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517 https://github.com/rust-lang/rust/issues/40364 https://github.com/rust-lang/rust/issues/44074.
Also, there are dozens of uses of `(option_)env!` in rustc repo and, like, half of them are not registered in build scripts.
---
Description:
- depinfo files are extended with special comments containing info about environment variables accessed during compilation.
- Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`.
- Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`).
- `KEY` and `VALUE` are minimally escaped (`\n`, `\r`, `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends.
FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488
Closes https://github.com/rust-lang/rust/issues/70517
Closes https://github.com/rust-lang/rust/issues/40364
Closes https://github.com/rust-lang/rust/issues/44074
A new issue in the cargo repo will be needed to track the cargo side of this feature.
r? @ehuss
|
|
Move remaining `NodeId` APIs from `Definitions` to `Resolver`
Implements https://github.com/rust-lang/rust/pull/73291#issuecomment-643515557
TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed.
After this, the only remaining work for #50928 should be to adjust the dev guide.
r? @petrochenkov
|
|
|
|
It turns out that this has not been working for who knows how long.
Previously:
```
pub fn h() { 1 + 2; }
```
After this change:
```
pub fn h() { loop {} }
```
This only affected the pass when run with the command line
pretty-printing option, so rustdoc was still replacing bodies with
`loop {}`.
|
|
|
|
|
|
Currently, the `Debug` impl for `proc_macro::Span` just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the `SyntaxContext` is displayed.
This commit adds a perma-unstable flag `-Z span-debug`. When enabled,
the `Debug` impl for `proc_macro::Span` simply forwards directly to
`rustc_span::Span`. Once #72618 is merged, this will start displaying
actual line numbers.
While `Debug` impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.
|
|
r=eddyb
Track devirtualized filenames
Split payload of FileName::Real to track both real and virtualized paths.
(Such splits arise from metadata refs into libstd; the virtualized paths look like `/rustc/1.45.0/src/libstd/io/cursor.rs` rather than `/Users/felixklock/Dev/Mozilla/rust.git/src/libstd/io/cursor.rs`)
This way, we can emit the virtual name into things like the like the StableSourceFileId (as was done back before PR #70642) that ends up in incremental build artifacts, while still using the devirtualized file path when we want to access the file.
Fix #70924
|
|
|
|
|
|
Such splits arise from metadata refs into libstd.
This way, we can (in a follow on commit) continue to emit the virtual name into
things like the like the StableSourceFileId that ends up in incremetnal build
artifacts, while still using the devirtualized file path when we want to access
the file.
Note that this commit is intended to be a refactoring; the actual fix to the bug
in question is in a follow-on commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
normalize some imports & prefer direct ones
r? @Mark-Simulacrum
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #69251 (#[track_caller] in traits)
- #69880 (miri engine: turn error sanity checks into assertions)
- #70207 (Use getentropy(2) on macos)
- #70227 (Only display definition when suggesting a typo)
- #70236 (resolve: Avoid "self-confirming" import resolutions in one more case)
- #70248 (parser: simplify & remove unused field)
- #70249 (handle ConstKind::Unresolved after monomorphizing)
- #70269 (remove redundant closures (clippy::redundant_closure))
- #70270 (Clean up E0449 explanation)
Failed merges:
r? @ghost
|
|
|
|
|
|
|
|
Don't unwind when hitting the macro expansion recursion limit
This removes one use of `FatalError.raise()`.
r? @petrochenkov
|
|
|
|
|
|
Remove some imports to the rustc crate
- When we have `NestedVisitorMap::None`, we use `type Map = dyn intravisit::Map<'v>;` instead of the actual map. This doesn't actually result in dynamic dispatch (in the future we may want to use an associated type default to simplify the code).
- Use `rustc_session::` imports instead of `rustc::{session, lint}`.
r? @Zoxc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
