Rollup merge of #74251 - shepmaster:bootstrap-target-files, r=Mark-Simulacrum
Teach bootstrap about target files vs target triples
`rustc` allows passing in predefined target triples as well as JSON
target specification files. This change allows bootstrap to have the
first inkling about those differences. This allows building a
cross-compiler for an out-of-tree architecture (even though that
compiler won't work for other reasons).
Even if no one ever uses this functionality, I think the newtype
around the `Interned<String>` improves the readability of the code.
Rollup merge of #74169 - ecstatic-morse:dataflow-unreachable, r=pnkfelix
Stop processing unreachable blocks when solving dataflow
...instead we `debug_assert` that the user is not checking the dataflow state for an unreachable block. This resolves a FIXME in the dataflow engine. The old behavior was an artifact of the previous dataflow framework. Things should run a tiny bit faster now, but I suspect not enough to show up in benchmarks. AFAIK, only the generator transform runs dataflow on MIR with unreachable basic blocks.
This PR also adds some utility methods to `mir::traversal`.
Rollup merge of #74056 - fusion-engineering-forks:fmt-arguments-as-str, r=Amanieu
Add Arguments::as_str().
There exist quite a few macros in the Rust ecosystem which use `format_args!()` for formatting, but special case the one-argument case for optimization:
```rust
#[macro_export]
macro_rules! some_macro {
($s:expr) => { /* print &str directly, no formatting, no buffers */ };
($s:expr, $($tt:tt)*) => { /* use format_args to write to a buffer first */ }
}
```
The problem with these is that a forgotten argument such as in `some_macro!("{}")` will not be diagnosed, but just prints `"{}"`.
With this PR, it is possible to handle the no-arguments case separately *after* `format_args!()`, while simplifying the macro. Then these macros can give the proper error about a missing argument, just like `print!("{}")` does, while still using the same optimized implementation as before.
This is even more important with [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795), to make sure `some_macro!("{some_variable}")` works as expected.
Rollup merge of #74009 - mati865:mingw-tests-implib, r=nikomatsakis
Fix MinGW `run-make-fulldeps` tests
`compiler-rt-works-on-mingw` and `libs-search-path` were not ran because `only-mingw` doesn't match any target.
Enabled and verified few ignored tests with `windows-gnu` toolchain. They are still ignored on MSVC since I'm not experienced with this target.
Rollup merge of #73930 - a1phyr:feature_const_option, r=dtolnay
Make some Option methods const
Tracking issue: #67441
Constantify the following methods of `Option`:
- `as_ref`
- `is_some`
- `is_none`
- `iter` (not sure about this one, but it is possible, and will be useful when const traits are a thing)
Rollup merge of #71670 - GuillaumeGomez:enforce-codeblocks-attribute-check, r=Mark-Simulacrum
Enforce even more the code blocks attributes check through rustdoc
`rustdoc` now has a lint which allows it to warn if a code block attribute is malformated (which can end up in bad situations, even more in case of testing examples!). Now it'll fail if such a situation is encountered when testing markdown code blocks examples.
When ran on Windows `cp` will follow symlink: `checkout/build/<target>/<stage>/lib/rustlib/src/rust`.
It points to `checkout` which means the test will get stuck in copying loop until there is no space left.
Teach bootstrap about target files vs target triples
`rustc` allows passing in predefined target triples as well as JSON
target specification files. This change allows bootstrap to have the
first inkling about those differences. This allows building a
cross-compiler for an out-of-tree architecture (even though that
compiler won't work for other reasons).
Even if no one ever uses this functionality, I think the newtype
around the `Interned<String>` improves the readability of the code.
Auto merge of #73365 - Manishearth:rustdoc-vis, r=GuillaumeGomez
Record visibility of reexports for all items, not just type items
This fixes https://github.com/rust-lang/rust/issues/73363
Unfortunately I can't add a test for this since this bug is obscured by the cross-crate bug, being fixed in https://github.com/rust-lang/rust/issues/73363 . Tests will be added later.
Auto merge of #74395 - Mark-Simulacrum:stage0-next, r=pietroalbini
Bump version to 1.47
This also bumps to a more recent rustfmt version, just to keep us relatively up to date (though almost nothing has changed in rustfmt we use beyond bumps to the parser infra). No formatting changes as a result of this.
Auto merge of #74422 - Manishearth:rollup-7mfrf6g, r=Manishearth
Rollup of 8 pull requests
Successful merges:
- #73101 (Resolve items for cross-crate imports relative to the original module)
- #73269 (Enable some timeouts in SGX platform)
- #74033 (Add build support for Cargo's build-std feature.)
- #74351 (Do not render unstable items for rustc doc)
- #74357 (Some `Symbol` related improvements)
- #74371 (Improve ayu rustdoc theme)
- #74386 (Add RISC-V GNU/Linux to src/tools/build-manifest as a host platform)
- #74398 (Clean up E0723 explanation)
Rollup merge of #74371 - Aloso:patch-1, r=GuilliameGomez
Improve ayu rustdoc theme
This PR changes the following:
* It makes some lines darker
* It gives the crate selector and search bar a border
* The search bar's border turns blue when focused
* ~~Gives the logo a bright shadow.~~
For standard library crates, it would be better to invert the logo, but that would be bad for crates with a colored logo, e.g. [async-std](https://docs.rs/async-std/1.6.2/async_std/).
Rollup merge of #74351 - lzutao:remove-rustc-internal-compiler-warns, r=Mark-Simulacrum
Do not render unstable items for rustc doc
See the zulip conversion: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc.20doc.3A.20.22internal.20compiler.20API.22.20warns.20are.20everywhere!/near/203850782
Rollup merge of #74033 - ehuss:std-compile-all-platforms, r=Mark-Simulacrum
Add build support for Cargo's build-std feature.
This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform.
Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally, there is a "restricted-std" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future.
This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi, hermit, and sgx), but I figure that can be done in a future PR.
There are some small changes to stable behavior in this PR:
- `std::env::consts::ARCH` on asmjs now reports "wasm32", to match its actual architecture.
- Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused.
There should otherwise not be any changes to how std is built for distribution via bootstrap.
This does not yet support all platforms when used with build-std.
- It doesn't work with 16-bit targets (hashbrown does not support that).
- It does not work with JSON spec targets.
- In particular, all target triple snooping will need to be replaced with appropriate target option checking.
- Switching to gimli (#73441) will make cross-building *much* easier.
- There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support.
Future PRs are intended to address some of these issues.
This replaces the need for the `description` and `details` symbols in
`UnsafetyViolation`, which are static. As a result some
`Symbol::as_str()` calls are no longer necessary, which is nice.
It's equivalent to `Ident::from_str_and_span`. The commit also
introduces some more static symbols so that `Ident::new` can be used in
various places instead of `Ident::from_str_and_span`.
The commit also changes `Path::path` from a `&str` to a `Symbol`, which
then allows the lifetime annotation to be removed from `Ty`. Also, the
use of `Symbol` in `Bounds` removes the need for its lifetime
annotation.
Auto merge of #74408 - Manishearth:rollup-9gxn4od, r=Manishearth
Rollup of 21 pull requests
Successful merges:
- #73566 (Don't run `everybody_loops` for rustdoc; instead ignore resolution errors)
- #73771 (Don't pollute docs/suggestions with libstd deps)
- #73794 (Small cleanup for E0705 explanation)
- #73807 (rustdoc: glue tokens before highlighting)
- #73835 (Clean up E0710 explanation)
- #73926 (Ignoring test case: [codegen] repr-transparent-aggregates-1.rs for aarch64)
- #73981 (Remove some `ignore-stage1` annotations.)
- #73998 (add regression test for #61216)
- #74140 (Make hir ProjectionKind more precise)
- #74148 (Move #[doc(alias)] check in rustc)
- #74159 (forbid generic params in the type of const params)
- #74171 (Fix 44056 test with debug on macos.)
- #74221 (Don't panic if the lhs of a div by zero is not statically known)
- #74325 (Focus on the current file in the source file sidebar)
- #74359 (rustdoc: Rename internal API fns to `into_string`)
- #74370 (Reintroduce spotlight / "important traits" feature)
- #74390 (Fix typo in std::mem::transmute documentation)
- #74391 (BtreeMap: superficially refactor root access)
- #74392 (const generics triage)
- #74397 (Fix typo in the latest release note)
- #74406 (Set shell for github actions CI)
Rollup merge of #74390 - ColoredCarrot:patch-1, r=lcnr
Fix typo in std::mem::transmute documentation
`u32::from_ge_bytes` function does not exist; replace with `u32::from_be_bytes`.
It is clear that `u32::from_le_bytes` is not meant from the context; the latter is used correctly while `from_be_bytes` is misspelled.
Rollup merge of #74171 - ehuss:44056-debug-macos, r=nikomatsakis
Fix 44056 test with debug on macos.
The test `codegen/issue-44056-macos-tls-align.rs` fails on macos if `debug-assertions` is enabled in `config.toml`. It has the following error:
```
/Users/eric/Proj/rust/rust/src/test/codegen/issue-44056-macos-tls-align.rs:9:11: error: CHECK: expected string not found in input
// CHECK: @STATIC_VAR_1 = thread_local local_unnamed_addr global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4
^
/Users/eric/Proj/rust/rust/build/x86_64-apple-darwin/test/codegen/issue-44056-macos-tls-align/issue-44056-macos-tls-align.ll:1:1: note: scanning from here
; ModuleID = 'issue_44056_macos_tls_align.3a1fbbbh-cgu.0'
^
/Users/eric/Proj/rust/rust/build/x86_64-apple-darwin/test/codegen/issue-44056-macos-tls-align/issue-44056-macos-tls-align.ll:9:1: note: possible intended match here
@STATIC_VAR_1 = thread_local global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4
^
```
Comparing the output, the actual output is missing the text "`local_unnamed_addr`".
The fix here is to ignore `local_unnamed_addr`, as it doesn't seem relevant to the test.
@eddyb and I talked [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/type.20of.20const.20parameters/near/203405696) about this and we probably want to also forbid generic consts in the default
type of a parameter, e.g. `struct Foo<T, U = [u8; std::mem::size_of::<T>()]>`, this is currently still allowed
and I will probably fix that in a followup PR.
Rollup merge of #73981 - ehuss:remove-ignore-stage1, r=nikomatsakis
Remove some `ignore-stage1` annotations.
These tests appear to no longer need the `ignore-stage1` marker.
- `run-make-fulldeps/issue-37839` and `run-make-fulldeps/issue-37893`: I believe these were due to the use of proc-macros, and probably were just missed in #49219 which fixed the proc-macro compatibility.
- `compile-fail/asm-src-loc-codegen-units.rs`: This was due to an old issue with landing pads (as mentioned in the linked issue #20184). `-Zno-landing-pads` was an option when building the first stage (it was much faster), but somewhere along the way (I think the switch from makefiles to rustbuild), the option was removed.
- NOTE: This test doesn't actually test what it was originally written for, and is probably mostly pointless now. This test was asserting the message "build without -C codegen-units for more exact errors", but that was removed in #42682. It is now in essence identical to `asm-src-loc.rs`.
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.
projects / rust.git / log