-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
rustc: remove dead code #13244
rustc: remove dead code #13244
Conversation
pub static box_field_refcnt: uint = 0u; | ||
pub static box_field_tydesc: uint = 1u; | ||
pub static box_field_prev: uint = 2u; | ||
pub static box_field_next: uint = 3u; | ||
pub static box_field_body: uint = 4u; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be made 2u
? (same question for other cases)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is used for the offset of the field in the struct. this is hard-coded, and doesn't change with order. if it works today, it will continue to work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I know it'll continue to work. It was more a "Do we want this to be sequential?"
Either way works for me, TBH.
@flaper87 pushed new version |
@@ -1920,10 +1863,6 @@ def_type_content_sets!( | |||
) | |||
|
|||
impl TypeContents { | |||
pub fn meets_bounds(&self, cx: &ctxt, bbs: BuiltinBounds) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is useful. I'm actually surprised that middle::kinds::check_builtin_bounds
doesn't use this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this will probably go away with OIBT, so, feel free to add a FIXME(#13231)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not used today, and if it's going to go away.... why keep it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was more a "I'm surprised it's not being used, I think I'll need it but I'm not sure yet" :D Anyway, ignore this comment. Lets get rid of it.
Added a few more comments. Sorry for not catching those before. |
pub static tag_items_data_item_visibility: uint = 0x4e; | ||
|
||
pub static tag_link_args: uint = 0x4f; | ||
pub static tag_link_args_arg: uint = 0x50; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same concern in this area: maybe numbers could be reassigned sequentially? (maybe a macro could do this automatically?)
review addressed |
I was very confused when reading the git history, because of the name of this branch. |
sorry :) I noticed that the surrounding area needed some cleanup as I was experimenting |
yay! 🍰 |
…r=Veykril Support builtin derive macro helper attributes Closes rust-lang#13244 It's a bit wasteful for `Macro2Data` to have `helpers` field currently just for `Default` derive macro, but I tend to think it's okay for the time being given how rare macro2's are used.
Remove more `snippet_opt` calls First commit is the same as rust-lang#13244 changelog: none
Start removing `snippet_opt` in favor of `get_source_text` Continuing the job of removing unnecessary allocations. changelog: none
No description provided.