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.

Sign up for GitHub

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

Jump to bottom

Consider prioritising crate search directories #2223

Closed
brson opened this issue Apr 17, 2012 · 1 comment
Closed

Consider prioritising crate search directories #2223

brson opened this issue Apr 17, 2012 · 1 comment
Labels
A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@brson
Copy link
Contributor

brson commented Apr 17, 2012

The way crates are resolved now is by searching all known library paths for libraries with matching metadata. If there is exactly one match then it is used. If there are multiple matches then it's an error. This creates occasional situations where there are (for good reason) multiple crates in different directories with the exact same name, causing compilation to fail.

The most obvious example is when somebody installs the same crate to ./.cargo and to ~/.cargo, making it unusable. One possible scheme is to break the paths up into 'priority groups' and if there are multiple matches with the exact same metadata then the higher priority one wins. If there are muliple matches with different metadata then, even if they are different priorities, it's still an error.

Priority groups from lowest to highest:

  • sysroot target libs - where core/std, rustc, etc live
  • sysroot cargo libs - if such a thing exists
  • user cargo libs - in ~/.cargo
  • local cargo libs - in ./.cargo
  • all user provided search paths

Most of these groups consist of a single path, except for 'all user provided search paths', i.e. the -L flag. If a user explicitly says where to look for crates then there really shouldn't be dupes.
@catamorphism
Copy link
Contributor

I think #5682 supersedes this.

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
@bors
Auto merge of rust-lang#2228 - cbeuw:futex-fix, r=RalfJung
c4dd3f4 
Prevent futex_wait from actually waiting if a concurrent waker was executed before us

Fixes rust-lang#2223

Two SC fences were placed in `futex_wake` (after the caller has changed `addr`), and in `futex_wait` (before we read `addr`). This guarantees that `futex_wait` sees the value written to `addr` before the last `futex_wake` call, should one exists, and avoid going into sleep with no one else to wake us up.
https://github.com/rust-lang/miri/blob/ada7b72a879d79aaa06f0a2a95edd520615da1a2/src/concurrency/weak_memory.rs#L324-L326

Earlier I proposed to use `fetch_add(0)` to read the latest value in MO, though this isn't the proper way to do it and breaks aliasing: syscall caller may pass in a `*const` from a `&` and Miri complains about write to a `SharedReadOnly` location, causing this test to fail.
https://github.com/rust-lang/miri/blob/ada7b72a879d79aaa06f0a2a95edd520615da1a2/tests/pass/concurrency/linux-futex.rs#L56-L68
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@brson @catamorphism