You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, ui_test doesn't support crates that appear as both build-dependencies and core dependencies. That's a bummer as it blocks rust-lang/rust-clippy#14883 which is on the critical path to resolving rust-lang/rust#78717.
So, I wonder what could be done here. First I tried to understand what happens.
The problem
To determine the rlib files that should be added to the tests, ui_test builds the test dependency crate with --message-format=json. Then it scours the JSON we get from that for the files we care about.
This is basically the same line twice, just with two different hashes in the filename.
This happens because cargo built quote twice: once as a dependency of a proc macro, and once as a dependency of the crate itself. These days those two dependencies don't get unified any more to avoid features leaking between "host dependencies" and "target dependencies". But ui_test has no way of knowing which of these two to use, so we give up.
Is that right? There's something here I don't understand, which is the situation where a crate only appears as a host dependency. ui_test wouldn't know this and then it would make that available to the test. Doesn't that cause problems? In particular if we are cross-building where host dependencies will have been built for the wrong target?
The pipe dream solution
Cargo probably knows why it built this crate. If it could communicate that to us in the JSON, this would be trivial. "Just" tell us whether this crate was built "for the host" or "for the target". Or is there some reason that cargo doesn't have this information by the time the JSON is emitted? Cc @ehuss@weihanglo
The hacky solution?
If, instead of cargo build, we run cargo build --target x86_64-unknown-linux-gnu, we get slightly different output:
Looking at these, it is clear that the first one is the "target dependency" and the second is the "host dependency".
So maybe ui_test could use that to resolve the ambiguity? I don't know what the best algorithm here is; the easiest one is "call pop() three times and then compare the filename() with the target name; if they match, it's the target dependency". @oli-obk do you think that could work?
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Currently,
ui_testdoesn't support crates that appear as both build-dependencies and core dependencies. That's a bummer as it blocks rust-lang/rust-clippy#14883 which is on the critical path to resolving rust-lang/rust#78717.So, I wonder what could be done here. First I tried to understand what happens.
The problem
To determine the rlib files that should be added to the tests, ui_test builds the test dependency crate with
--message-format=json. Then it scours the JSON we get from that for the files we care about.The problem is that sometimes we get this:
This is basically the same line twice, just with two different hashes in the filename.
This happens because cargo built
quotetwice: once as a dependency of a proc macro, and once as a dependency of the crate itself. These days those two dependencies don't get unified any more to avoid features leaking between "host dependencies" and "target dependencies". But ui_test has no way of knowing which of these two to use, so we give up.Is that right? There's something here I don't understand, which is the situation where a crate only appears as a host dependency. ui_test wouldn't know this and then it would make that available to the test. Doesn't that cause problems? In particular if we are cross-building where host dependencies will have been built for the wrong target?
The pipe dream solution
Cargo probably knows why it built this crate. If it could communicate that to us in the JSON, this would be trivial. "Just" tell us whether this crate was built "for the host" or "for the target". Or is there some reason that cargo doesn't have this information by the time the JSON is emitted? Cc @ehuss @weihanglo
The hacky solution?
If, instead of
cargo build, we runcargo build --target x86_64-unknown-linux-gnu, we get slightly different output:Note the two different filenames:
/home/r/src/rust/clippy/target/x86_64-unknown-linux-gnu/debug/deps/libquote-d21625b54f8de8ce.rlib/home/r/src/rust/clippy/target/debug/deps/libquote-7d753679308ff16a.rlibLooking at these, it is clear that the first one is the "target dependency" and the second is the "host dependency".
So maybe ui_test could use that to resolve the ambiguity? I don't know what the best algorithm here is; the easiest one is "call
pop()three times and then compare thefilename()with the target name; if they match, it's the target dependency". @oli-obk do you think that could work?The text was updated successfully, but these errors were encountered: