-
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
Make crate linkage rules less error-prone #2135
Comments
what to do in the case that multiple libraries with identical metadata are found in various paths? |
if they have the exact same meta hash then the one that was found first is chosen. |
I guess that leaves open the possibility for the same types of confusion if you have a new version in the working directory but on old version installed and they both have the same version. |
Probably the injected |
If they have the same metadata, they'll have the same hash. |
de35288 adds the error when Currently, if you have two copies of the same crate version (not necessarily bit-identical) in two different, searched paths, then rustc will fail. This could impact cargo since it appears to use a scheme where it searches a primary location then a fallback location, then the system default location. In practice, if you use cargo to install libfoo globally then also locally, it will not be usable. |
I added an additional sanity check in 5dd1677 that issues a warning when |
Considering this done. We can have follow-up bugs for specific issues as they come up. |
We were emitting warnings using the warn macro at every occurrence of a concurrent constructs, which wasn't very user friendly. Instead, we now aggregate them and only print one warning at the end, similar to how we handle unsupported constructs. Co-authored-by: Zyad Hassan <88045115+zhassan-aws@users.noreply.github.com>
Lately we've been hitting a lot of problems where rustc picks the wrong version of a crate from multiple candidates. Sometimes this happens from picking the 0.1 crate when it should pick 0.2, sometimes because there are multiple 0.2 crates and it picks the wrong one randomly.
There are two parts to this solution. This first is just being more disciplined about our
use
statements (#2069).The second part involves adding a check to creader that there is only a single match. When there are multiple matching crates it will list them and their associated linkage metadata then error. In order to recover from the error the code must create more specific
use
statements until there is no ambiguity.This leaves an open problem when there are two matching crates with the same linkage metadata. Usually in this case you just want do delete the old ones, but we could also allow
use
to match on the crate hash itself.The text was updated successfully, but these errors were encountered: