Skip to content
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

Store HIR ForeignItem in a side table #79318

Merged
merged 7 commits into from
Nov 27, 2020
Merged

Store HIR ForeignItem in a side table #79318

merged 7 commits into from
Nov 27, 2020

Conversation

cjgillot
Copy link
Contributor

In a similar fashion to Item, ImplItem and TraitItem.

@rust-highfive
Copy link
Collaborator

r? @varkor

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 22, 2020
@lcnr
Copy link
Contributor

lcnr commented Nov 22, 2020

didn't look through it completely yet, but from what I can see this is really awesome and what I should have done a few months ago while I was looking into this 👍

good job

@cjgillot
Copy link
Contributor Author

Is this enough to close #37713?

@bors
Copy link
Contributor

bors commented Nov 25, 2020

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

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@varkor
Copy link
Member

varkor commented Nov 26, 2020

It may take me a little while to get to this, as it's quite busy for me at the moment, so if someone else is happy to review, do go ahead. Otherwise I'll get to it as soon as I can!

@lcnr
Copy link
Contributor

lcnr commented Nov 26, 2020

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Nov 26, 2020

⌛ Trying commit 624f07fed26127b737495cfe15719ecd9d273a34 with merge 30a62b3f272e155d4aba84177ea7147d78f85afc...

@bors
Copy link
Contributor

bors commented Nov 26, 2020

☀️ Try build successful - checks-actions
Build commit: 30a62b3f272e155d4aba84177ea7147d78f85afc (30a62b3f272e155d4aba84177ea7147d78f85afc)

@rust-timer
Copy link
Collaborator

Queued 30a62b3f272e155d4aba84177ea7147d78f85afc with parent aefcf1f, future comparison URL.

Copy link
Contributor

@lcnr lcnr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

some small nits

@@ -29,6 +29,7 @@ macro_rules! arena_types {
[] field_pat: rustc_hir::FieldPat<$tcx>,
[] fn_decl: rustc_hir::FnDecl<$tcx>,
[] foreign_item: rustc_hir::ForeignItem<$tcx>,
[] foreign_item_ref: rustc_hir::ForeignItemRef<$tcx>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense to use [few] here?

Don't know how big of an impact this has but foreign items are probably quite rare.

compiler/rustc_hir/src/hir.rs Show resolved Hide resolved
@@ -277,6 +289,14 @@ pub trait Visitor<'v>: Sized {
walk_list!(self, visit_impl_item, opt_item);
}

/// Like `visit_nested_item()`, but for impl items. See
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// Like `visit_nested_item()`, but for impl items. See
/// Like `visit_nested_item()`, but for foreign items. See

@@ -1225,7 +1225,7 @@ impl EncodeContext<'a, 'tcx> {
hir::ItemKind::Mod(ref m) => {
return self.encode_info_for_mod(item.hir_id, m, &item.attrs);
}
hir::ItemKind::ForeignMod(_) => EntryKind::ForeignMod,
hir::ItemKind::ForeignMod{..} => EntryKind::ForeignMod,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
hir::ItemKind::ForeignMod{..} => EntryKind::ForeignMod,
hir::ItemKind::ForeignMod { .. } => EntryKind::ForeignMod,

auto formatting inside of macros

@@ -447,6 +447,8 @@ impl<'v, 'k, 'tcx> ItemLikeVisitor<'v> for LifeSeeder<'k, 'tcx> {
fn visit_impl_item(&mut self, _item: &hir::ImplItem<'_>) {
// ignore: we are handling this in `visit_item` above
}

fn visit_foreign_item(&mut self, _item: &'v hir::ForeignItem<'v>) {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is currently incorrect, but already was so before this PR.

#[repr(C)]
struct Type(u8);

extern "C" {
    #[allow(dead_code)]
    fn hey(t: Type);
}

shouldn't warn for Type because type is used by fn hey.
Should probably open a separate issue for this unless you quickly want to fix this in a followup PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Investigating in a follow-up PR.

@@ -37,6 +37,8 @@ impl<'v, 'tcx> ItemLikeVisitor<'v> for DiagnosticItemCollector<'tcx> {
fn visit_impl_item(&mut self, impl_item: &hir::ImplItem<'_>) {
self.observe_item(&impl_item.attrs, impl_item.hir_id);
}

fn visit_foreign_item(&mut self, _foreign_item: &hir::ForeignItem<'_>) {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fn visit_foreign_item(&mut self, _foreign_item: &hir::ForeignItem<'_>) {}
fn visit_foreign_item(&mut self, foreign_item: &hir::ForeignItem<'_>) {
self.observe_item(foreign_item.attrs, foreign_item.hir_id);
}

we currently do this manually in line 107, but should just do this here.

@@ -45,6 +45,8 @@ impl<'a, 'tcx> ItemLikeVisitor<'tcx> for EntryContext<'a, 'tcx> {
fn visit_impl_item(&mut self, _impl_item: &'tcx ImplItem<'tcx>) {
// Entry fn is never a trait item.
}

fn visit_foreign_item(&mut self, _: &'tcx ForeignItem<'tcx>) {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fn visit_foreign_item(&mut self, _: &'tcx ForeignItem<'tcx>) {}
fn visit_foreign_item(&mut self, _: &'tcx ForeignItem<'tcx>) {
// Entry fn is never a foreign item.
}

comments are fun 🤷

@@ -378,6 +378,8 @@ impl<'a, 'tcx> ItemLikeVisitor<'tcx> for CollectPrivateImplItemsVisitor<'a, 'tcx
fn visit_impl_item(&mut self, _impl_item: &hir::ImplItem<'_>) {
// processed in visit_item above
}

fn visit_foreign_item(&mut self, _foreign_item: &hir::ForeignItem<'_>) {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fn visit_foreign_item(&mut self, _foreign_item: &hir::ForeignItem<'_>) {}
fn visit_foreign_item(&mut self, _foreign_item: &hir::ForeignItem<'_>) {
// We never export foreign functions as they have no body to export.
}

At least that's how I understand this, not completely sure about that 😆

@@ -499,7 +499,7 @@ impl<'tcx> Visitor<'tcx> for MissingStabilityAnnotations<'tcx> {
// optional. They inherit stability from their parents when unannotated.
if !matches!(
i.kind,
hir::ItemKind::Impl { of_trait: None, .. } | hir::ItemKind::ForeignMod(..)
hir::ItemKind::Impl { of_trait: None, .. } | hir::ItemKind::ForeignMod{..}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
hir::ItemKind::Impl { of_trait: None, .. } | hir::ItemKind::ForeignMod{..}
hir::ItemKind::Impl { of_trait: None, .. } | hir::ItemKind::ForeignMod { .. }

formatting 🤷

@lcnr
Copy link
Contributor

lcnr commented Nov 26, 2020

r? @lcnr

@rust-highfive rust-highfive assigned lcnr and unassigned varkor Nov 26, 2020
@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (30a62b3f272e155d4aba84177ea7147d78f85afc): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-perf

@lcnr
Copy link
Contributor

lcnr commented Nov 27, 2020

thanks 👍

@bors r+ rollup=never

@bors
Copy link
Contributor

bors commented Nov 27, 2020

📌 Commit d6b22fa has been approved by lcnr

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 27, 2020
@bors
Copy link
Contributor

bors commented Nov 27, 2020

⌛ Testing commit d6b22fa with merge c922857...

@bors
Copy link
Contributor

bors commented Nov 27, 2020

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing c922857 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 27, 2020
@bors bors merged commit c922857 into rust-lang:master Nov 27, 2020
@rustbot rustbot added this to the 1.50.0 milestone Nov 27, 2020
@cjgillot cjgillot deleted the fitem branch November 27, 2020 16:25
@rylev
Copy link
Member

rylev commented Dec 3, 2020

@cjgillot @lcnr this change caused a ~4% regression in the extern stress test. It might be worth thinking about why that is since that perf test is likely to exercise this change quite a bit.

@lcnr
Copy link
Contributor

lcnr commented Dec 3, 2020

With this PR we now have an additional allocation for each extern item as well as a BTreeMap which stores all of them.

Building the additional tree in hir lowering is probably the cause of the slowdown of the extern stress test. I do not think this regression is something to worry about because that benchmark is pretty much the worst case by defining a lot of extern items without doing anything else with them.

This PR reduces the amount of false edges in the query graph, meaning that changing the definition of an extern item shouldn't invalidate as many queries as before as seen in the changes to our incremental tests. That should result in perf improvements in some cases. Would it make sense add an incremental test changing the definition of an extern item to the extern stress test?

It is also a improvement to the way we deal with extern items, which can be seen in #79318 (comment) where it allowed us to easily detect a bug.

@rylev
Copy link
Member

rylev commented Dec 3, 2020

changing the definition of an extern item

Can you explain the nature of the change to the definition that you'd want to see? I'm not sure I fully follow.

@lcnr
Copy link
Contributor

lcnr commented Dec 3, 2020

The relevant changes would change ForeignItemKind without changing ForeignItemRef.

So afaict possible changes would be

  • adding an attribute
  • changing the generics or function signature of an extern function
  • changing the mutability of an extern static
  • going from an extern static to an extern function with the same name and visibility.

cc @cjgillot we store the Span of the whole extern item in the ForeignItemRef, does this mean that incremental gets dirtied whenever we change the size of the extern item definition?

@cjgillot
Copy link
Contributor Author

cjgillot commented Dec 3, 2020

Yes. AFAICT, the whole HIR is dirtied by spans changes. I had started #72015 to remove dirtying by spans. It is blocked on perf regressions (~few %). For attributes, I have #79519 with a similar idea, blocked on a bug.

flip1995 pushed a commit to flip1995/rust that referenced this pull request Dec 6, 2020
Store HIR ForeignItem in a side table

In a similar fashion to Item, ImplItem and TraitItem.
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 8, 2020
Visit ForeignItems when marking dead code

Follow-up to rust-lang#79318

r? `@lcnr`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants