Code change:
I tried this code: and I expected to see this happen: All tests passing. No doc tests running when using Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
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 ?
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.
Hi there, I just did a fresh clone and got the same failures (target x86_64-unknown-linux-gnu). The 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 " 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:
is your copy of rust cloned into some really deep directory path? like... ? 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...
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.
I can reproduce this locally by cloning 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. claim
alternatively, we could gate it under the existing flag
I have code that works for this, but there are some tests under that seem to actually test specifically this behaviour of spilling to disk. So I'm thinking, under we skip spilling to disk, unless there is another flag, enabled, in which case we spill long type names to disk so that logic can be tested as well. Thoughts?
Two examples I found where we are testing the long type name spilling behaviour: with
:+1: this seems good. i would bikeshed the name as and uncouple it from (i.e. compiletest would start passing instead of you changing the behavior of ), but i like the idea :)
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? Thanks
The pull-request is going through well, but I'm now wondering about this part: Do you mean to basically revert this pull-request:
Pull-request to remove remap-path-prefix code for CI builds:

Related discussion:
text: /// `//[foo]`), then the property is ignored unless `cfg` is /// `Some("foo")`. fn load_from(&mut self, testfile: &Path, cfg: Option<&str>, config: &Config) { <del> // In CI, we've sometimes encountered non-determinism related to truncating very long paths. // Set a consistent (short) prefix to avoid issues, but only in CI to avoid regressing the // contributor experience. if CiEnv::is_ci() { self.remap_src_base = config.mode == Mode::Ui && !config.suite.contains("rustdoc"); } </del> let mut has_edition = false; if !testfile.is_dir() { let file = File::open(testfile).unwrap();