-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
try to not rely on attributes from extern crates #505
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. cc @rust-lang/compiler @rust-lang/compiler-contributors |
@rustbot second |
@rustbot label -final-comment-period +major-change-accepted |
don't encode only locally used attrs Part of rust-lang/compiler-team#505. We now filter builtin attributes before encoding them in the crate metadata in case they should only be used in the local crate. To prevent accidental misuse `get_attrs` now requires the caller to state which attribute they are interested in. For places where that isn't trivially possible, I've added a method `fn get_attrs_unchecked` which I intend to remove in a followup PR. After this pull request landed, we can then slowly move all attributes to only be used in the local crate while being certain that we don't accidentally try to access them from extern crates. cc rust-lang#94963 (comment)
don't encode only locally used attrs Part of rust-lang/compiler-team#505. We now filter builtin attributes before encoding them in the crate metadata in case they should only be used in the local crate. To prevent accidental misuse `get_attrs` now requires the caller to state which attribute they are interested in. For places where that isn't trivially possible, I've added a method `fn get_attrs_unchecked` which I intend to remove in a followup PR. After this pull request landed, we can then slowly move all attributes to only be used in the local crate while being certain that we don't accidentally try to access them from extern crates. cc rust-lang/rust#94963 (comment)
…es in the crate metadate. Thank you. This is part of changing attributes to only_local. I hope get your opinion whether I should split into multiple PRs, or submit in one. According to [try to not rely on attributes from extern crates](rust-lang/compiler-team#505) and lcnr's guidance.
…es in the crate metadate. Thank you. This is part of changing attributes to only_local. I hope get your opinion whether I should split into multiple PRs, or submit in one. According to [try to not rely on attributes from extern crates](rust-lang/compiler-team#505) and lcnr's guidance.
…es in the crate metadate. Thank you. This is part of changing attributes to only_local. I hope get your opinion whether I should split into multiple PRs, or submit in one. According to [try to not rely on attributes from extern crates](rust-lang/compiler-team#505) and lcnr's guidance.
…r=<try> By changing some attributes to only_local, reducing encoding attributes in the crate metadate. Thank you. This is part of changing attributes to only_local. I hope get your opinion whether I should split into multiple PRs, or submit in one. According to [try to not rely on attributes from extern crates](rust-lang/compiler-team#505) and lcnr's guidance.
…, r=lcnr By changing some attributes to only_local, reducing encoding attributes in the crate metadate. Thank you. This is part of changing attributes to only_local. I hope get your opinion whether I should split into multiple PRs, or submit in one. According to [try to not rely on attributes from extern crates](rust-lang/compiler-team#505) and lcnr's guidance.
Rollup merge of rust-lang#121493 - surechen:edit_attribute_only_local, r=lcnr By changing some attributes to only_local, reducing encoding attributes in the crate metadate. Thank you. This is part of changing attributes to only_local. I hope get your opinion whether I should split into multiple PRs, or submit in one. According to [try to not rely on attributes from extern crates](rust-lang/compiler-team#505) and lcnr's guidance.
Modified according to rust-lang/compiler-team#505. By running test cases, I found that modifying the attribute's only_local tag sometimes causes some unintuitive error reports, so I tend to split it into multiple PRs and edit a small number of attributes each time to prevent too many changes at once. Prevent possible subsequent difficulties in locating problems.
…_20240226, r=lcnr Changing some attributes to only_local. Modified according to rust-lang/compiler-team#505. By running test cases, I found that modifying the attribute's only_local tag sometimes causes some unintuitive error reports, so I tend to split it into multiple PRs and edit a small number of attributes each time to prevent too many changes at once. Prevent possible subsequent difficulties in locating problems. r? `@lcnr`
…_20240226, r=lcnr Changing some attributes to only_local. Modified according to rust-lang/compiler-team#505. By running test cases, I found that modifying the attribute's only_local tag sometimes causes some unintuitive error reports, so I tend to split it into multiple PRs and edit a small number of attributes each time to prevent too many changes at once. Prevent possible subsequent difficulties in locating problems. r? ``@lcnr``
…_20240226, r=lcnr Changing some attributes to only_local. Modified according to rust-lang/compiler-team#505. By running test cases, I found that modifying the attribute's only_local tag sometimes causes some unintuitive error reports, so I tend to split it into multiple PRs and edit a small number of attributes each time to prevent too many changes at once. Prevent possible subsequent difficulties in locating problems. r? ```@lcnr```
…_20240226, r=lcnr Changing some attributes to only_local. Modified according to rust-lang/compiler-team#505. By running test cases, I found that modifying the attribute's only_local tag sometimes causes some unintuitive error reports, so I tend to split it into multiple PRs and edit a small number of attributes each time to prevent too many changes at once. Prevent possible subsequent difficulties in locating problems. r? `@lcnr`
Modified according to rust-lang/compiler-team#505.
…_20240226, r=lcnr Changing some attributes to only_local. Modified according to rust-lang/compiler-team#505. By running test cases, I found that modifying the attribute's only_local tag sometimes causes some unintuitive error reports, so I tend to split it into multiple PRs and edit a small number of attributes each time to prevent too many changes at once. Prevent possible subsequent difficulties in locating problems. r? ``@lcnr``
Rollup merge of rust-lang#121661 - surechen:change_attribute_to_local_20240226, r=lcnr Changing some attributes to only_local. Modified according to rust-lang/compiler-team#505. By running test cases, I found that modifying the attribute's only_local tag sometimes causes some unintuitive error reports, so I tend to split it into multiple PRs and edit a small number of attributes each time to prevent too many changes at once. Prevent possible subsequent difficulties in locating problems. r? ``@lcnr``
…_20240228, r=lcnr Changing some attributes to only_local. Modified according to rust-lang/compiler-team#505. r? `@lcnr`
…_20240228, r=lcnr Changing some attributes to only_local. Modified according to rust-lang/compiler-team#505. r? ``@lcnr``
Rollup merge of rust-lang#121740 - surechen:change_attribute_to_local_20240228, r=lcnr Changing some attributes to only_local. Modified according to rust-lang/compiler-team#505. r? ``@lcnr``
Modified according to rust-lang/compiler-team#505.
Modified according to rust-lang/compiler-team#505.
Modified according to rust-lang/compiler-team#505.
Modified according to rust-lang/compiler-team#505.
…l_20240304, r=lcnr Change some attributes to only_local. Modified according to rust-lang/compiler-team#505. r? `@lcnr`
…l_20240304, r=lcnr Change some attributes to only_local. Modified according to rust-lang/compiler-team#505. r? ``@lcnr``
Rollup merge of rust-lang#122014 - surechen:change_attributes_to_local_20240304, r=lcnr Change some attributes to only_local. Modified according to rust-lang/compiler-team#505. r? ``@lcnr``
…al_20240314, r=lcnr Change some attribute to only_local Modified according to rust-lang/compiler-team#505. r? `@lcnr`
Rollup merge of rust-lang#122477 - surechen:change_attribute_only_local_20240314, r=lcnr Change some attribute to only_local Modified according to rust-lang/compiler-team#505. r? `@lcnr`
…14, r=lcnr Change some attribute to only_local Modified according to rust-lang/compiler-team#505. r? `@lcnr`
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:
get_attrs
to also detect misuse, causing any incorrect accesses to cause an ICEonly_local
item_attrs
queryMentors 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:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
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.
The text was updated successfully, but these errors were encountered: