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[1]: Circular libuv.a <- libuv.a dependency dropped. #11067

Closed
huonw opened this issue Dec 19, 2013 · 0 comments
Closed

make[1]: Circular libuv.a <- libuv.a dependency dropped. #11067

huonw opened this issue Dec 19, 2013 · 0 comments

Comments

@huonw
Copy link
Member

huonw commented Dec 19, 2013

On a normal invocation of make I see:

compile_and_link: x86_64-unknown-linux-gnu/stage0/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd.so
make[1]: Entering directory `/home/huon/rust/build/x86_64-unknown-linux-gnu/rt/libuv'
make[1]: Circular libuv.a <- libuv.a dependency dropped.
  COPY libuv.a
make[1]: Leaving directory `/home/huon/rust/build/x86_64-unknown-linux-gnu/rt/libuv'

The build does proceed as normal, and it all works fine.

bors added a commit that referenced this issue Dec 23, 2013
Turns out libuv's build system doesn't like us telling them that the build
directory is a relative location, as it always spits out a warning about a
circular dependency being dropped. By using an absolute path, turns out the
warnings isn't spit out, who knew?

Closes #11067
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 18, 2024
…r=Manishearth

Compare trait references in `trait_duplication_in_bounds` correctly

Fixes rust-lang#13476
Fixes rust-lang#11067
Fixes rust-lang#9915
Fixes rust-lang#9626

Currently, the `trait_duplication_in_bounds` lints has a helper type for a trait reference that can be used for comparison and hashing, represented as `{trait: Res, generic_args: Vec<Res>}`. However, there are a lot of issues with this. For one, a `Res` can't represent e.g. references, slices, or lots of other types, as well as const generics and associated type equality. In those cases, the lint simply ignores them and has no way of checking if they're actually the same.

So, instead of using `Res` for this, use `SpanlessEq` and `SpanlessHash` for comparisons with the trait path for checking if there are duplicates.

However, using `SpanlessEq` as is alone lead to a false negative in the test. `std::clone::Clone` + `foo::Clone` wasn't recognized as a duplicate, because it has different segments. So this also adds a new "mode" to SpanlessEq which compares by final resolution. (I've been wondering if this can't just be the default but it's quite a large scale change as it affects a lot of lints and I haven't yet looked at all uses of it to see if there are lints that really do care about having exactly the same path segments).

Maybe an alternative would be to turn the hir types/consts into middle types/consts and compare them instead but I'm not sure there's really a good way to do that

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant