Skip to content

compiletest: compare-mode false negatives w.r.t. long type file path #136510

Closed
@jieyouxu

Description

@jieyouxu

Random comment while I was in the neighborhood.

When using -Zwrite-long-types-to-disk=yes, we usually normalize away the hash in the long type file name, but that's not enough. Using a compare-mode will embed the compare mode in the long type file path as well.

The path note: the full name for the type has been written to '$TEST_BUILD_DIR/diagnostic-width/E0271.unicode/E0271.long-type-hash.txt' will become note: the full name for the type has been written to '$TEST_BUILD_DIR/diagnostic-width.$compare-mode/E0271.unicode/E0271.long-type-hash.txt' and the test will fail.

I encountered this while looking over the test failures under the new solver, i.e. ./x test bla --compare-mode=next-solver. While this specific test will currently fail for different reasons, it should pass in general without any changes required to diagnostics. (you can check that this test will fail under e.g. --compare-mode polonius)

For that, we'd need either:

  • compiletest to take care of all normalizations needing to be done due to compare-modes
  • expand what we manually normalize in the tests, taking care of the compare-mode suffix, as well as the possible hash

Since we already do part of the latter, I personally went with option 2 in #136310, and expanded the regex to look for the complete file path to remove the subdirectories.

For cases that have a hash suffix to normalize away, like in this E0271 test, it looks like:

// The regex below normalizes the long type file name to make it suitable for compare-modes.
//@ normalize-stderr: "'\$TEST_BUILD_DIR/.*\.long-type-\d+.txt'" -> "'$$TEST_BUILD_DIR/$$FILE.long-type-hash.txt'"

One could remove the comment to avoid reblessing the new line numbers. (Or simplify the regex, I went with making sure only this path output would be changed. The hash suffix normalization doesn't do that, nor did the .nll/ -> "" compare-mode normalization)

I already took care of long-E0308 and so on in that other PR (so they will conflict/require reblessing), but the same issue will also appear in the new long-e0277.rs test here.

Thanks for coming to my TED talk.

Originally posted by @lqd in #136328 (comment)

Metadata

Metadata

Assignees

Labels

A-compiletestArea: The compiletest test runnerA-compiletest-compare-modesArea: compiletest compare-modesA-compiletest-normalizationsArea: compiletest normalizationsA-testsuiteArea: The testsuite used to check the correctness of rustcC-bugCategory: This is a bug.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions