update rustc_index_macros feature handling

[onur-ozkan]

It seems that cargo can't conditionally propagate features if they were enabled by default on the target crate, but disabled with default-features = false in the current/parent crate.

Fixes #118129

[rustbot]

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

That is... weird. I'll take a look tmrw.
r? jieyouxu

[RalfJung]

It seems that cargo can't conditionally propagate features when default-features is set to false.

What do you mean by this?

[onur-ozkan]

This does not work.

[RalfJung]

It does seem to work sometimes though? Only particular ./x.py invocations are broken.

[onur-ozkan]

I couldn't see anything that could be related in bootstrap.

[RalfJung]

Note that if this truly does not work you'll have to also change it here

rust/compiler/rustc_abi/Cargo.toml

Lines 13 to 32 in eca1702

	rustc_index = { path = "../rustc_index", default-features = false }
	rustc_macros = { path = "../rustc_macros", optional = true }
	rustc_serialize = { path = "../rustc_serialize", optional = true }
	rustc_span = { path = "../rustc_span", optional = true }
	tracing = "0.1"
	# tidy-alphabetical-end
	[features]
	# tidy-alphabetical-start
	default = ["nightly", "randomize"]
	# rust-analyzer depends on this crate and we therefore require it to built on a stable toolchain
	# without depending on rustc_data_structures, rustc_macros and rustc_serialize
	nightly = [
	"dep:rustc_data_structures",
	"dep:rustc_feature",
	"dep:rustc_macros",
	"dep:rustc_serialize",
	"dep:rustc_span",
	"rustc_index/nightly",
	]

and in the dozen other places where we do the same thing.

I think the first step would be to reproduce this in a minimal example and file a cargo issue, if this is really the problem.

[onur-ozkan]

Yeah, I saw those too. This PR was kind of a hotfix for the problem you experienced to improve the developer experience. I think it's worth filing an issue on the cargo side, will do that today.

[RalfJung]

Hm yeah this PR does fix that problem... I have no idea why, given that the same pattern is still used in a whole bunch of other places.

[jieyouxu]

I think it's worth filing an issue on the cargo side, will do that today.

I think we probably should wait until we hear back from T-cargo before merging this (even as a hotfix)... I don't quite understand this current behavior either.

[jieyouxu]

Ok, I did some more testing. This PR's changes notably still passes tests/run-make/rustc-crates-on-stable, i.e. the compiler crates that need to compile on stable still continues to compile on stable (more or less). AFAICT it also preserves the behavior of the non-nightly-ness of rustc_index_macros as a dep for rustc_index. I tried something different like making rustc_index_macros truly optional, and while that also addresses the original report it also regresses tests/run-make/rustc-crates-on-stable (as expected).

[onur-ozkan]

Yeah, I saw those too. This PR was kind of a hotfix for the problem you experienced to improve the developer experience. I think it's worth filing an issue on the cargo side, will do that today.

I tried to create a simple reproduction in a new cargo workspace but I couldn't reproduce it. I am not sure what is the special case in compiler tree, but I don't want to spend more time on this since there are alternative x invocations and we already have a fix (which is this PR) for the broken one.

[jieyouxu]

Yeah, I also tried to make a smaller repro but failed.

@bors r+ rollup=iffy

[bors]

📌 Commit e151148 has been approved by jieyouxu

It is now in the queue for this repository.