Add more rust_private attributes

[ljedrz]

I'm working on enabling clippy in x.py and the usage of is_xid_start and is_xid_continue in the components is one of the obstacles. If we are not planning to remove this attribute then it makes sense to use it for these compiler internals, as it is already done with some of the others.

If for any reason this is undesirable, there is probably some way of working around it; otherwise it seems like the most straightforward option.

r? @alexcrichton

[alexcrichton]

I think this is probably indicative of other problems perhaps? These attributes shouldn't be necessary due to how rustbuild builds the compiler crates, and this attribute would otherwise be needed by a much larger number of crates.

I think that clippy integration into rustc will be somewhat difficult, but it'll likely for sure need some tight integration with rustbuild itself!

[ljedrz]

I am trying an approach similar to check (since it's not an issue there); I'm wondering if it has something to do with the cargo process run from within clippy, but the arguments I've tried to "smuggle in" so far (RUSTC_FORCE_UNSTABLE and RUSTC_BOOTSTRAP) didn't do the trick.

[ljedrz]

@alexcrichton An additional effect of this change is the improved ability to execute cargo (clippy/fix) on rustc crates individually; this is desirable if we want to keep them as modular as possible. For example, it allows cargo fix --edition to automatically migrate libproc_macro to the 2018 edition.

[alexcrichton]

Is this still necessary or has it largely moved over to #56595?

[ljedrz]

It is still needed in order for all components to work with x.py clippy with the other PR, but I kept it separate in case there is a better way to achieve this. This PR is also useful on its own, as mentioned in the previous comment.

[alexcrichton]

Hm well as I mentioned before these feature gates should not be necessary, and indicates a bug in the build setup if they're otherwise required. I haven't had a chance to dig into the other PR yet, but if it requires this one then I think that the other PR needs some more work

[bors]

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

[TimNN]

ping from triage @alexcrichton: Could you clarify you previous review? Is this PR entirely infeasible or just needs some additional work?

[alexcrichton]

Oh sorry sure, this PR shouldn't be necessary (and we're building just fine AFAIK today), so I think there may have been something local giong wrong? In any case I'll go ahead and close.