-
Notifications
You must be signed in to change notification settings - Fork 13k
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
diagnostics: do not suggest masked crate impls #109688
Conversation
r? @b-naber (rustbot has picked a reviewer for you, use r? to override) |
Some changes occurred in src/librustdoc/clean/types.rs cc @camelid |
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 an improvement, but afaict only partially fixes the issue since this relies on the use of extern crate
.
Can you maybe check that all private dependencies in std are marked #[doc(masked)]
?
#![feature(doc_masked)] | ||
|
||
#[doc(masked)] | ||
extern crate masked_crate; |
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 understand why you include this extern crate
statement here. miniz_oxide
is #[doc(masked)]
in std, so just using the example in the fixed issue as a test should suffice 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.
I wanted to make sure that this test case didn't rely on the specifics of how libstd is implemented right now, so I copied the relevant parts of miniz_oxide into the test case.
When run without the fix, the error message lists both miniz_oxide and masked_crate.
@@ -495,6 +496,25 @@ pub(in crate::rmeta) fn provide(providers: &mut Providers) { | |||
tcx.untracked().cstore.leak(); | |||
tcx.arena.alloc_from_iter(CStore::from_tcx(tcx).iter_crate_data().map(|(cnum, _)| cnum)) | |||
}, | |||
doc_masked_crates: |tcx, LocalCrate| { |
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.
Can you put this functionality in a function and only call that function in the closure here, please? I think keeping the provide
functions short is preferable and is what seems to be done in most places in the compiler.
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.
Okay. It's done.
@@ -2006,6 +2006,7 @@ impl<'tcx> InferCtxtPrivExt<'tcx> for TypeErrCtxt<'_, 'tcx> { | |||
|| !trait_pred | |||
.skip_binder() | |||
.is_constness_satisfied_by(self.tcx.constness(def_id)) | |||
|| self.tcx.is_doc_masked(def_id.krate) |
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.
hm I'm not sure whether relying on an attribute that seems to solely be used in rustdoc inside the trait system is such a good idea. 🤔 But I can't think of a better way to filter for crates we want to ignore here either, so I guess this is fine.
Still can you put a FIXME
here that states that ideally we should't rely on an attribute for extern crate
for 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.
Okay, FIXME added.
@@ -1549,6 +1549,12 @@ impl<'a, 'tcx> CrateMetadataRef<'a> { | |||
self.root.tables.is_intrinsic.get(self, index) | |||
} | |||
|
|||
fn get_doc_masked_crates(self) -> Vec<CrateNum> { | |||
let mut v: Vec<CrateNum> = self.root.doc_masked_crates.decode(self).collect(); | |||
v.sort_unstable(); |
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.
Why do we need to sort 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.
I added a comment describing why it needs sorted. It's so that binary search can be used later.
Since this adds two queries: @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit a28eba9 with merge 46d8dad086555c8fe75815dc84f0f04b9ea287af... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
58f292d
to
ced09d3
Compare
ced09d3
to
622e7eb
Compare
Finished benchmarking commit (46d8dad086555c8fe75815dc84f0f04b9ea287af): comparison URL. Overall result: no relevant changes - no action neededBenchmarking 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. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
I looked again where |
@b-naber That assessment seems accurate. The only times I've seen or heard of this bug, it's been |
Looking at what traits are considered in
rust/compiler/rustc_middle/src/ty/trait_def.rs Lines 221 to 225 in f2d9a3d
rust/compiler/rustc_middle/src/ty/trait_def.rs Lines 229 to 270 in f2d9a3d
I don't see why this would be exclusive to |
The event that’s happening is that the compiler suggests a trait impl from a transitive dependency. It probably occurs all the time, but when it isn’t a private dependency of the standard library, is it considered a bug? |
The correct fix for this issue, I think, would be to not suggest traits from any private dependencies in general and not just for |
No, you make a good call. A proper fix will probably tie into RFC 1977, and require a different implementation tactic. |
Fixes #88696