"the full type name has been written to disk" causes UI tests to fail

[cchiw]

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 -->

[saethlin]

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]

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]

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]

@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]

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]

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.

this is a great idea — if we do this, we should also remove the code that enables remap-path-prefix in CI.

[mdibaiee]

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]

We could do this by adding a compiler flag that disables this behavior, and enable that flag by default in the ui testing suite.

alternatively, we could gate it under the existing -Z ui-testing flag

[mdibaiee]

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, under ui_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]

Two examples I found where we are testing the long type name spilling behaviour:

• https://github.com/rust-lang/rust/tree/bef6ff618f17398775e9d8cd23a6f47d983869dc/tests/ui/issues/issue-37311-type-length-limit
• https://github.com/rust-lang/rust/blob/bef6ff618f17398775e9d8cd23a6f47d983869dc/tests/ui/diagnostic-width/long-E0308.rs with https://github.com/rust-lang/rust/blob/bef6ff618f17398775e9d8cd23a6f47d983869dc/tests/ui/diagnostic-width/long-E0308.stderr

[jyn514]

So I'm thinking, under ui_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?

👍 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 of ui-testing), but i like the idea :)

[mdibaiee]

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]

@jyn514 The pull-request is going through well, but I'm now wondering about this part:

we should also remove the code that enables remap-path-prefix in CI.

Do you mean to basically revert this pull-request: #110115

[mdibaiee]

Pull-request to remove remap-path-prefix code for CI builds: #114090