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

Make crate linkage rules less error-prone #2135

Closed
brson opened this issue Apr 5, 2012 · 8 comments
Closed

Make crate linkage rules less error-prone #2135

brson opened this issue Apr 5, 2012 · 8 comments
Assignees
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Milestone

Comments

@brson
Copy link
Contributor

brson commented Apr 5, 2012

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.

@ghost ghost assigned brson Apr 5, 2012
@nikomatsakis
Copy link
Contributor

what to do in the case that multiple libraries with identical metadata are found in various paths?

@brson
Copy link
Contributor Author

brson commented Apr 5, 2012

if they have the exact same meta hash then the one that was found first is chosen.

@brson
Copy link
Contributor Author

brson commented Apr 5, 2012

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.

@brson
Copy link
Contributor Author

brson commented Apr 6, 2012

Probably the injected use core needs to automatically use the correct version.

@graydon
Copy link
Contributor

graydon commented Apr 6, 2012

If they have the same metadata, they'll have the same hash.

@brson
Copy link
Contributor Author

brson commented Apr 6, 2012

de35288 adds the error when creader finds multiple crates that match for a use statement.

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.

@brson
Copy link
Contributor Author

brson commented Apr 6, 2012

I added an additional sanity check in 5dd1677 that issues a warning when creader decides to use multiple crates with the same name. I realize this is a valid use case and we even have a (broken) test for it under run-pass/crateresolve2.rs, but in all current scenarios this will just lead to mystery bugs.

@brson
Copy link
Contributor Author

brson commented Apr 21, 2012

Considering this done. We can have follow-up bugs for specific issues as they come up.

@brson brson closed this as completed Apr 21, 2012
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

3 participants