Consider again propagating dynamic native dependencies #10743
Labels
A-linkage
Area: linking into static, shared libraries and binaries
Comments
|
It appears that @luqmana has run into this when building rustdoc as well: https://gist.github.com/luqmana/a418261dc179db131770 |
|
And again @luqmana found this building rustc: https://gist.github.com/luqmana/3eb91d9181cacf11cfbe |
bors
added a commit
that referenced
this issue
Dec 3, 2013
Commit messages have the fun details, the focus of this is closing #10743 though
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Jun 30, 2023
new lint: `explicit_into_iter_fn_arg` Closes rust-lang#10743. This adds a lint that looks for `.into_iter()` calls in a call expression to a function that already expects an `IntoIterator`. In those cases, explicitly calling `.into_iter()` is unnecessary. There were a few instances of this in clippy itself so I fixed those as well in this PR. changelog: new lint [`explicit_into_iter_fn_arg`]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In 2b9c774, we stopped propagating link arguments across crates. The main reason for this is that it was impossible to have a static library build dependency because the link arguments would always be propagated (and the library is only available during the build process).
Now that we have a proper linkage system set up (after #10528), we may want to consider re-propagating these dependencies. I have seen many failed compilations due to this not occurring (one is in issue #10543), and it seems reasonable to do this.
Because we would only do this for native dynamic dependencies, the dependency must already be in place to use the upstream crate, so why not just link it to the downstream crate?
I'm personally in favor of this (due to having a distinction between dynamic/static native libraries now), and I believe that this should be done.
Nominating for discussion.
The text was updated successfully, but these errors were encountered: