Uplift .dSYM for unit tests as well

[jiegec]

Describe the problem you are trying to solve

Currently, debug symbols are uplifted for binaries and examples only, see

cargo/src/cargo/core/compiler/build_context/target_info.rs

Lines 260 to 269 in e618d47

	// See rust-lang/cargo#4490, rust-lang/cargo#4960.
	// Only uplift debuginfo for binaries.
	// - Tests are run directly from `target/debug/deps/` with the
	// metadata hash still in the filename.
	// - Examples are only uplifted for apple because the symbol file
	// needs to match the executable file name to be found (i.e., it
	// needs to remove the hash in the filename). On Windows, the path
	// to the .pdb with the hash is embedded in the executable.
	let is_apple = target_triple.contains("-apple-");
	if *kind == TargetKind::Bin || (*kind == TargetKind::ExampleBin && is_apple) {

Related Issue: #4490.

Yet it seems that the path in executable key in cargo json format output points to target/debug/xxx-hash instead of target/debug/deps/xxx-hash, so tools like Intellij Rust fail to debug these tests: intellij-rust/intellij-rust#3680.

Cargo json output:

{
    "reason": "compiler-artifact",
    "package_id": "project 0.1.0 (path+file:///path/to/project)",
    "target": {
        "kind": [
            "lib"
        ],
        "crate_types": [
            "lib"
        ],
        "name": "project",
        "src_path": "/path/to/project/src/lib.rs",
        "edition": "2018",
        "doctest": true
    },
    "profile": {
        "opt_level": "0",
        "debuginfo": 2,
        "debug_assertions": true,
        "overflow_checks": true,
        "test": true
    },
    "features": [

    ],
    "filenames": [
        "/path/to/project/target/debug/project-123462f2a057f680"
    ],
    "executable": "/path/to/project/target/debug/project-123462f2a057f680",
    "fresh": true
}

Only /path/to/project/target/debug/deps/project-123462f2a057f680.dSYM exists, but /path/to/project/target/debug/project-123462f2a057f680.dSYM doesn't. So lldb can't pick up debug symbols when debugging /path/to/project/target/debug/project-123462f2a057f680.

Describe the solution you'd like

I think there are three possible solutions:

1. Change the executable path in JSON to /path/to/project/target/debug/deps/project-123462f2a057f680
2. Add symlink
3. Let those tools handle this specific case

Notes

Related issue: rust-lang/rust#59907

[jiegec]

A comprehensive description on this issue is posted by @kwhrtsk at https://github.com/kwhrtsk/rust-lldb-workaround.

[ehuss]

I don't know the history of how or why things work this way. It looks like 1.0 placed the binary directly into target/debug/ and ran directly from there. Then, in 1.12 it changed to executing directly out of deps/, but it still linked it into the parent (via #2919). It doesn't look like there was any discussion about tests. I can't imagine why tests still needs to be linked to target/debug/ if those filenames are inherently un-discoverable without the JSON output.

One argument for removing the link is that some tests make assumptions about the directory they run from (like this). That might be an argument that tools should only execute from deps/ to match the behavior of Cargo?

Can you (or @alexcrichton) think of any reason it would be bad to stop linking tests into target/debug/?

[alexcrichton]

What you pointed out is the only thing that I can think of, by changing where we execute tests we change env::current_exe() which might affect programs relying on their location to find sibling binaries. Recently we added env vars for this though so they should be switching to those env vars regardless.

IMO we should have the flexibility to do w/e we want (in general) with the target directory to fix issues like this, it's just a matter of how to best get there. We may have to wait for the env vars to propagate to stable before we make a change to not uplift tests.

[ehuss]

by changing where we execute tests

To be clear, I'm not suggesting changing where it is executed. Currently Cargo executes it out of target/debug/deps/, but the JSON message says the artifact is in target/debug/. I'm suggesting to change the JSON, and to potentially just stop linking to target/debug/ altogether, since nothing should be relying on it (if we change the JSON path).

[alexcrichton]

Oh dear my bad, then yeah I can't think of any reason to not change the JSON and stop uplifting the tests.

[jiegec]

Done in #7965