Use TargetTriple::from_path in rustdoc

[bjorn3]

This fixes the problem reported in Rust-for-Linux/linux#272 where rustdoc requires the absolute path of a target spec json instead of accepting a relative path like rustc.

[rust-highfive]

r? @jyn514

(rust-highfive has picked a reviewer for you, use r? to override)

[bjorn3]

  /usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=2 origin +d20bfe8ac965fce0c261b2fb0771fbf29324d906:refs/remotes/pull/85361/merge
  remote: Internal Server Error.
  remote: 
  Error: fatal: unable to access 'https://github.com/rust-lang/rust/': The requested URL returned error: 500
  The process '/usr/bin/git' failed with exit code 128

[jyn514]

Can you add a test for the new behavior (maybe a run-make test)?

Where is this logic for rustc, is it possible to reuse it?

[bjorn3]

The logic for rustc is at

rust/compiler/rustc_session/src/config.rs

Lines 1510 to 1521 in 544d124

	fn parse_target_triple(matches: &getopts::Matches, error_format: ErrorOutputType) -> TargetTriple {
	match matches.opt_str("target") {
	Some(target) if target.ends_with(".json") => {
	let path = Path::new(&target);
	TargetTriple::from_path(&path).unwrap_or_else(|_| {
	early_error(error_format, &format!("target file {:?} does not exist", path))
	})
	}
	Some(target) => TargetTriple::TargetTriple(target),
	_ => TargetTriple::from_triple(host_triple()),
	}
	}

[jyn514]

Great. Can you make that function public and use it in rustdoc instead of duplicating it?

[jyn514]

@bjorn3 you made the function public, but didn't use it in rustdoc. Also it would be nice to have the test.

[bjorn3]

I did git add compiler, which doesn't include src/librustdoc. How should I test it? Should I compile the real libcore or use a dummy #![no_core] lib as dependency?

[jyn514]

The error in Rust-for-Linux/linux#258 (comment) confuses me (that is the error this fixes, right?) but if you can write dummy no_core test that fails before and passes after, that sounds great :)

[bjorn3]

that is the error this fixes, right?

Yes

The error in Rust-for-Linux/linux#258 (comment) confuses me

The problem is that when using rustc the full canonicalized path of the target spec json would be used by rustc and thus end up in the metadata of libcore and other dependencies, but when trying to use rustdoc, only the literal value of --target is used, which results in rustc rejecting the metadata due to a different target value.

but if you can write dummy no_core test that fails before and passes after, that sounds great :)

👍

[jyn514]

r=me if you confirmed the test fails before this PR (I can't check right now).

@bors delegate=bjorn3

[jyn514]

nit: can you use include instead so it gives an error if the file is missing?

[bjorn3]

Sure, I just copied another rustdoc test.

[jyn514]

@bors delegate=bjorn3

[bors]

✌️ @bjorn3 can now approve this pull request

[bjorn3]

I manually ran the commands in the test. It failed with a nightly rustc/rustdoc.

@bors r=jyn514

[bors]

📌 Commit 0c99e003cf06ed87998b4a0a05d9a331b1709701 has been approved by jyn514

[jyn514]

@bors r- (until CI is passing)

[bjorn3]

Fixed the test.

@bors r=jyn514

[bors]

📌 Commit 6afc1f4 has been approved by jyn514