Change:
drop(handlers); } <ins> // `.dwo` files are only emitted if: // // - Object files are being emitted (i.e. bitcode only or metadata only compilations will not //   produce dwarf objects, even if otherwise enabled) // - Target supports Split DWARF // - Split debuginfo is enabled // - Split DWARF kind is `split` (i.e. debuginfo is split into `.dwo` files, not different //   sections in the `.o` files). let dwarf_object_emitted = matches!(config.emit_obj, EmitObj::ObjectCode(_)) && cgcx.target_can_use_split_dwarf && cgcx.split_debuginfo != SplitDebuginfo::Off && cgcx.split_dwarf_kind == SplitDwarfKind::Split; </ins> Ok(module.into_compiled_module( config.emit_obj != EmitObj::None, <del> cgcx.target_can_use_split_dwarf && cgcx.split_debuginfo != SplitDebuginfo::Off && cgcx.split_dwarf_kind == SplitDwarfKind::Split, </del> <ins> dwarf_object_emitted, </ins> config.emit_bc, &cgcx.output_filenames, ))

Discussion:
When I add to my in (on Linux), my build fails with: In debug I initially had the same problem but a fixed it without requiring me to turn off . However, release continues to be failing even after . rustc --version rustc 1.65.0 ( 2022-11-02) cargo --version cargo 1.65.0 ( 2022-10-20)
It's silent in my macOS in release profile, but no dSYM generated. It's OK in dev profile.
Oh not sure if it matters, but I also have debug = true set for my release build.
Thanks for your reminder. I forgot that is off by default in release profile.
Can confirm this happens for me as well but with .
Can you provide some more information, such as the target you are building for (?), the output of , and anything else that might help narrow down the issue? Is your profile exactly this?
I got this same error when I tried compiling with both split debug info and linker plugin LTO.
also need LTO enabled, works fine without here
Thanks for clarifying. Yeah, I do have LTO on as well.
cc or in case this didn't hit your radar. The reproduction is: with the error: From what I can tell, the archiver is expecting a file to exist ( around ). AFAIK, that doesn't make sense with a bitcode-only output. The decision of whether or not a dwo is expected I think is made around . I'm guessing that decision (or perhaps something at a higher level) needs to be aware that the split-dwarf won't happen with bitcode-only output? (IOW, that case should only be true if was called with a value with ?)
Should this issue be marked as a stable-to-stable regression?
Submitted to fix this.
Thanks for the ping and the great pre-investigation,
I am encountering this on without LTO. (Or at least I'm not explicitly enabling LTO, and I don't have LTO enabled in ). Builds in local projects work fine, only is affected. Adding the following to triggers it: Should I open a new issue, or do you want to track this together with the LTO case?
Can you put together a reproduction?

Also, it might help to post the output of with your command (along with the exact command you are running).
Here are the outputs of : <details<summarySuccessful run</summary</details<details<summaryFailed run</summary</detailsI imagine simply running Ubuntu 20.04 and adding this to should do the trick: But I'll verify it and let you know.
Yes, I've verified that this is reproducible on a clean Ubuntu 20.04 installation or live CD. Other than the commands above you need to and install Rust through
Oh, I see that the failed run does contain the flag. So it is the same issue. I'm confused why implicitly enables it by default while other invocations don't, but that's a separate issue.
rustfilt sets LTO . I don't know what other commands you are running, but if it is , then that would use the dev profile without LTO.
Up on message: