path trimming: ignore type aliases

[da-x]

Continuation of #73996.

[rust-highfive]

r? @davidtwco

(rust_highfive has picked a reviewer for you, use r? to override)

[petrochenkov]

I'm not sure what is the logic here besides "this makes Result unique by getting rid of io::Result and friends".
Is it applicable to other types that are not Result?
Maybe Result should be special-cased as a "well-known" type from prelude instead?

[da-x]

Not sure about treating this as special case. If there are other type names colliding with type aliases, the tests don't reveal them. We'll get a better picture by listing all the type aliases in std and core.

[bors]

☔ The latest upstream changes (presumably #77373) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[davidtwco]

Implementation LGTM; I think I like this change, but I'd like to clarify a few things. These are the primary cases that this concerns, right?

• Alias has same name as type that it aliases - alias would be printed using the full path, but (more common) use of type wouldn't (e.g. Result). This seems reasonable, improves the common case and I don't think it'd lead to much confusion.
• Alias has the same name as an entirely unrelated type (from a different crate, for example), alias would be printed using the full path and if unrelated type were used then it would have its short path printed. Could this lead to a user using alias Foo without a path throughout their code, and then having type Foo (used in their code as foo::Foo) be printed without the full path in diagnostics? That seems like it could be confusing.

[da-x]

@davidtwco can you point to cases where paths to aliases are being printed? AFAIK the type system resolves type aliases so that printed types are fully resolved and are not related to them at all.

[davidtwco]

@davidtwco can you point to cases where paths to aliases are being printed? AFAIK the type system resolves type aliases so that printed types are fully resolved and are not related to them at all.

I was just assuming that was the behaviour. If that isn't the case then I think I'm happy with this change.

[Dylan-DPC-zz]

@davidtwco do you wish to review this again? Or can we consider "happy with this change" as an approval? (pending the trivial conflicts)

[davidtwco]

@davidtwco do you wish to review this again? Or can we consider "happy with this change" as an approval? (pending the trivial conflicts)

Apologies, I should have been clearer and followed-up - I'm happy to see this land after a rebase.

[bors]

☔ The latest upstream changes (presumably #78343) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[crlf0710]

@da-x Ping from triage. I'm sorry but this seems needs a rebase again.

[davidtwco]

Apologies again for being so slow to get back to this review - looks good now.

@bors r+

[bors]

📌 Commit 98f43e1e7c287eda1aeaed8fffe0254f994ef320 has been approved by davidtwco

[bors]

⌛ Testing commit 98f43e1e7c287eda1aeaed8fffe0254f994ef320 with merge 3aa1bf2bc01ad967a5d3db4e42bbe941f92e2f14...

[rust-log-analyzer]

The job x86_64-gnu-llvm-9 failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

diff of stderr:
2 --> $DIR/typeck.rs:10:22
3 |
4 LL | Ok(x) if let Err(_) = x => {},
- | ^^^^^^ expected enum `Option`, found enum `std::result::Result`
+ | ^^^^^^ expected enum `Option`, found enum `Result`
6 |
7 = note: expected enum `Option<bool>`
- found enum `std::result::Result<_, _>`
+ found enum `Result<_, _>`
10 error[E0308]: mismatched types
11 --> $DIR/typeck.rs:12:22
The actual stderr differed from the expected stderr.
Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/rfc-2294-if-let-guard/typeck/typeck.stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args rfc-2294-if-let-guard/typeck.rs`
error: 1 errors occurred comparing output.
status: exit code: 1
status: exit code: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/rfc-2294-if-let-guard/typeck.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zemit-future-incompat-report" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/rfc-2294-if-let-guard/typeck" "-A" "unused" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/rfc-2294-if-let-guard/typeck/auxiliary"
------------------------------------------
------------------------------------------
stderr:
stderr:
------------------------------------------
error[E0308]: mismatched types
--> /checkout/src/test/ui/rfc-2294-if-let-guard/typeck.rs:10:22
|
LL | Ok(x) if let Err(_) = x => {},
| ^^^^^^ expected enum `Option`, found enum `Result`
|
= note: expected enum `Option<bool>`
found enum `Result<_, _>`
error[E0308]: mismatched types
--> /checkout/src/test/ui/rfc-2294-if-let-guard/typeck.rs:12:22
|
|
LL | Ok(x) if let 0 = x => {},
| ^ expected enum `Option`, found integer
|
= note: expected enum `Option<bool>`
found type `{integer}`
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0308`.
---
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu
command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/ui" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--suite" "ui" "--mode" "ui" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-9/bin/FileCheck" "--nodejs" "/usr/bin/node" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--llvm-version" "9.0.0" "--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver engine executionengine fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interpreter ipo irreader jitlink lanai lanaiasmparser lanaicodegen lanaidesc lanaidisassembler lanaiinfo libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option orcjit passes perfjitevents powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvutils runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target textapi transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xcore xcorecodegen xcoredesc xcoredisassembler xcoreinfo xray" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
failed to run: /checkout/obj/build/bootstrap/debug/bootstrap --stage 2 test --exclude src/tools/tidy
Build completed unsuccessfully in 0:16:57

[bors]

💔 Test failed - checks-actions

[da-x]

If it would have reproduced locally, that would have been much easier. However test src/test/run-make-fulldeps runs without errors on my Linux machine. Therefore nailing what needs updating just from looking at the error is tougher, and it seems I'm chasing it out without result.

In the CI, it only fails in one particular Windows rustc port - x86_64-msvc-1. Now the diff is over an output html, and it indicates output instability only for that port with relation to the work in #73996. Perhaps it makes sense that we would disable trimmed paths in that output? If so, adding a relevant with_no_trimmed_paths || wrapper or running the compiler with a flag to disable it will make the output stable for all architectures, and get this finally out of the way.

[davidtwco]

Perhaps it makes sense that we would disable trimmed paths in that output? If so, adding a relevant with_no_trimmed_paths || wrapper or running the compiler with a flag to disable it will make the output stable for all architectures, and get this finally out of the way.

I think this makes sense.

[bors]

☔ The latest upstream changes (presumably #81149) made this pull request unmergeable. Please resolve the merge conflicts.

[da-x]

@bors r=davidtwco

[bors]

📌 Commit 9dc0d1d has been approved by davidtwco

[jonas-schievink]

@bors r- rollup=iffy failed in #81528 (comment)

[davidtwco]

Looks like disabling trimmed paths for that test either didn't work, or there were trimmed paths in the output that weren't undone.

[bors]

☔ The latest upstream changes (presumably #80851) made this pull request unmergeable. Please resolve the merge conflicts.

[da-x]

My mistake so far was not building with profiler = true - now that I noticed and fixed that, my local tests cover these outputs. Even so, I've kept the commit to disable trimmed path for code coverage, as it is more relevant for error messages, and to reduce noise for other devs.

Let's see how it runs now. :)

[da-x]

@bors r=davidtwco

[bors]

📌 Commit 0752415f88179d8a828f95c6569ce0a834981161 has been approved by davidtwco

[bors]

☔ The latest upstream changes (presumably #81257) made this pull request unmergeable. Please resolve the merge conflicts.

[da-x]

@bors r=davidtwco

[bors]

📌 Commit 6495029 has been approved by davidtwco

[bors]

⌛ Testing commit 6495029 with merge 08fdbd5...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing 08fdbd5 to master...