test: Prepare tests for new Cargo build-dir layout

[ranger-ross]

This PR prepares the clippy testsuite to work with the new Cargo build-dir layout tracked in rust-lang/cargo#16807.

Context: In rust-lang/rust#155439 we attempt to enable the new Cargo build-dir layout in rust-lang/rust and I am working through all of the build failures caused by changing where the files are.

Also note that the ui_test crate was bumped to include the corresponding fix in oli-obk/ui_test#368

With the changes in this PR the following test passes on my system.

CARGO_UNSTABLE_BUILD_DIR_NEW_LAYOUT=true ./x test --stage 2 src/tools/clippy

changelog: none

[rustbot]

r? @samueltardieu

rustbot has assigned @samueltardieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: 7 candidates
• 7 candidates expanded to 7 candidates
• Random selection from Jarcho, dswij, llogiq, samueltardieu

[samueltardieu]

I'm not familiar with the new layout, but when I look at my local Clippy ui_test's debug/build I can see several versions of the proc-macro2 crate:

libc-cef78c73a588beef
lock_api-322a98564ef4bbc0
parking_lot_core-6b4e77ee5c9c43aa
proc-macro2-29604991fe83921e
proc-macro2-70ecf6aed0aea7e6
proc-macro2-b8940090bfe979a4
serde-de22b5d9748dde25

Can this be a problem, or will the compiler sort them out? (even though there is a debug/deps so this won't be used right now)

View changes since the review

[ranger-ross]

This is expected. Those are actually different Cargo "build units" of the same crate.
proc-macro2 has a build.rs meaning those 3 units are likely:

• the proc-macro library itself (.rmeta)
• the build script binary (build_script_build[.exe])
• the build script execution

This should not affect compilation as Cargo know's which units it needs to add.
In the case of the test logic, there should be no difference since previous we were adding -L .../deps which adds everything to library search path. With the new layout we have to pass multiple -L args since they are in different directories, but the result should stay the same.

Ideally Cargo could have a better mechanism for exposing these paths in the future.

[samueltardieu]

Another novice question: isn't there a risk if an old deps directory still lies around when build starts being used? Wouldn't deps get precedence even though it is now obsolete?

[ranger-ross]

That is correct. (though only for the tests, cargo build will always use the correct one)
I went with a backwards compatible change here to ease the transition as there are many changes needed to enable in rust-lang/rust.

Once the new build-dir layout is stabilized we can remove support for building with older Cargos that still use deps

[samueltardieu]

After removing all target dirs, this command fails:

$ CARGO_UNSTABLE_BUILD_DIR_NEW_LAYOUT=true cargo test -F internal

with

FAILURES:
    tests/ui-internal/interning_literals.rs
    tests/ui-internal/collapsible_span_lint_calls.rs
    tests/ui-internal/unnecessary_def_path.rs
    tests/ui-internal/symbol_as_str.rs
    tests/ui-internal/invalid_msrv_attr_impl.rs
    tests/ui-internal/repeated_is_diagnostic_item_unfixable.rs
    tests/ui-internal/repeated_is_diagnostic_item.rs

View changes since this review