Take the original extra-filename passed to a crate into account when resolving it as a dependency #49253
Conversation
|
Hi @alexcrichton, it looks like I haven't triggered the bot that usually assigns reviewers on PRs, have I missed a step here? Thanks! |
|
Thanks for the PR! I think though we may want a slightly relaxed logic here as well in terms of this PR as-is is technically a breaking change unfortunately. Today we allow renaming the library (aka changing the final hash) and the compiler will continue to look it up and find it. Could we perhaps default to preferring exact matches, but if none are found fall back to the original logic of no hash present? Additionally, could tests be added for this pr? |
shepmaster
changed the title
shepmaster
added
the
S-waiting-on-author
chmanchester
force-pushed
the
probing_fix
branch
from
2b786fa
to
1d302b4
Compare
|
Thank you for the feedback @alexcrichton. I've made the requested change and added a test for the behavior described that we should preserve so this isn't a breaking change. Do you have any tips for how we might implement a more general test for the issue? I'm sort of at a loss for how to detect which crates' metadata is read during a test, but I'm not very familiar with the various test types in rustc. |
|
Sure yeah! I think we'd want to add a |
|
☔ The latest upstream changes (presumably #49019) made this pull request unmergeable. Please resolve the merge conflicts. |
chmanchester
force-pushed
the
probing_fix
branch
from
1d302b4
to
34d7b1c
Compare
|
Unfortunately the locator is only emitting the duplicate libs error in the case it finds otherwise matching libraries with distinct hashes, which only happens if the svh isn't included in the search (if it is, either the hash matches and it just picks one, or the hash doesn't match and the candidate is rejected). Transitive dependencies always include the svh in their search, and are the only ones we have the extra-filename for, so I'm having trouble figuring out how to make this fail... |
chmanchester
force-pushed
the
probing_fix
branch
2 times, most recently
from
342f9f1
to
2e6b3b2
Compare
resolving it as a dependency. Fixes rust-lang#46816
chmanchester
force-pushed
the
probing_fix
branch
from
2e6b3b2
to
bd81547
Compare
|
|
||
| all: | ||
| $(RUSTC) -C extra-filename=-hash foo.rs | ||
| $(RUSTC) bar.rs |
There was a problem hiding this comment.
If you pass --crate-name foo here, does that make the test fail on today's compiler?
There was a problem hiding this comment.
It does, but because it's identical to one of its dependencies (same crate name and metadata), which is also a failure with this patch.
There was a problem hiding this comment.
Could a different metadata be passed to bar.rs here so that error path wouldn't get hit?
There was a problem hiding this comment.
Yeah, but then we fail because baz.rs can't tell which version of foo to use, which is still an issue with this patch because we don't yet have an extra-filename for foo, because we're searching for it as a direct dependency of baz. This seemed plausible:
$(RUSTC) -C extra-filename=-hash foo.rs
$(RUSTC) --crate-name foo -C metadata=baz -C extra-filename=-another-hash bar.rs
$(RUSTC) --extern foo=$(TMPDIR)/libfoo-another-hash.rlib baz.rs
$(RUSTC) qux.rs
where qux depends on baz, but even then locator.rs doesn't produce an error because it can differentiate between foo crates by the SVH it finds in the metadata for deps of baz, and doesn't consider the foo found in foo.rs when resolving dependencies for baz.rs.
After trying this and a few more things I'm sort of convinced we're not going to get further in this direction, because whenever extra_filename is present in the locate context, hash will be too, and in this case locator.rs doesn't produce the kind of errors we're trying to induce.
Should we consider landing this without the test?
There was a problem hiding this comment.
Ah I think you're right, that makes sense to me and means that it may be quite hard to add a test. In that case I think it's fine, do you want to remove this one as it's not testing what we thought it was testing?
There was a problem hiding this comment.
This test may still be interesting, because it's a case that fails with an earlier version of this patch (which didn't fall back to an imprecise match if the match considering extra-filename failed), but I'd be ok with leaving it out for now as well. Thanks!
There was a problem hiding this comment.
Oh ok! If it catches a previous mistake sounds good to leave in
|
@bors: r+ |
|
📌 Commit bd81547 has been approved by |
bors
added
S-waiting-on-bors
…chton Take the original extra-filename passed to a crate into account when resolving it as a dependency resolving it as a dependency. Fixes rust-lang#46816
…chton Take the original extra-filename passed to a crate into account when resolving it as a dependency resolving it as a dependency. Fixes rust-lang#46816
Rollup of 9 pull requests Successful merges: - #48658 (Add a generic CAS loop to std::sync::Atomic*) - #49253 (Take the original extra-filename passed to a crate into account when resolving it as a dependency) - #49345 (RFC 2008: Finishing Touches) - #49432 (Flush executables to disk after linkage) - #49496 (Add more vec![... ; n] optimizations) - #49563 (add a dist builder to build rust-std components for the THUMB targets) - #49654 (Host compiler documentation: Include private items) - #49667 (Add more features to rust_2018_preview) - #49674 (ci: Remove x86_64-gnu-incremental builder) Failed merges:
resolving it as a dependency.
Fixes #46816