Renaming kebab-case cdylib target to kebab_case in metadata breaks cargo subcommands

[workingjubilee]

Problem

Hi!

Previously for targets (possibly just cdylib targets?), cargo would emit an artifact.target.name that matched the name of the package! Now it uses the underscored name. This broke cargo-pgrx on beta, and it appears that it or a related change has broken at least one other cargo tool. I believe the breaking change is in the range of 7bb7b53...54d8815 since it appears on beta but not stable, for me.

I discovered this while hunting another bug or I would have figured it out much faster. As-is, it took me a while to narrow down this problem from amidst my other issues. If I can I will try to fix my other problems and bisect this to a specific cargo commit but I have a lot going on right now so! Though, maybe I will get lucky and this will somehow be the same issue?

It would be nice if this was publicized much more loudly but it doesn't seem to be in the CHANGELOG at that point in time. It might also be nice if I had other ways of finding the mapping of target -> output .so, .dylib, or .dll name than rummaging through the compiler's output messages or randomly picking over the output directory! I don't think I've ever seen documentation promising a particular output format...

If it's relevant, just to make things more confusing, this is a library that is both an rlib and cdylib!

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

$ cargo --version --verbose
cargo 1.78.0-beta.4 (54d8815d0 2024-03-26)
release: 1.78.0-beta.4
commit-hash: 54d8815d04fa3816edc207bbc4dd36bf18014dbc
commit-date: 2024-03-26
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Arch Linux Rolling Release [64-bit]

[epage]

See also

• https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/cargo.20metadata.20change.20in.20targets.2Ename.20field
• cargo: prevent dashes in lib.name #12783

[weihanglo]

Isn't #12783 only available on nightly?

[epage]

Correct, so something else must be going on.

@workingjubilee could you add reproduction steps?

[weihanglo]

By just looking at linked issues in #12783, some folks are certainly bitten by cargo metadata output change 😞.

[workingjubilee]

Unfortunately the "reproduction steps" seem to involve the enormity of the pgrx framework. I spent a bit on trying to rebuild a minimal version from scratch, and I seem to be unable to find a minimal reproducer that demonstrates that it happens on beta first, despite it most definitely happening anytime I have set rustup default beta! It's very weird. Unfortunately this has already consumed a large amount of time I should have been spending on hunting down a rustc bug that breaks my crate, so it will be a while before I can show you anything you can actually reason about.

I will however resume bisecting across rustc commits, and while I go at it, I can try to see if I can find the exact update to rustc where the breaks start happening for cargo-pgrx. Maybe then I will get some insight into extracting a reproducer.

[workingjubilee]

Oh, I can add this much: Part of the reason I tried to go directly for a minimal reproducer instead of cutting things down in a more binary-search style is that by the time cargo build is run in this context, we have

• started running cargo test
• started executing test code
• that then calls back into cargo pgrx
• that then finally calls cargo build

...maybe there's an environment variable cargo previously set that is leading to this result. 🤔