jiebi/CodeConvo huggingface dataset:
<!-- 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.
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.
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.
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)
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
<!-- 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 .
We have some relative links in doc, e.g., the link of in the comments for : but we will get the page if we click it in , which is re-exported. So I think we can fix this by two ways: 't use relative path in rustc doc 't generate new link for re-exported items, use the same links with the original definition but for the second option, we may have private middle mods, so it may be not a solution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
I'm thinking of tackling this issue, is this Issue aimed at removing this invalid path once and for all? (Sorry if I'm wrong as I'm trying to contribute for the first time)
claim
Hi just checking if you are still working on the issue? If so, apologies please ignore this. Otherwise I'm happy to take over. Thanks
take it
Given the following code: The current output is: I think it's typical for a newcomer to want to get a iterator by chaining method calls like . There's no obvious reason why that shouldn't work. The examples in the documentation do typically show being assigned to a variable prior to calling its method, but don't explain why that's necessary. I think the "borrow" terminology is misleading, but there might not be a concise way to describe what's actually going on to the user. The "temporary value is freed at the end of this statement" is probably correct. The "creates a temporary which is freed while still in use" is probably more correctly "creates a temporary that is required to outlive (or live exactly as long as) the result of...", followed by a pointer to the method invocation, with text of " method call". Maybe it should also point out the lifetime argument in the return type. I tried and failed to find a satisfactory explanation of what exactly was borrowing from the temporary value produced by . When I looked through the library source code, the only references in were those created by locking a , and the in question is static. I'm guessing the existence of a borrow is assumed rather than inferred from analyzing the function body of . The assumption might be the result of the anonymous lifetime argument on the output type from , which imposes a requirement that the doesn't outlive (or has the same lifetime as?) the value that is the receiver of . The correct fix might be to change the locked stdin handles to all use lifetimes, but I will probably file that as a separate issue.
label +A-borrow-checker +A-lifetimes +D-confusing +D-incorrect +D-newcomer-roadblock
IMO the intent is clear here. Without changing the API, why exactly is Rust unable to lift 'a &'static X to 'static & 'static X, if X also contains only 'static lifetimes? I don't think raw references have a meaningful dropper; borrowck is able to freely resolve any derived lifetimes on impls that don't depend on anything else to 'static; I'm pretty sure under current rules we should be able to substitute latter for earlier and get exactly the same behaviour.
This is due to .
is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index:
Playground: UPDATE: MCVE is here: Code: Crashes compiler with
Would be nice to figure out if this is a regression or not and if it is when has this regressed. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
It has been present since at least 2019-08-01 according to bisect-rustc
Simplified code to remove dependencies This compiles for 1.20.0 and not for 1.30.0 (setting edition to 2015) I'll try and pinpoint at least the version where it causes the ICE
From what I can tell the first time this ICE would happen is in 1.24.0
Assigning
Even simpler:
Triage: This ICE has been fixed in the latest nightly, I assume it's fixed by . Marking as .
Wait, the original code and still triggers the ICE... glacier was tracking with but it seems the others encounter another roadblock. Dropping .
No longer ICEs since , likely from
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
label +D-diagnostic-infra -needs-triage
This bug only happens when calling a method on two different referenced variables inside an async closure. For some reason, this bug will not happen if the lines are flipped (calling it on test first then temp). It also will not happen if test isn't cloned outside the closure first. This will error: This will not: Neither will: Nor will: But if both the order is flipped and the line order is flipped it will crash (variable name changed to make sure shadowing wasn't the issue): This setup for the bug was found entirely through trial and error. The original issue was found in a nightly build of a project I'm working on (). This bug was introduced in the latest version of nightly (2024-04-08). It was not present in 2024-04-07. rustc 1.79.0-nightly ( 2024-04-08) binary: rustc commit-hash: commit-date: 2024-04-08 host: x8664-pc-windows-msvc release: 1.79.0-nightly LLVM version: 18.1.3 ICE txt file:
thank you for producing these examples; they're very helpful. i will have a fix out tomorrow, sorry for the inconvenience and hope it doesn't discourage you from testing async closures more.
Wow, that was quick! Thanks, I'll make sure to report any more I come across, I plan on implementing more async closures into the project with my next big refactor because of how helpful they are.
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --No user code, just trying to compile my project. The is <!-- 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. --:
Do you mind checking if this still ICEs on the most recent nightly?
I just did that now, and it looks like the issue is fixed on the latest nightly. (sorry should have tried that in first place!)
That's weird, because I can repro it (cross-compiling for from linux if it matters).
on the latest nightly?
yep: Also the version of winit from the report () is not the latest . I'm working on bisecting and reducing now
Wait, this actually ICEs on stable too and I didn't notice because rustc emitted a bunch of errors after the ICE (?!)
I've reduced it down to this (which is no longer macOS or aarch64 dependent): (The assignment to was of course something more reasonable in the original code, but now I can't seem to replace it without making the ICE go away) This failed to compile without ICE on 1.69: Regression in () searched nightlies: from nightly-2023-03-06 to nightly-2023-04-19 regressed nightly: nightly-2023-04-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-stable
Whoops, I seemed to have caused it I'll look into it!
WG-prioritization assigning priority (). label -I-prioritize +P-medium
<!-- 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: Note that is not marked as internal I expected to see this happen: code compiles Instead, this happened: ` Maybe the lint should ignore code from expansions? <!-- 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. --:
On , the expansion of with contains a call to : is tagged with , but not .
Tracking issue: . The assembler directive allows to treat data as instructions. This allows to generate CPU instructions that are otherwise not possible using assembler commands. It is platform specific and mostly relevant for RISC-V platforms, but I could also find uses for it on MIPS targets as well. More generally speaking, any solution that allows me to produce custom machine code instructions without a performance overhead will be okay for me. The current best workaround is to write the assembler code externally and then link to it. However, this adds the overhead of a function call that cannot be inlined due to the FFI boundary, so this is not acceptable in the long term. See also for some more discussion of my problem.
This will likely work automatically once LLVM supports it. A commit has recently landed () but is not yet in any released version.
label +A-inline-assembly +F-asm
I tried building rust+cargo from source with cherry-picked. Sadly it did not make the error message go away. A good way to check is to use on a minimal example instead. Turns out that I somehow wasn't.
Okay, it actually does work. What is the procedure around Rust's LLVM dependency? How often is it bumped? Is this a candidate for cherry-picking onto rust-llvm?
LLVM procedure is at https://rustc-dev- I think this is a candidate for cherry-picking but someone needs to do the work.
Test Case 1: Test Case 2: Both produce errors like this: CC
Hm, so the first case here should work (e.g. should subvert basically everything), although the second case is correct in yielding an error (albeit not a very good one)
Is the second case not allowed then? 's documentation suggests that manually implementing it is okay to do: I figured only existed to wrap types which you couldn't yourself, but for which you can ensure their invariants are upheld across the boundary. And what about moving values into the closure? can't be unwrapped, at least not currently.
Oh wait sorry I misread your second example, I failed to notice the manual ! This is basically a case where closure captures are coming into play. The closures aren't annotated with , so outer variables are captured by-reference which means that the actual types being tested against the trait here are and . In the first case that should be handled by , but the second is legitimately indicating that it's not a recover-safe type (b/c the reference is different than the by-value). You should be able to get around this via either plus or via . Certainly an interesting interaction going on here though. One would likely expect that if isn't recover safe that would fix the problem but it's likely what you really need to do is due to the way closures largely work.
There's , why not ? Coherence?
Nah unfortunately that'd defeat the purpose of the distinction. The type is itself recover safe, it's just that's not (so the distinction need to be there)
It's unfortunate that fails due to coherence or something like that:
Hm interesting, I guess yeah you'll be forced to move the reference inside the wrapper rather than having a reference to the wrapper
Is it possible to implement then? My use case can contain and friends but I'm guaranteeing that they're unobservable in user code after recovery because I immediately re-panic after escaping the FFI stack.
I guess I can just use once it's fixed :stuckouttongue:. I see your PR has been accepted so I'll look forward to trying it on tonight's nightly. When do the buildbots fire?
Yeah currently you can implement (being renamed to ) I believe (although I can't say I've tried). For now though yeah I'd recommend just using plus closures.
The PR is in but'll take a few hours at least to land.
the problem with moving at this point in time is that I call in different branches of a but I pass the same closed-over value to it; I can't do the branch in the closure because I need to do some FFI cleanup afterwards regardless of whether a panic happened or not (which also requires the closed-over value). It would help if derived and/or so I could reuse it without constructing a new value for each arm, but that would probably require some discussion because I don't know if it's safe or not. I'll probably just implement and fix the name after your PR drops. A quick check confirms that it works just fine. Thanks anyways!
Oh yeah we could totally add more traits like and to , there shouldn't be any safety concerns there.
Updating code to modern functions and traits in makes this compile, so I'm going to close.