Fix crate-version with rustdoc in bootstrap.

[ehuss]

Cargo will now automatically use the --crate-version flag (see rust-lang/cargo#8509). Cargo has special handling to avoid passing the flag if it is passed in via RUSTDOCFLAGS, but the rustdoc wrapper circumvents that check. This causes a problem because rustdoc will fail if the flag is passed in twice. Fix this by using RUSTDOCFLAGS.

This will be necessary when 1.47 is promoted to beta, but should be safe to do now.

[rust-highfive]

r? @Mark-Simulacrum

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

[ehuss]

Hm, so I completely forgot that the non-dev version string has a space in it, which won't work with RUSTDOCFLAGS. That's...unfortunate. I'm trying to decide how to deal with this. Some options I'm considering:

• Use cargo's -Zadvanved-env which allows spaces in env vars via TOML. It only works with config values, so it would need to be specified via CARGO_BUILD_RUSTDOCFLAGS.
  • I could introduce space support for RUSTDOCFLAGS in cargo, but that would need to wait until beta promotion.
• Use cargo's --config CLI option which allows passing config values on the cli via TOML (like build.rustdocflags).
• Revert Stabilize -Z crate-versions cargo#8509 until there is better support for args with spaces.
• Maybe pass --crate-version as a command-line flag here. I don't like that because the rustc/rustdoc flags use cargo doc which doesn't allow flags.

Do any of those options sound reasonable? Or any other ideas? I would probably lean towards advanced-env.

[Mark-Simulacrum]

The version string is 1.47.0-nightly (81dc88f 2020-08-13), right? Could we swap the space for   or perhaps some Unicode space?

An other option is to pass a fake version via RUSTDOCFLAGS and then swap it out in our wrapper...

Do you have some sense of how stable we expect the toml environment stuff to be? If it's pretty likely to not change (much) then I think that's probably our best bet. I wouldn't mind the (simpler?) fix of not using a real space though.

[ehuss]

The version string is 1.47.0-nightly (81dc88f 2020-08-13), right?

Yes.

Could we swap the space for   or perhaps some Unicode space?

I had the same idea. Rustdoc escapes the &, so that won't work. Unicode spaces work, though I was worried that was a little too magical or potentially confusing. I'm pretty sure it won't break on linux, macos, and windows, but I'm not sure about other unusual platforms.

With nbsp, it gets a little too wide for the sidebar, particularly with the nightly/beta strings. Of course Unicode has a million other spaces to choose from. en-space (\u2002) looks pretty much the same as the original. I went ahead and pushed a commit with that change, WDYT?

Do you have some sense of how stable we expect the toml environment stuff to be?

Unfortunately I don't. It was an experiment that we haven't really pursued too much.

[Mark-Simulacrum]

r=me either way - I think a new line might be a bit better, but I don't care much either way.

[Mark-Simulacrum]

This might be a bit out there, but should work more uniformly across platforms I think. If cargo is splitting by regular ASCII space only, we could use a new line here.

That said, thinking some more about this it seems really error prone - anyone can replace that splitting with split_whitespace which would break us here. But I feel like that's not too big a deal, we can fix it as needed. Would you be up for adding a Cargo test as well so that the (potential) breakage is detected earlier?

[ehuss]

Ah, I like newline better.

I'll put it on my todo list to add a regression test in cargo.

[ehuss]

@bors r=Mark-Simulacrum

[bors]

📌 Commit 85a9cfa has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 85a9cfa with merge 5205b97...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: Mark-Simulacrum
Pushing 5205b97 to master...