Closed
Description
I tried this code:
./x test --doc
and ./x test --no-doc
I expected to see this happen: All tests passing. No doc tests running when using --no-doc
Instead, this happened:
failures:
[ui] tests/ui/mismatched_types/issue-36053-2.rs
[ui] tests/ui/typeck/issue-31173.rs
[ui] tests/ui/recursion/issue-83150.rs
test result: FAILED. 4 passed; 3 failed; 15247 ignored; 0 measured; 0 filtered out; finished in 630.84ms
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu
Build completed unsuccessfully in 0:00:0
Meta
rustc --version --verbose
:
rustc 1.72.0-nightly (f0411ffce 2023-05-30)
binary: rustc
commit-hash: f0411ffcebcd7f75ac02ed45feb53ffd07b75398
commit-date: 2023-05-30
host: x86_64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.4```
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_ASSIGN_START -->
<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"mdibaiee"}$$TRIAGEBOT_ASSIGN_DATA_END -->
<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Metadata
Metadata
Assignees
Labels
Area: Messages for errors, warnings, and lintsArea: The testsuite used to check the correctness of rustcCategory: This is a bug.Call for participation: Medium difficulty. Experience needed to fix: Intermediate.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
[-]Issue when running rustdoc tests[/-][+]Multiple tests failing on upstream pull[/+]saethlin commentedon Jul 7, 2023
The tests pass for me and they're passing in CI. So I suspect there is something about your system that differs from mine and CI.
Can you post the contents of your
config.toml
?compiler-errors commentedon Jul 7, 2023
Also, could you share how these tests are failing? Failing tests usually explain why their stderr differs from expected, or otherwise explain why the test happened to fail.
cchiw commentedon Jul 7, 2023
Hi there, I just did a fresh clone and got the same failures (target x86_64-unknown-linux-gnu). The Cargo.toml file has not been changed. The test pass when I used my Mac device.
The test each have "The actual stderr differed from the expected stderr." The actual stderr seems to have extra lines " ...the full type name has been written to.." which are not in the expected stderr. Could that be the cause of the failure? If so, what can a fix look like?
Full output on terminal:
output.txt
compiler-errors commentedon Jul 7, 2023
@cchiw is your copy of rust cloned into some really deep directory path? like...
/home/blah/blah/long_directory_name/even_more/folders/rust
?the problem is that your tests are failing because your build is producing type names that hit the length limit and are spilled to disk, and that file limit is dependent (unfortunately) on the path that the rust clone is located at...
compiler-errors commentedon Jul 7, 2023
we should probably fix this so that UI tests don't spill any long type names to disk by default.
We could do this by adding a compiler flag that disables this behavior, and enable that flag by default in the ui testing suite.
jyn514 commentedon Jul 8, 2023
this is a great idea — if we do this, we should also remove the code that enables remap-path-prefix in CI.
mdibaiee commentedon Jul 13, 2023
I can reproduce this locally by cloning
rust
under a long path. I would like to work on this. I'll take a look to see if I can identify where we have the logic for spilling the type names to disk, and guard it with a flag. I'll ask questions if I have trouble with that.@rustbot claim
jyn514 commentedon Jul 13, 2023
alternatively, we could gate it under the existing
-Z ui-testing
flagmdibaiee commentedon Jul 15, 2023
I have code that works for this, but there are some tests under
tests/ui
that seem to actually test specifically this behaviour of spilling to disk. So I'm thinking, underui_testing
we skip spilling to disk, unless there is another flag,-Z force-long-type-name-disk-spill
enabled, in which case we spill long type names to disk so that logic can be tested as well. Thoughts?mdibaiee commentedon Jul 15, 2023
Two examples I found where we are testing the long type name spilling behaviour:
jyn514 commentedon Jul 15, 2023
👍 this seems good. i would bikeshed the name as
-Z write-long-types-to-disk
and uncouple it from-Z ui-testing
(i.e. compiletest would start passing-Z write-long-types-to-disk=no
instead of you changing the behavior ofui-testing
), but i like the idea :)[-]Multiple tests failing on upstream pull[/-][+]"the full type name has been written to disk" causes UI tests to fail[/+]mdibaiee commentedon Jul 24, 2023
I have a pull-request for this, but I'm getting an error in the CI pipeline that I haven't dug too deep into, was wondering if there is a simple explanation for this? #113893 (comment)
Thanks
mdibaiee commentedon Jul 25, 2023
@jyn514 The pull-request is going through well, but I'm now wondering about this part:
Do you mean to basically revert this pull-request: #110115
mdibaiee commentedon Jul 26, 2023
Pull-request to remove remap-path-prefix code for CI builds: #114090
Rollup merge of rust-lang#114090 - mdibaiee:remove-remap-path-prefix-…