Consider prioritising crate search directories #2223
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
|
I think #5682 supersedes this. |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 22, 2022
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
BoxyUwU
pushed a commit
to BoxyUwU/rust
that referenced
this issue
Jan 29, 2025
CI: use key-restore for cache GH action
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
./.cargoand 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:
~/.cargo./.cargoMost of these groups consist of a single path, except for 'all user provided search paths', i.e. the
-Lflag. If a user explicitly says where to look for crates then there really shouldn't be dupes.The text was updated successfully, but these errors were encountered: