Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Binary sizes on the latest nightlies are significantly larger than on stable and some previous nightly versions. This is caused by some extra sections in the binary and also an increase in the text and data sections Stable (1.62.0): Nightly (1.64.0-nightly ): I tried this code: I expected to see this happen: small binary size (143 360 bytes on 1.62.0) Instead, this happened: extremely large binary size (3 517 952 bytes) <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.64.0 (nightly) <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-nightly -regression-untriaged --
This seems to be due to , cc
How was this built? (i.e. without ) would enable debuginfo, but plain wouldn't. My best guess (and why I'm asking the above) is that you already have a next to the , but caused you to also have DWARF debuginfo in the (and that part is the regression). EDIT: turns out it's the standard library, I forgot we compile it w/ debuginfo until
This was built with , although the same thing happens with
Just checked, this regressed between and
That's pretty worrying, because , and the plausible bug that introduced is that would always be set when debuginfo is enabled (i.e. it's exactly as unconditional as ). <hr/Took a look through the PRs that landed in the latter, and aside from , only could possibly affect output binaries at this level (but I fail to see how it can have any effect for windows). The only other thing I can think of to try would be - you should be able to pass to it, and then guide it based on how the resulting binary looks like.
I already ran cargo-bisect-rustc, that's how I came to the conclusion in that it was . Sorry if that wasn't clear.
My bad - also, I was probably wasting everyone's time by not trying to borrow someone else's windows laptop. So what's really going on is that even at we link debuginfo from the standard library - I bet that's why there's a at all in the first place! (which should've clued me in) So yeah, it's via // being always compiled with debuginfo and statically linked into every binary (and does seem to avoid this, as one might expect).
WG-prioritization assigning priority (). label -I-prioritize +P-medium +I-heavy
Regarding prioritization: This kills the Clippy Windows CI, because it is running out of disk space: It increases the size of from 17MB to 1GB: I don't think Clippy is/will be the only project affected by this.
Btw as per a quick fix would be to make the (unconditional after ) call for be conditional on (basically the opposite of the one). This should be perfectly backwards compatible as all MSVC targets had in their target spec, for the DWARF version, before (so they never got the LLVM set). If someone can make a PR and test it on windows, I'll r+ p=10 it just to get it out sooner.
edit2: Sorry for the useless ping, that was indeed it. But maybe it could be useful anyways: for the debugging initiative, it could be interesting to have tests that would have caught this regression. (edit1: maybe I did something silly in this test above in that maybe debuginfo-std-level is not the same as a nightly)
Since you're doing a local build, that will be highly impacted by AFAICT. Okay yeah looks like dist builds always set .
Indeed, forcing this setting as mentions, and doing the same build as instead of a debug build, it's looking good now. I'll open a PR.
cc Before this is concluded, I wanted to bring up that we could've likely avoided this bug if we had "debuginfo tests" (in the sense of introspecting the debuginfo generated, without involved a debugger) and they were always looking for both: DWARF (either embedded or split), via CodeView in PDBs, 's // subcommands speaking of which, we should ship with CI LLVM and/or the component, I only happen to have it in a local LLVM build (The only test that even uses seems to be , and it only checks that certain strings are contained and others aren't, in a very coarse way) Because what would've then happened in is any CodeView-only test would start also having DWARF being found by , and fail because no DWARF was expected. <hr/One complication though, and you might already have guessed it by the section names in the original issue description, but just tried to use on the s w/ DWARF sections and couldn't get anything out of it other than  (which presumably just looks for anything starting with ). We believe PE is : However, I don't believe we would ever actually rely on dumping debuginfo from a final executable (on any platform), because that statically links so unless we can rely on to bypass that, the amount of debuginfo would be too big to reasonably handle in a test. Thankfully, was able to confirm that on the MSVC nightly's does show the DWARF data that shouldn't be there (and ), so the (much likelier) approach of testing s (or even individual s?) would've detected this.
Out of curiosity, I also checked the MinGW target () which does use DWARF: <details<summary(click to expand <codellvm-dwarfdump</codeoutput for <code-windows-gnu</code</code/<coderustc_driver-.dll</code)</summary</detailsSo they have untrucated section names - a quick check in a hex viewer confirms that it is the COFF format described in the docs ( + an ASCII decimal encoding of a string table offset): ! The docs also said that it's not* meant for (PE) "images" (/), and MSVC does truncate section names, but maybe most tools that don't need to know about those sections will just see the weird name that starts with and simply assume that it's the actual name, and nothing will break?
thanks for the ping I have re-read this issue and you're right, this is much more impacting than I (mistakenly) understood. Even if the issue should be now solved I'll bump up the prioritization for historical records to to signal that it must have not progressed in the release cycle. label P-critical -P-medium

Discussion:
unsafe { llvm::LLVMRustDIBuilderFinalize(self.builder); <del> // Debuginfo generation in LLVM by default uses a higher // version of dwarf than macOS currently understands. We can // instruct LLVM to emit an older version of dwarf, however, // for macOS to understand. For more info see #11352 // This can be overridden using --llvm-opts -dwarf-version,N. // Android has the same issue (#22398) let dwarf_version = sess.opts.unstable_opts.dwarf_version.unwrap_or(sess.target.default_dwarf_version); llvm::LLVMRustAddModuleFlag( self.llmod, llvm::LLVMModFlagBehavior::Warning, "Dwarf Version0".as_ptr().cast(), dwarf_version, ); // Indicate that we want CodeView debug information on MSVC if sess.target.is_like_msvc { </del> <ins> if !sess.target.is_like_msvc { // Debuginfo generation in LLVM by default uses a higher // version of dwarf than macOS currently understands. We can // instruct LLVM to emit an older version of dwarf, however, // for macOS to understand. For more info see #11352 // This can be overridden using --llvm-opts -dwarf-version,N. // Android has the same issue (#22398) let dwarf_version = sess .opts .unstable_opts .dwarf_version .unwrap_or(sess.target.default_dwarf_version); llvm::LLVMRustAddModuleFlag( self.llmod, llvm::LLVMModFlagBehavior::Warning, "Dwarf Version0".as_ptr().cast(), dwarf_version, ); } else { // Indicate that we want CodeView debug information on MSVC </ins> llvm::LLVMRustAddModuleFlag( self.llmod, llvm::LLVMModFlagBehavior::Warning,