-
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
Retire ItemLikeVisitor
trait
#96825
Retire ItemLikeVisitor
trait
#96825
Conversation
Some changes occurred in src/tools/clippy. cc @rust-lang/clippy |
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
8bf26ff
to
18de522
Compare
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 18de522d3d1c898efded66bd7a9682fa8f5914ca with merge f39b93d7c3fd9f8a404d16432db96302ec9ab095... |
☀️ Try build successful - checks-actions |
Queued f39b93d7c3fd9f8a404d16432db96302ec9ab095 with parent 4c09a33, future comparison URL. |
Finished benchmarking commit (f39b93d7c3fd9f8a404d16432db96302ec9ab095): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Footnotes |
if let hir::ItemKind::Impl(hir::Impl { of_trait: Some(ref trait_ref), ref items, .. }) = | ||
item.kind | ||
item.kind |
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 wonder if this one also could be implemented without fetching HIR.
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.
If the snippet here is OK, then I will use the same approach here.
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.
The algorithm here needs the Res
from hir::TraitRef
but impl_trait_ref
returns ty::TraitRef
which doesn't have that info. I haven't been able to find to a way to get that data without accessing the HIR.
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.
trait_def_id
is tcx.impl_trait_ref(item.def_id).def_id
.
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.
Sorry I don't follow. We need the Res
not the LocalDefId
or is it not necessary to check the variant of Res
?
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 don't think we need to check the variant here. Let's do it in a follow-up PR so we can test it independently.
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.
Sounds good. I will leave this snippet here.
// We need only trait impls here, not inherent impls, and only non-exported ones
let of_trait = tcx.impl_trait_ref(id.def_id);
if !access_levels.is_reachable(id.def_id) {
let local_def_ids = tcx
.associated_items(id.def_id)
.in_definition_order()
.filter_map(|assoc_item| assoc_item.def_id.as_local());
worklist.extend(local_def_ids);
if !of_trait.def_id.is_local() {
return;
}
worklist.extend(
tcx.provided_trait_methods(of_trait.def_id).map(|assoc| assoc.def_id.expect_local()),
);
}
89daab5
to
76238b6
Compare
.unwrap_or(false); | ||
|
||
if !is_implemented { | ||
to_implement.push(tcx.item_name(trait_item_id).to_string()); |
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.
No need to allocate strings immediately, this can be done when error actually invoked.
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.
@kckeiks ^
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.
No need to allocate strings immediately, this can be done when error actually invoked.
Sorry I almost missed this. I made the changes.
☔ The latest upstream changes (presumably #96473) made this pull request unmergeable. Please resolve the merge conflicts. |
0f13888
to
f7bc51a
Compare
@cjgillot tests are panicing after rebasing changes from #96473. The issue is in
The code that was causing the error fn has_custom_linkage<'tcx>(tcx: TyCtxt<'tcx>, def_id: LocalDefId) -> bool {
// Anything which has custom linkage gets thrown on the worklist no
// matter where it is in the crate, along with "special std symbols"
// which are currently akin to allocator symbols.
let codegen_attrs = tcx.codegen_fn_attrs(def_id);
tcx.def_kind(def_id).has_codegen_attrs()
&& (codegen_attrs.contains_extern_indicator()
|| codegen_attrs.flags.contains(CodegenFnAttrFlags::RUSTC_STD_INTERNAL_SYMBOL)
// FIXME(nbdd0121): `#[used]` are marked as reachable here so it's picked up by
// `linked_symbols` in cg_ssa. They won't be exported in binary or cdylib due to their
// `SymbolExportLevel::Rust` export level but may end up being exported in dylibs.
|| codegen_attrs.flags.contains(CodegenFnAttrFlags::USED)
|| codegen_attrs.flags.contains(CodegenFnAttrFlags::USED_LINKER))
} There were no errors when I changed the function as shown below. fn has_custom_linkage<'tcx>(tcx: TyCtxt<'tcx>, def_id: LocalDefId) -> bool {
// Anything which has custom linkage gets thrown on the worklist no
// matter where it is in the crate, along with "special std symbols"
// which are currently akin to allocator symbols.
if !tcx.def_kind(def_id).has_codegen_attrs() {
return false;
}
let codegen_attrs = tcx.codegen_fn_attrs(def_id);
codegen_attrs.contains_extern_indicator()
|| codegen_attrs.flags.contains(CodegenFnAttrFlags::RUSTC_STD_INTERNAL_SYMBOL)
// FIXME(nbdd0121): `#[used]` are marked as reachable here so it's picked up by
// `linked_symbols` in cg_ssa. They won't be exported in binary or cdylib due to their
// `SymbolExportLevel::Rust` export level but may end up being exported in dylibs.
|| codegen_attrs.flags.contains(CodegenFnAttrFlags::USED)
|| codegen_attrs.flags.contains(CodegenFnAttrFlags::USED_LINKER)
} Is this expected with the changes that were merged? |
Signed-off-by: Miguel Guarniz <mi9uel9@gmail.com>
@bors r+ |
📌 Commit 48fd666 has been approved by |
⌛ Testing commit 48fd666 with merge 4962b6d234092418aeb8b2762b81d5d443a7e857... |
💔 Test failed - checks-actions |
@cjgillot looks like the
Have you seen this issue before? |
@bors retry |
☀️ Test successful - checks-actions |
Finished benchmarking commit (7355d97): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
@cjgillot @kckeiks looks like a performance run was done before this was merged, but I'm not seeing any justification for the regression. In any case, it looks like the regression reproduced after merge. Interestingly, this regression seems to be taking place exclusively in the Is there any reason why the Here's what cachegrind looks like for
|
The previous perf run had identified a regression in the The post-merge perf run shows a completely different regression in the I have no idea what happened. There may be an unexpected interaction with #96885 which was merged in between. @kckeiks do you have an idea what happened? |
…t, r=cjgillot Retire `ItemLikeVisitor` trait Issue rust-lang#95004 cc `@cjgillot`
Issue #95004
cc @cjgillot