Recomputing TargetDataLayout from the string is incorrect

[workingjubilee]

The actual computation we want to do will require additional information from the Target. We need to enrich it with enough information to make it actually useful to Rust. I will probably be making it impossible to use the string parsing as an entry point into that type.

[workingjubilee]

Where do you even get that string?

[Veykril]

From rustc --print target-spec-json: https://github.com/rust-lang/rust-analyzer/blob/6df12139bccaaeecf6a34789e0ca799d1fe99c53/crates/project-model/src/toolchain_info/target_data_layout.rs

[workingjubilee]

Mhm. Had a feeling.

[workingjubilee]

Is there a reason you don't just immediately compute all the data from the target and store that instead?

[Veykril]

I am not sure I follow, this is the only way for us to access the target data for a given target tuple, especially now that t-compiler decided to not librarify rustc_target.

[workingjubilee]

@Veykril oh, it's more I am wondering why the Result<Arc<str>, Arc<str>> hangs around in the workspace_data.

[Veykril]

Ah, that's because of dependencies. The crate that invokes rustc for the info string does not depend on rustc_abi deliberately