Rollup merge of #73771 - alexcrichton:ignore-unstable, r=estebank,GuillaumeGomez
Don't pollute docs/suggestions with libstd deps
Currently dependency crates of the standard library can sometimes leak
into error messages such as when traits to import are suggested.
Additionally they can leak into documentation such as in the list of
"all traits implemented by `u32`". The dependencies of the standard
library, however, are intended to be private.
The dependencies of the standard library can't actually be stabl-y
imported nor is the documentation that relevant since you can't import
them on stable either. This commit updates both the compiler and rustdoc
to ignore unstable traits in these two scenarios.
Specifically the suggestion for traits to import ignore unstable traits,
and similarly the list of traits implemented by a type excludes unstable
traits.
This commit is extracted from #73441 where the addition of some new
dependencies to the standard library was showed to leak into various
error messages and documentation. The intention here is to go ahead and
land these changes ahead of that since it will likely take some time to
land.
Rollup merge of #73566 - jyn514:name-resolve-first, r=eddyb
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.
Auto merge of #74202 - oli-obk:mir_const, r=RalfJung
Reduce the amount of interning and `layout_of` calls in const eval.
r? @ghost
If we just want to get at some bits of a constant, we don't need to intern it before extracting those bits.
Also, if we want to read a `usize` or `bool`, we can fetch the size without invoking a query.
Auto merge of #74388 - Manishearth:rollup-i7iueu8, r=Manishearth
Rollup of 7 pull requests
Successful merges:
- #73421 (Clarify effect of orphan rule changes on From/Into)
- #74037 (Update reference to CONTRIBUTING.md)
- #74203 (Enforce the static symbol order.)
- #74295 (Add and fix BTreeMap comments)
- #74352 (Use local links in the alloc docs.)
- #74377 (Move libstd's default feature to libtest)
- #74381 (Update docs for str::as_bytes_mut.)
* Remove mention of `from_utf8_mut`. It is not necessary to call
a function to convert the byte slice back to a string slice. The
original string becomes accessible again after the byte slice is
no longer used (as shown in the example code).
Rollup merge of #74377 - alexcrichton:test-default, r=Mark-Simulacrum
Move libstd's default feature to libtest
This commit makes it so `std` no longer has a `default` feature, but
instead the `test` crate has a `default` feature doing the same thing.
The purpose of this commit is to allow Cargo's `-Zbuild-std` command,
which could customize the features of the standard library, to handle
the `default` feature for libstd. Currently Cargo's `-Zbuild-std`
support starts at libtests's manifest as the entry point to the std set
of crates.
Rollup merge of #74352 - ehuss:fix-alloc-links, r=Mark-Simulacrum
Use local links in the alloc docs.
Links to other crates (like core) from the alloc crate were incorrectly using the `https://doc.rust-lang.org/nightly/` absolute (remote) links, instead of relative (local) links. For example, the link to `Result` at https://doc.rust-lang.org/1.44.1/alloc/vec/struct.Vec.html#method.try_reserve goes to /nightly/.
This is because alloc was being documented before core, and rustdoc relies on the existence of the local directory to know if it should use a local or remote link.
There was code that tried to compensate for this (`create_dir_all`), but in #54543 it was broken because instead of running `cargo doc` once for all the crates, it was changed to run `cargo rustdoc` for each crate individually. This means that `create_dir_all` was no longer doing what it was supposed to be doing (creating all the directories before starting).
The solution here is to just build in the correct order (from the dependency leaves towards the root). An alternate solution would be to switch back to running `cargo doc` once (and use RUSTDOCFLAGS for passing in flags). Another alternate solution would be to iterate over the list twice, creating the directories during the first pass.
I also did a little cleanup to remove the "crate-docs" directory. This was added in the past because different crates were built in different directories. Over time, things have been unified (and rustc docs no longer include std), so it is no longer necessary.
Rollup merge of #74203 - nnethercote:enforce-static-symbol-order, r=petrochenkov
Enforce the static symbol order.
By making the proc macro abort if any symbols are out of order.
The commit also changes the proc macro collect multiple errors (of order
or duplicated symbols) and prints them at the end, which is useful if
you have multiple errors.
Rollup merge of #73421 - janikrabe:master, r=joshtriplett
Clarify effect of orphan rule changes on From/Into
Updated documentation for `std::convert` and `std::convert::From` to reflect changes to orphan rule in Rust 1.41. It should no longer be necessary to implement `Into` directly, unless targeting an older version.
By making the proc macro abort if any symbols are out of order.
The commit also changes the proc macro collect multiple errors (of order
or duplicated symbols) and prints them at the end, which is useful if
you have multiple errors.
* Remove mention of `from_utf8_mut`. It is not necessary to call
a function to convert the byte slice back to a string slice. The
original string becomes accessible again after the byte slice is
no longer used (as shown in the example code).
Janik Rabe [Tue, 16 Jun 2020 13:14:16 +0000 (16:14 +0300)]
Clarify effect of orphan rule changes on From/Into
Updated documentation for `std::convert` and `std::convert::From` to
reflect changes to orphan rule in Rust 1.41. It should no longer be
necessary to implement Into directly, unless targeting an older version.
Alex Crichton [Wed, 15 Jul 2020 18:31:48 +0000 (11:31 -0700)]
Move libstd's default feature to libtest
This commit makes it so `std` no longer has a `default` feature, but
instead the `test` crate has a `default` feature doing the same thing.
The purpose of this commit is to allow Cargo's `-Zbuild-std` command,
which could customize the features of the standard library, to handle
the `default` feature for libstd. Currently Cargo's `-Zbuild-std`
support starts at libtests's manifest as the entry point to the std set
of crates.
Rollup merge of #74374 - cuviper:lto-bitcode-1.45, r=Mark-Simulacrum
Add a 1.45 release note on lto vs. embed-bitcode
I added a bullet for Cargo's use of `embed-bitcode`, since that was even noteworthy enough for the Inside Rust blog. Then more importantly, I added a compatibility note for how this may interact poorly with manually enabling LTO.
Rollup merge of #74337 - estebank:ty-parse-recovery, r=varkor
Handle case of incomplete local ty more gracefully
When encountering a local binding with a type that isn't completed, the
parser will reach a `=` token. When this happen, consider the type
"complete" as far as the parser is concerned to avoid further errors
being emitted by parse recovery logic.
Rollup merge of #74294 - msirringhaus:master, r=pietroalbini
Update cross-compilation README
README seemed rather out of date. I hope the information in my PR is now correct (it was more or less assembled by asking in zulip and learning-by-doing).
Rollup merge of #74276 - lcnr:discriminant-kind-what, r=nagisa
improve DiscriminantKind handling
Adds a lang item `discriminant_type` for the associated type `DiscriminantKind::Discriminant`.
Changes the discriminant of generators from `i32` to `u32`, which should not be observable to fix an
oversight where MIR was using `u32` and codegen and typeck used `i32`.
Rollup merge of #74218 - GuillaumeGomez:search-results-bottom-margin, r=Dylan-DPC
Add margin after doc search results
I found it not really on computer that the last result is right at the bottom of the page. I find it better with margin below (especially when you hover the last element!). A screenshot to show the result:
Joshua Nelson [Sun, 12 Jul 2020 01:50:25 +0000 (21:50 -0400)]
Address review comments
- Move static variables into the innermost scope in which they are used
- Clean up comments
- Remove external_providers; rename local_providers -> providers
Joshua Nelson [Sat, 11 Jul 2020 04:28:42 +0000 (00:28 -0400)]
Don't ICE on infinitely recursive types
`evaluate_obligation` can only be run on types that are already valid.
So rustdoc still has to run typeck even though it doesn't care about the
result.
This wasn't picked up earlier because having `type Alias = impl Trait;`
in the same module caused _all closures_ to be typechecked, even if they
wouldn't normally. Additionally, if _any_ error was emitted, no
delay_span_bug would be emitted. So as part of this commit all of the
tests were separated out into different files.
Joshua Nelson [Fri, 3 Jul 2020 22:41:23 +0000 (18:41 -0400)]
Don't ICE on errors in function returning impl trait
Instead, report the error.
This emits the errors on-demand, without special-casing `impl Trait`, so
it should catch all ICEs of this kind, including ones that haven't been
found yet.
Since the error is emitted during type-checking there is less info about
the error; see comments in the code for details.
- Add test case for -> impl Trait
- Add test for impl trait with alias
- Move EmitIgnoredResolutionErrors to rustdoc
This makes `fn typeck_item_bodies` public, which is not desired behavior.
That change should be removed once
https://github.com/rust-lang/rust/pull/74070 is merged.
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
Auto merge of #74113 - lcnr:type-dependent-consts-2, r=eddyb
Support const args in type dependent paths (Take 2)
once more, except it is sound this time :smiling_face_with_three_hearts: previously #71154
-----
```rust
#![feature(const_generics)]
struct A;
impl A {
fn foo<const N: usize>(&self) -> usize { N }
}
struct B;
impl B {
fn foo<const N: usize>(&self) -> usize { 42 }
}
fn main() {
let a = A;
a.foo::<7>();
}
```
When calling `type_of` for generic const arguments, we now use the `TypeckTables` of the surrounding body to get the expected type.
This alone causes cycle errors though, as we now have `typeck_tables_of(main)` -> `...` ->
`type_of(main_ANON0 := 7)` -> `typeck_tables_of(main)` :zap: (see https://github.com/rust-lang/rust/issues/68400#issuecomment-611760290)
To prevent this we must not call `type_of(const_arg)` during `typeck_tables_of`. This is achieved by
calling `type_of(param_def_id)` instead.
We have to somehow remember the `DefId` of the param through all of typeck, which is done using the
struct `ty::WithOptConstParam<DefId>`, which replaces `DefId` where needed and contains an `Option<DefId>` to
be able to store the const parameter in case it exists.
Queries which are currently cached on disk are split into two variants: `query_name`(cached) and `query_name_(of|for)_const_arg`(not cached), with `query_name_of_const_arg` taking a pair `(did, param_did): (LocalDefId, DefId)`.
For some queries a method `query_name_of_opt_const_arg` is added to `TyCtxt` which takes a `ty::WithOptConstParam` and either calls `query_name` or `query_name_of_const_arg` depending on the value of `const_param_did`.
This now reuses `fn discriminant_ty` in project, removing
some code duplication. Doing so made me realize that
we previously had a disagreement about the discriminant
type of generators, with MIR using `u32` and codegen and
trait selection using `i32`.
Auto merge of #71272 - jclulow:illumos-x86-ci, r=pietroalbini
build dist for x86_64-unknown-illumos
This change creates a new Docker image, "dist-x86_64-illumos", and sets
things up to build the full set of "dist" packages for illumos hosts, so
that illumos users can use "rustup" to install packages. It also
adjusts the manifest builder to expect complete toolchains for this
platform.
Handle case of incomplete local ty more gracefully
When encountering a local binding with a type that isn't completed, the
parser will reach a `=` token. When this happen, consider the type
"complete" as far as the parser is concerned to avoid further errors
being emitted by parse recovery logic.
projects / rust.git / log