Improve librustdoc error when a file creation/modification failed
The message before looks like this:
```
failed to create or modify "/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/search.index/entry/"
```
And with this change it looks like this:
```
failed to create or modify "/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/search.index/entry/": failed to read column from disk: data consumer error: missing field `unknown number` at line 1 column 8
```
r? ``````@lolbinarycat``````
compiler: Include span of too huge enum with `-Cdebuginfo=2`
We have the ui test `tests/ui/limits/huge-enum.rs` to ensure we emit an error if we encounter too big enums. Before this fix, compiling the test with `-Cdebuginfo=2` would not include the span of the instantiation site, because the error is then emitted from a different code path that does not include the span.
Propagate the span to the error also in the debuginfo case, so the test passes regardless of debuginfo level. I'm sure we can propagate spans in more places, but let's start small.
## Test failure without the fix
Here is what the failure looks like if you run the test without the fix:
```
[ui] tests/ui/limits/huge-enum.rs#full-debuginfo ... F
.
failures:
---- [ui] tests/ui/limits/huge-enum.rs#full-debuginfo stdout ----
Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-enum.full-debuginfo/huge-enum.full-debuginfo.stderr`
diff of stderr:
1 error: values of the type `Option<TYPE>` are too big for the target architecture
- --> $DIR/huge-enum.rs:17:9
- |
- LL | let big: BIG = None;
- | ^^^
6
7 error: aborting due to 1 previous error
8
The actual stderr differed from the expected stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args limits/huge-enum.rs`
```
as can be seen, the `span` used to be missing with `debuginfo=2`.
## See also
This is one small step towards resolving rust-lang/rust#61117.
cc https://github.com/rust-lang/rust/pull/144499 which began running UI tests with `rust.debuginfo-level-tests=1`. This PR is part of preparing for increasing that to debuglevel 2.
std: use a TAIT to define `SplitPaths` on UNIX
Defining `SplitPaths` as a TAIT allows using closures instead of function pointers for `split` and `map`.
Avoid more rustc rebuilds in cross-compilation scenarios
This is a continuation of https://github.com/rust-lang/rust/pull/145874.
It adds a `compiler_for_std` function, which is a slimmed down version of `compiler_for`, which is much simpler, and designed to be used only for the standard library.
The build, dist and doc steps somtimes work with a stage2 std for a given target. That currently requires building a stage2 host compiler. However, if we uplift the stage1 libstd anyway, that is wasteful, in particular when we are cross-compiling.
The last two commits progressively make the stage 2 host rustc build avoidance more and more aggressive. I think that if we decide that it is fine to ship stage1 libstd everywhere, then it makes sense to go all the way.
When we ship stuff, we always build it with the stage 1 compiler (e.g. we ship stage 2 rustc which is built with stage 1 rustc). Libstd is the only component where stage N is built with the stage N compiler. So I think that shipping stage 1 libstd is "enough", and we could thus optimize what gets built on CI.
r? `@jieyouxu`
compiletest: Reduce the number of `println!` calls that don't have access to `TestCx`
In order to stop using `#![feature(internal_output_capture)]` in compiletest, we need to be able to capture the console output of individual tests run by the executor.
The approach I have planned is to have all test runners print “console” output into a trait object that is passed around as part of `TestCx`, since almost all test-runner code has easy access to that context. So `println!("foo")` will become `writeln!(self.stdout, "foo")`, and so on.
In order to make that viable, we need to avoid unnecessary printing in places that don't have easy access to `TestCx`. To do so, we can either get rid of unnecessary print statements, or rearrange the code to make the context available. This PR uses both approaches.
r? jieyouxu
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#2 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#1 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
I.e. the type definition, then a single inherent `impl` block, then the
trait `impl` blocks.
The lack of sensible ordering here has bugged me for some time.
This appears to have been leftover debugging code.
If the capture information turns out to have still been useful, we can find a
way to emit it in a way that doesn't interfere with overhauling compiletests's
output capture system.
The code in this module is always called in the context of running an
individual tests, and sometimes prints output that needs to be captured.
Moving this module into `runtest` will make it easier to find and audit all of
the print statements that need to be updated when overhauling output-capture.
Running `./x --verbose` will still print out the command-line arguments, and
setting `RUST_LOG=compiletest` will now log the full config instead of a
subset.
Remove TmpLayout in layout_of_enum
09a3846 from <https://github.com/rust-lang/rust/pull/103693> made LayoutData be owned instead of interned in `Variants::Multiple::variants`[^1], so there's no need for `TmpLayout` in layout_of_enum anymore, and we can just store the variants' layouts directly in the prospective `LayoutData`s' `variants` fields.
This should have no effect on semantics or layout.
(written as part of rust-lang/rust#145337 but not related to the layout optimizations in that PR)
[^1]: see line 1154 of `compiler/rustc_target/src/abi/mod.rs` in the linked commit; `Variants::Multiple::variants` effectively changed from `IndexVec<.., Layout<'tcx>>` to `IndexVec<.., LayoutData>` where the `LayoutData`s are not interned as `Layout`s (`LayoutData` was at the time called `LayoutS`)
fix(std): Fix undefined reference to __my_thread_exit on QNX 8.0
When cross-compiling for the x86_64/aarch64-unknown-nto-qnx800 target (QNX SDP 8.0), the build fails during the final link stage with the error:
```
error: linking with `qcc` failed: exit status: 1
...
= note: undefined reference to `__my_thread_exit'
```
- **On QNX 7.1**: The __my_thread_exit symbol is defined and exported by the main C library (libc.a/libc.so). The std backtrace code can therefore successfully take its address at compile time.
- **On QNX 8.0**: As part of a toolchain modernization, this symbol has been refactored. It is no longer present in any of the standard system libraries (.a or .so).
This patch addresses the problem at its source by conditionally compiling the problematic code.
Fixesrust-lang/rust#142726
Switch next solver to use a specific associated type for trait def id
The compiler just puts `DefId` in there, but rust-analyzer uses different types for each kind of item.
See [the Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Implmentating.20New.20Trait.20Solver/near/534329794). In short, it will be a tremendous help to r-a to use specific associated types, while for the solver and the compiler it's a small change. So I ported `TraitId`, as a proof of concept and it's also likely the most impactful.
r? types
