-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sysroot spans are not printed on some targets (affected: Debian, rust-lang's own i586; unaffected: Fedora) #53081
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Our
|
related: #54546 |
Strangely, if I run rust's own upstream binary compiler from here the output is also missing error details.
|
@oli-obk you created |
cc @michaelwoerister This looks like it might be related to file paths for libcore, not being found when running tests. |
FWIW here is the output with
Hopefully it's easy to reproduce with rust-lang's own |
@michaelwoerister would our usage of
|
I am able to repro this at will in my CI environment if anyone has suggestions on extra logging to add or data to collect. |
I'm not sure what the correct action to resolve this issue is. Is it to change our test suite so it stops showing code snippets from the standard library? |
One way to fix this, assuming |
This affects not just distros building Rust; at least some tests on the |
This is certainly not a good practice. |
With #66049 I am at least consolidating the existing work-arounds for this problem to all point to this issue here. There's around a dozen instances of this in our test suite. |
consistent handling of missing sysroot spans Due to rust-lang#53081, sysroot spans (pointing to code in libcore/libstd/...) fails to print on some x86 runners. This consolidates the ignore directives for that and references the relevant issue. I also did that for the generated derive-error-span tests -- but there the script and the tests were not entirely in sync any more since rust-lang#64151. Cc @estebank @varkor
consistent handling of missing sysroot spans Due to rust-lang#53081, sysroot spans (pointing to code in libcore/libstd/...) fails to print on some x86 runners. This consolidates the ignore directives for that and references the relevant issue. I also did that for the generated derive-error-span tests -- but there the script and the tests were not entirely in sync any more since rust-lang#64151. Cc @estebank @varkor
This seems to have affected windows as well. |
Teach `compiletest` to ignore platform triples The UI tests are written assuming `--remap-path-prefix` is *not used* (`remap-debuginfo` in `config.toml`). The consequence is that the error messages may include paths and snippets into the standard library. When `remap-debuginfo` is enabled, these messages change in format and structure because `rustc` will not show paths and snippets into the standard library. This normally isn't a problem for the "main" platforms (linux/macos/windows), because the CI infrastructure is set up so that the tests run without `remap-debuginfo`, but the `dist` artifacts are built separately with `remap-debuginfo` enabled. However, some of the lower-tier platforms perform both tests and distribution in a single step with `remap-debuginfo` enabled. This also affects developers and distributors who use `remap-debuginfo`. To sidestep this problem, we add a way to ignore tests in specific platform triples, and update the overly broad `ignore-x86` rule in affected tests. Address rust-lang#46948, rust-lang#54546, rust-lang#53081.
Teach `compiletest` to ignore platform triples The UI tests are written assuming `--remap-path-prefix` is *not used* (`remap-debuginfo` in `config.toml`). The consequence is that the error messages may include paths and snippets into the standard library. When `remap-debuginfo` is enabled, these messages change in format and structure because `rustc` will not show paths and snippets into the standard library. This normally isn't a problem for the "main" platforms (linux/macos/windows), because the CI infrastructure is set up so that the tests run without `remap-debuginfo`, but the `dist` artifacts are built separately with `remap-debuginfo` enabled. However, some of the lower-tier platforms perform both tests and distribution in a single step with `remap-debuginfo` enabled. This also affects developers and distributors who use `remap-debuginfo`. To sidestep this problem, we add a way to ignore tests in specific platform triples, and update the overly broad `ignore-x86` rule in affected tests. Address #46948, #54546, #53081.
I took a deeper look at this, and the simplest approach for fixing #53486 won't directly fix this. That's because there's no equivalent to the I'll work around that by removing a I'm also worried this might leak into codegen and cause non-deterministic builds, so we might have to do it only for loading the contents and diagnostics, or probably just gate the rewriting on For the longest time I was confused and thought this needed "distcheck" to reproduce, but it's really just The remaining (non-failing) 26 tests that mention the issue are all |
EDIT(@eddyb): For a detailed update/explanation, see #53081 (comment).
I'm trying to track down why we have this diff on all arches, which causes that test to fail:
Test, test output
The test passes on Fedora.
Two main things we're doing differently in Debian is that we're currently using cargo 0.27 to build (rather than cargo 0.28) and we also omit some components. However I don't see why either of these should affect the above test output. I also can't see why our other patches should affect it.
The text was updated successfully, but these errors were encountered: