jiebi/CodeConvo huggingface dataset:
Code change:
<del> use crate::spec::{LinkerFlavor, PanicStrategy, Target, TargetResult}; </del> <ins> use crate::spec::{LinkerFlavor, Target, TargetResult}; </ins> pub fn target() -> TargetResult { let mut base = super::windows_msvc_base::opts();

Related discussion:
text: The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.
Code change:
//~^ ERROR doesn't implement } <del> pub fn main() { } </del> <ins> trait Foo<T> { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Bar: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Baz where Self: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Qux<T> where Self: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } trait Bat<T>: std::fmt::Display { const SIZE: usize = core::mem::size_of::<Self>(); //~^ ERROR the size for values of type `Self` cannot be known at compilation time } fn main() { } </ins>

Related discussion:
text: The following code errors, and the error contains a suggestion how to fix the error: The error message states: Obviously, writing is invalid syntax.
It seems the issue is that it's inserting the suggestion after the trait name and before the generics, rather than after the generics.
No-nightly-features code that exhibits the same problem: label -requires-nightly (should the F-labels go as well?)
Code change:
AscribeUserTy, /// The data of a user variable, for debug info. VarDebugInfo, <del> /// PlaceMention statement. PlaceMention, </del> } #[derive(Copy, Clone, Debug, PartialEq, Eq)]

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy
Code change:
let node_id = scope.node_id(self.tcx, &self.region_scope_tree); match self.tcx.hir.find(node_id) { Some(hir_map::NodeStmt(_)) => { <del> db.note("consider using a `let` binding to increase its lifetime"); </del> <ins> if *sub_scope != ty::ReStatic { db.note("consider using a `let` binding to increase its lifetime"); } </ins> } _ => {} }

Related discussion:
text: suggests but still won't give us a lifetime. We should not emit the if the required lifetime is for the inside the source presume there's some code already checking for producing the "borrowed value must be valid for the static lifetime" message, find that code and bubble up the knowledge about that until you have it in the scope of the "consider using a binding to increase its lifetime" message 't emit the message in that case 'll already fail a bunch of tests, I don't think you need any new tests. Running should succeed and give you a bunch of changes to commit. Check that all changes make sense and just commit them.
can I take this on if nobody is working on this?
All yours!
closing it, as required code change has been merged.
Code change:
<ins> error[E0596]: cannot borrow immutable `Box` content `*x` as mutable --> $DIR/issue-36400.rs:15:12 | 14 |     let x = Box::new(3); |         - consider changing this to `mut x` 15 |     f(&mut *x); |            ^^ cannot borrow as mutable error: aborting due to previous error </ins>

Related discussion:
text: This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.
Code change:
<ins> error[E0596]: cannot borrow immutable `Box` content `*x` as mutable --> $DIR/issue-36400.rs:15:12 | 14 |     let x = Box::new(3); |         - consider changing this to `mut x` 15 |     f(&mut *x); |            ^^ cannot borrow as mutable error: aborting due to previous error </ins>

Related discussion:
text: Before , this caused an LLVM error Afterwards, this causes an ICE (the rustc size is the correct one):
I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.
Looks like called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.
Appears to be fixed today. E-needstest.
It seems that a better diagnostic output is needed:
Why? I believe it's implemented as a feature now (maybe it should be ?).
it's unrelated to this issue, but rather to 's solution, merits at least a clarifying label pointing at the , as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the . I know it definitely confused me_ :) Back to this issue, yes, the test in should be .
Code change:
<ins> error[E0596]: cannot borrow immutable `Box` content `*x` as mutable --> $DIR/issue-36400.rs:15:12 | 14 |     let x = Box::new(3); |         - consider changing this to `mut x` 15 |     f(&mut *x); |            ^^ cannot borrow as mutable error: aborting due to previous error </ins>

Related discussion:
text: Triage: this no longer ICEs. <details<summaryMeta</summary: rustc 1.16.0 ( 2017-03-10) binary: rustc commit-hash: commit-date: 2017-03-10 host: x86_64-pc-windows-gnu release: 1.16.0 LLVM version: 3.9 </details
Code change:
[[package]] name = "ar_archive_writer" <del> version = "0.4.0" </del> <ins> version = "0.4.2" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "de11a9d32db3327f981143bdf699ade4d637c6887b13b97e6e91a9154666963c" </del> <ins> checksum = "01667f6f40216b9a0b2945e05fed5f1ad0ab6470e69cb9378001e37b1c0668e4" </ins> dependencies = [ "object 0.36.2", ]

Related discussion:
text: <!-- 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. --I tried to build using a simple then . I expected to see this happen: linking success. Instead, this happened: MSVC link returns LNK2005 and fails to the static library. It most recently worked on: 1.77.2 <!-- Provide the version you are using that has the regression. --: This is caused by both and When creating stdlibs, each MR causes the Rust compiler to add an export of ; one comes from api-ms-win-core-synch-l1-2-0.dll and the other from This error will not be found until one consumes the Rust-generated library. I am filing this report to consolidate the ones in and <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged
cc
Using for a rust staticlib seems weird to me but cc
The purpose is to allow reexporting a subset of symbols on MSVC. This can be achieved with partial linking elsewhere, but this is not doable on Windows. I wrote about a specific application here:
Sorry, I'm confused, are you trying to create a dynamic or static library? The article that you linked to talks about static libraries, but the backtrace in the OP shows that you are creating a dynamic library.
Both: I'm using the Rust-produced static library through , plus a module definition file, to create a dynamic library. This is because (apart from size considerations) GNOME's gobject-introspection needs a shared library, and Meson will only accept targets that are generated by itself. Further context is here:
In this particular case, because of the imports present in the stdlib, linking something against the Rust-produced static librsvg is enough to trigger the issue.
I am still struggling to understand why is needed, at least for MSVC.
Code change:
[[package]] name = "ar_archive_writer" <del> version = "0.4.0" </del> <ins> version = "0.4.2" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "de11a9d32db3327f981143bdf699ade4d637c6887b13b97e6e91a9154666963c" </del> <ins> checksum = "01667f6f40216b9a0b2945e05fed5f1ad0ab6470e69cb9378001e37b1c0668e4" </ins> dependencies = [ "object 0.36.2", ]

Related discussion:
text: So the DLL is created here: is used so that the DLL includes every single object in the staticlib, even if it's unneeded or indeed causes conflicts. But then is used to add a which presumably defines what actually gets exported from the DLL. What I'm not understanding is what would be different if, for MSVC, it just linked normally without ? I.e. using instead.
On MSVC, static linking doesn't let you reexport dependencies' symbols automatically, they're subject to DCE. . However, PE-COFF static libraries don't support symbol visibility, so the is there to make all Rust symbols private and keep only the librsvg ones. See e.g. and for consequences of not blocking out symbols like .
Sure but the should work regardless of if is used or not because using the export will force the linker to go looking for the symbol(s) listed in the file. E.g. as a test I have the following static lib (using to make symbols easier to find): Which I compile into a static lib using: rustc -O --crate-type=staticlib And I have the following file: Which for simplicity I compile via rustc but I'm using an empty file and also raw linker arguments: rustc -O --crate-type=cdylib -C link-args=" " This compiles and if I see the two functions I wanted: No std symbols are exported.
Independent of whether whole-archive is necessary for this specific use case, we should support linking rust staticlibs with whole-archive, even if because of the fact that not linking with whole-archive can mask linker errors, which will later show up when any change to the cgu partitioning is made, which often causes people to report a regression even though their crate is at fault.
If I repeat the above using even in this simple case I get a bunch of errors, not just : I'm not really sure if rustc can currently guarantee that whole archive will work without doing some of the work of a linker. Which sounds like a new feature and not specific to MSVC.
All duplicate symbol errors for are caused by That it works without is by accident and likely to break in case of cgu partitioning changes.
Code change:
[[package]] name = "ar_archive_writer" <del> version = "0.4.0" </del> <ins> version = "0.4.2" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "de11a9d32db3327f981143bdf699ade4d637c6887b13b97e6e91a9154666963c" </del> <ins> checksum = "01667f6f40216b9a0b2945e05fed5f1ad0ab6470e69cb9378001e37b1c0668e4" </ins> dependencies = [ "object 0.36.2", ]

Related discussion:
text: Sure, and then if I compile the static library with and use whole archive then I get a whole slew of errors, which I'll spoiler for length <details<summarylinker errors</summary</details
There are also some technical details in that kleisauke linked. windows-gnu is unaffected because it uses legacy import libraries format.
To get back to address case we could either: Filter symbols when building a staticlib Try using COMDAT in generated raw-dylibs (might not work in this situation)
Filter in what way?
When linking raw dylibs into a staticlib we could exclude the objects containing . Except for one.
Code change:
if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(

Related discussion:
text: The following sample crashed rustc: Removing the , or unwrapping the (leaving only ), or replacing the predicate (leaving ), solves the crash. Reproduced on Windows 64-bit, Fedora 32-bit, Ubuntu 64-bit. Full crash log (thanks to ) @ Short crash message:
Fixed pending
Fixed in
Code change:
if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(

Related discussion:
text: While I was playing with the new rustc 0.6, I encountered an internal compiler error The source code is here: Compiler version is 0.6, built with gcc, on OS X 10.7.5
If you run rustc under gdb and break on , could you paste the backtrace here?
OK. Here is the backtrace:
Looks like stack exhaustion to me. What happens if you remove ?
The code compiles with no problem when I wrap the rest of the code with mod block. Like:
This yields a proper error message now; closing.
Code change:
if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(

Related discussion:
text: When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.
Code change:
if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(

Related discussion:
text: As seen in , LLVM has lots of places where it will insert calls to libm directly, not switching stacks. One of places that I recall seeing this before is the translation of the instruction. Rust has floating point modulus and presumably it is doing it in the red zone.
We can solve this with an lang item.
Is this an issue with calls to compiler-rt too? Or are they compiled in some special way to avoid the issue?
Nominating for milestone 5, production-ready
, , and are also all generated. As far as I can tell, we can't prevent it from generating these by altering the IR we output.
We can possibly be selective about when we emit memcpy/memmov, second guessing LLVM (like, never for big things)
accepted for production-ready milestone
Closing due to segmented stacks being gone (stack switches no longer a thing)
Code change:
fBopt-levelfR=fIVALfR Optimize with possible levels 0[en]3 <ins> .SH ENVIRONMENT VARIABLES Some of these affect the output of the compiler, while others affect programs which link to the standard library. .TP fBRUST_TEST_THREADSfR The test framework Rust provides executes tests in parallel. This variable sets the maximum number of threads used for this purpose. .TP fBRUST_TEST_NOCAPTUREfR A synonym for the --nocapture flag. .TP fBRUST_MIN_STACKfR Sets the minimum stack size for new threads. .TP fBRUST_BACKTRACEfR If set, produces a backtrace in the output of a program which panics. </ins> .SH "EXAMPLES" To build an executable from a source file with a main function: $ rustc -o hello hello.rs

Related discussion:
text: I was looking for a collection of environment variables that honours but was unable to find a definitive list. There are a few mentions of variables such as , and on google but none of them are documented in Would it be possible to add these to the manual for future reference under an section much like and ?
Yup, that'd be great.
Lots of these are duplicates, but
This looks like an actual list of all of them right now:
FYI: Just (Document RUSTTESTTASKS in the "book") in response to spurious test failures due to parallel text execution.
Full list as of now:
(I gusess some of these are not actually env vars)
Code change:
self.tcx.struct_span_lint_hir( lint::builtin::RUST_2021_INCOMPATIBLE_CLOSURE_CAPTURES, closure_hir_id, <del> closure_head_span, </del> <ins> closure_head_span, </ins> |lint| { let mut diagnostics_builder = lint.build( format!(

Related discussion:
text: I tried this code: This does not issue a warning for , however it fails to compile with enabled: I would expect to give a suggestion to add . Found in the 2021 crater run for: I'm uncertain if this is a duplicate of or , they seem very similar, but this case is specific to implementing Drop. : cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Code change:
<del> Subproject commit 5399a24c66cb6164cf32280e7d300488c90d5765 </del> <ins> Subproject commit b31c30a9bb4dbbd13c359d0e2bea7f65d20adf3f </ins>

Related discussion:
text: I get a segfault when I try to run on the following code: I see the same behavior with the latest nightly . I see no error with 1.77.0 or earlier. It also works fine on Linux, and on an older Intel Macbook. I also updated to the latest XCode to make sure all parts of my toolchain were up to date. Doing so did not make the segfault go away.
The problem disappears if I turn off incremental compilation by adding this to the :
I believe this bisects to LLVM 18 from cc
We are hitting an LLVM assertion:
Could someone please run and then repeat the rustc command with and share the bitcode files?
I can reproduce it, and I will try to reduce it.
Upstream issue: Reduced:
It has already been backported to LLVM 18: label +llvm-fixed-upstream
Code change:
<del> Subproject commit 5399a24c66cb6164cf32280e7d300488c90d5765 </del> <ins> Subproject commit b31c30a9bb4dbbd13c359d0e2bea7f65d20adf3f </ins>

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This bug is spotted jointly by and We tried this code (minimized by and I expected to see this happen: The program should exit without error. Instead, this happened: segmentation fault. Notice that the code will pass . (). The error is reproducible with larger than . The error seems to be related, as does not reproduce the bug. There seems to be no bug in LLVM IR. noticed that produces different asm compared with the one in the ELF output. Notice that we encountered an ICE while exploring the code (for now, we are not sure whether the ICE is related to SEGV, we can file a separate report for ICE if needed). Basically, invoking the rustc consecutively, one will get (cleaning up the directory can help): <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --Both nightly and stable versions are affected :
may be running into
This started on stable in 1.73, and bisects to : A couple notes, when using cargo: incremental compilation is not enabled on release builds for people who opt into optimizing dependencies even in debug builds: incremental compilation is not enabled for dependencies either, only local crates It would be interesting to see exactly what impacts codegen here when enabling incremental compilation of a single session (but at the same time, it seems probable that not many users should encounter this issue in the more common configurations?).
Some additional context: the code is largely related to ecow. In case people compile typst/ecow related code with incremental build and level 1 optimization enabled and run into segmentation fault, this should be the bug behind it.
So the error happens just from adding , without there actually being a previous incremental cache there? Wow. Cc Seems likely that the LLVM 17 update is involved. Cc
I can confirm that this reproduces with an empty cache -- which should be good news in terms of debugging the issue. I'm pretty sure this is a ThinLTO-related bug and incremental somehow configures CGUs and LLVM settings in a way that triggers the bug. The segfault does not reproduce when compiling with .