Extend the build directive syntax with cargo::

[0xPoe]

What does this PR try to resolve?

close #11461

Extend the build directive syntax with cargo:: and update tests and docs.

How should we test and review this PR?

Check out the unit tests.

[rustbot]

r? @weihanglo

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

[0xPoe]

A lot of code and docs need to update. I will update it later.

[0xPoe]

• update other error messages
• update other docs
• add more tests

[epage]

Thanks!

@bors r+

[bors]

📌 Commit dec9e8c has been approved by epage

It is now in the queue for this repository.

[bors]

⌛ Testing commit dec9e8c with merge d45969a...

[bors]

☀️ Test successful - checks-actions
Approved by: epage
Pushing d45969a to master...

[0xPoe]

Thanks for your review! 💚 💙 💜 💛 ❤️

[weihanglo]

Just thought of target.<triple>.<links>. The TOML table accepts arbitrary keys as metadata keys. Should we also extend the format?

cargo/src/cargo/util/config/target.rs

Lines 225 to 228 in 74ef21b

	_ => {
	let val = value.string(key)?.0;
	output.metadata.push((key.clone(), val.to_string()));
	}

[0xPoe]

Should we also extend the format?

Do you mean we should add a prefix to those metadata keys? For instance: metadata-KEY = VALUE.

It seems that the purpose of this is just to override rustc configurations. Therefore, I'm unsure if we need to support it here.

cargo/src/cargo/util/config/target.rs

Line 223 in 74ef21b

anyhow::bail!("`{}` is not supported in build script overrides", key);

[weihanglo]

I mean, it is definitely a breaking change if we want to extend more keys to override from build scripts. Actually #10274 may break stuff if people already used key like rustc-link-arg-tests as a metadata key (which is rare).

Huh… maybe it's too hard and not worthy of a transition.

[epage]

I created #13211 to track this