-
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
Spurious "found two different crates with name alloc
" errors in PR builder
#64389
Comments
Some relatively unscientific digging for where we create SVHs dug up this bit of code -- that sort_unstable looks rather suspicious, as it's presumably possible for two crates with different hashes to end up in a different order, and then when we go on to hash it it'll lead to problems down the line if the sort resulted in a different ordering then we'd expect. To be clear, thinking some more about this, I think it's presumably fine for this to be an unstable sort since an unstable sort should still have stable output, it just might be different than input order, AIUI -- what's not fine is that we're introducing non-determinism by not sorting by hash. cc @michaelwoerister who I believe is the original author of this bit of code in 8129c53 cc @Zoxc @aturon -- this is a potentially interesting case for wg-parallel-rustc to examine, as it's a case where we need to be careful about ordering in a subtle way -- the output of a query is assumed to be ordering-stable across compilations, otherwise this svh computation won't work well I believe, though not certain |
Another note is that this is likely to prove rather hard to track down as to what caused this as we've seen relatively few of these errors - the PR description lists one case, and anecdotal data suggests maybe around 6 or so errors that we've noted like this. Interestingly, all were specifically in these liballoc doctests which explicitly have an I personally suspect this is sort of due to #63470 which likely causes us to keep around more artifacts than previously and perhaps one of those is contaminating the path whereas it didn't before; to be clear, this exposed the bug perhaps but almost certainly didn't cause it. |
Has this happened before #63827? |
I believe so, but not completely confident. It occurs really rarely, so it's hard to be certain unfortunately. |
Copying my comment from discord: Cargo usually takes care of correctly setting crate disambiguators but if this occurs in a setup that is not driven by Cargo, then that might be the source of the bug. Two versions of the same crate must always be compiled with differing crate disambiguators. The disambiguators are how we implement supporting multiple versions of the same crate. Another note: The following line should make sure that we sort lexicographically (as opposed to some kind of pointer value) here: If that is not the case for some reason, the sort order would indeed be undeterministic. |
I haven't seen this reproduced for a long time so I'll close it for now. |
There was similar error recently but with |
Triage: Has anyone here seen this error in recent years? |
GitHub search shows the most recent this particular message was in #67281, 4 years ago. The error message has since changed. I'm going to close, since I don't think this is a direct issue anymore. Here are my notes: The error appeared when compiling
There was a verification step in #100928 migrated to use the new diagnostics. #100599 removed the particular message and replaced it with a bug!:
Looks like the authors couldn't find a way to create a test for it, and thought that maybe it was an unreachable section. Shortly afterwards, the bug! and SVH check was simply removed in #109213 which refactored things to eagerly verify collisions (updated in #111461). Now, if there are two crates with the same stable crate ID, the errors are now:
Searching for those error messages doesn't pull up anything recent. |
to_str
implementation #64429 (comment)The text was updated successfully, but these errors were encountered: