Implement initial version of cfg(accessible(..))

[crlf0710]

Implements an initial version of cfg(accessible(..)). The code includes a few FIXMEs, and i think i need some help with understanding how things suppose to work before i can solve them. Also, maybe i need some advice on organizing these code.

I'll assign to Vadim but feel free to reassign.

cc #64797

r? @petrochenkov

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[Urgau]

This doesn't seems to share any code with the already implemented cfg_accessible macro.

What's the plan with that earlier attempt? Replace it with this one?

[crlf0710]

What's the plan with that earlier attempt?

I guess we can decide that after the we work out the "advice on organizing these code" part :)

[tgross35]

There seem to be existing tests at tests/ui/conditional-compilation/cfg_accessible-*, maybe these should stay in the same place? Or just make a new cfg-accessible directory and move everything there.

[crlf0710]

Ack, will move those files in the next push. Any advice on the implementation?

[tgross35]

I don't know too much about this area of the compiler unfortunately, petrochenkov is probably the expert here. Just happened to notice the existing tests while doing a driveby of this feature's history.

[bors]

☔ The latest upstream changes (presumably #135726) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

I think it makes sense to combine the this PR and the old implementation to implement this strategy.

• It can be implemented as #[cfg(accessible)] (as opposed to #[cfg_accessible]) and resolver can be passed to cfg-expander, like in this PR.
• The path resolution can just be taken from the old implementation, the special logic from cfg_accessible_crate/cfg_accessible_mod/cfg_accessible_item shouldn't be necessary.
• If the resolution logic returns Indeterminate we must immediately produce a user-facing error, because we cannot postpone it if we are in cfg.
• The existing test suite for cfg_accessible should be duplicated for cfg(accessible), preferably in the same files to highlight possible differences in behavior.
• The time travel prevention should be implemented in any case, it's need for both cfg(accessible) and cfg_accessible.

I suggest starting with the last item and submitting it as a separate PR.
The examples of very similar logic can be found by searching for uses of single_segment_macro_resolutions and multi_segment_macro_resolutions, which are used for time travel prevention in macro paths.

[petrochenkov]

Suggested change

	Some(ref cfg) => rustc_attr_parsing::eval_condition(
	Some(ref cfg) => attr::cfg_matches(cfg, sess, CRATE_NODE_ID, None, None),

Is the CfgEval trait really necessary?
I think adding an optional resolver (*) parameter to eval_condition/cfg_matches would be enough.
Then the code here and in trait selection will require no changes besides adding a single None.

eval_condition should produce an error on encountering accessible if the resolver is None.

(*) Perhaps hidden under a trait, if the compiler crate dependency structure doesn't allow passing it directly.

[crlf0710]

ok, let me see if removing it works better.

[petrochenkov]

I'm not sure why this is necessary if None always turns into false anyway.

[crlf0710]

My intention was to make #[cfg(not(invalid_cfg))] and #[cfg(invalid_cfg)] both acts as #[cfg(FALSE)]. I can leave comment in the code if it's not obvious enough.

[petrochenkov]

One example why time travel is still necessary even with the new "restricted" rules - extern prelude changes as crate expands and extern_prelude_get can give different results at different points in time.

[crlf0710]

extern_prelude_get can give different results at different points in time

Now I realize i didn't really understand how the extern prelude works. I'll reach you on Zulip to gain better understanding on this bullet point before i continue.

[crlf0710]

Personally i'm not very in favor of these lines of code. Here are the reasons:

• The original design already opens lots of possibility for typos within the path, which encourages footguns :(
• I changed quite a few of function signatures from &self to &mut self, which might become trouble when these parts of compiler got parallelized.
• There's fundamental inconsistency between cfg's one-pass processing and resolver's multi stage-processing. This reflects within the fact that the extern prelude dynamically changes during compilation (I actually didn't realize this until i send the code for review!).

Also, this code brings up the problem of difference between crate level attributes and root module inner attributes, which is solvable but it's its own can of worms.

I think i'll just close this draft PR for now. If anyone feel any code snippet is useful, feel free to copy-paste anything.