try to not rely on attributes from extern crates · Issue #505 · rust-lang/compiler-team (original) (raw)

Proposal

see zulip for some previous discussion.

We currently encode all attributes in the crate metadata, even if the attribute should only be needed in the local crate. I tried to change that in rust-lang/rust#95562 by filtering builtin attributes which should only be used in the local crate for the sake of performance. While that works, it is quite easy to accidentally miss one place where we use the attribute directly in another crate, causing surprising failures, see rust-lang/rust#95562 (comment) where that happened with #[inline].

Attributes are also generally not a great way to store information, considering that they have to be re-parsed each time they are used.

I would like to work towards not encoding attributes in the crate metadata at all, by adding specialized data structures for all attributes which are needed in other crates instead.

As that can't happen all at once, I propose the following steps:

land don't encode only locally used attrs rust#95562 with changes to get_attrs to also detect misuse, causing any incorrect accesses to cause an ICE
start to move existing attributes to a different encoding, also changing them to only_local
if the previous step continues to have a positive - or at least neutral - perf impact and does not negatively impact the maintainability of rustc, stop encoding attributes entirely and remove the item_attrs query

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention then here. You can put your own name here if you are planning to mentor the work.

Process

The main points of the Major Change Process are as follows:

File an issue describing the proposal.
A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
- Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.