jiebi/CodeConvo huggingface dataset:
The following GitHub action fails with nightly-2024-02-27 but passes with nightly-2024-02-26 for (I believe) any project with a file: The error I got is the following: This only affects x8664-pc-windows-gnu (not MVSC), and switching from to fixes the issue. I have reproduced the issue in I may end up deleting that repo in the future, so for posterity, I've included all the code below: <details<summaryExample project to reproduce the issue:workflows (See above) src </detailsThe original discovery of this issue is reported in Running yielded the following for the latest nightly version without the issue: Running on three versions with_ the issue (the next nightly version, the latest nightly version, and the current beta) yielded the following: This issue is not present in rustc 1.77.2 (the latest stable version).
The imports should mostly be shared between msvc and gnu so the fact the targets differ is a bit puzzling. My hypothesis would be that mingw on Windows Server 2019 is using an older version of an import library that maps one or more functions to the wrong DLL. Specifically I think this could be caused by the import library. cc in case you've heard of anything like this before
I doubt it's a problem with the old MinGW-w64; in that case, the program would fail to link. I helped with a similar issue recently, and it was caused by the wrong being loaded. There are two DLLs called that, and if a manifest is not provided, Windows will load the wrong one:
Hm... I ran on both windows-2019 and windows-latest and the import tables do look different (see ). <details<summarywindows-2019</summary</details<details<summarywindows-latest</summary</detailsNote that is listed under in windows-2019 but it's more correctly listed under in windows-latest.
Yeah, that is probably the culprit but mingw-w64 links from since mid 2016: If it's caused by miingw-w64 toolchain preinstalled on image it must be terribly out of date.
Quite possibly it is that out of date. The other explanation would be it's coming from somewhere else, which Is a bit worrying.
Based on , my first impression is that mingw-w64 isn't preinstalled on the image. Unless Windows Subsystem for Linux is relevant, I assume that the mingw-w64 toolchain is installed as part of the run of .
Various tools like Perl might come with GCC. Could you determine location of and ?
I'm not sure. I've only been able to reproduce this via a GitHub action, not on my own machine, although I might be able to use something like to explore around. Alternatively, I could just run a fixed list of commands. If there's a set of commands I can run to answer any questions you have, please let me know. I'm not sure how the Rust toolchain determines which version of to run when building Rust code, but that seems like something you might know. EDIT: Based on your question, I might need to just run with the two applications you asked about. EDIT2: and are both in according to .
Here are the versions of based on running :
Thanks, apparently there was a bug in mingw-w64 fixed in 2020: IIRC this toolchain is older than that so it's indeed a bug in mingw-w64 shipped with this .
Oh, weird. also comes shipped with so this image generally has up-to-date packages. I also didn't see mingw or mingw-w64 mentioned anywhere in its README, so now I'm wondering if there's a bug in the image itself. I expect this means that no action will be needed for this particular issue unless we want to be more robust to bad environments like this. EDIT: It looks like it's defined here: EDIT2: It was documented after all. I had to search for "gcc", not "mingw".
I was rather confused because states that the latest version from the 8.x series is 8.0.2, but the version installed of in the the Windows 2019 image is 8.1.0, which seems like it shouldn't exist. However, based on the releases of , the number after the is probably what's important, which means that we're on version 6.0.0, which is indeed before the fix. I might ask in the project to see if it's worth updating mingw64 for this reason.
EDIT: Filed Depending on their response, if they decide not to update, it's possible could be fixed instead to stop trying to install Rust over an incompatible version of MinGW.
For some reason, my original issue description code snippet mentioned instead of . I think that's because I copy/pasted the wrong version, when I was seeing whether the workaround worked (which I believe it did). I apologize if that caused any confusion. I've now edited the description to fix this mistake.
Given that seems to be in progress and would close this issue, I mentioned that in for extra transparency.
Thank you for all your help on this! It's awesome that all this happened in only 4 days. I can confirm on my end that this issue is now fully resolved on the latest nightly release of Rust (2024-04-19).
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Cc The error is with the following backtrace
Ah but further up the call stack we have so I think this will be fixed by
I have pinned down the regression to a specific commit, thanks to recommending me . searched nightlies: from nightly-2024-07-28 to nightly-2024-07-30 regressed nightly: nightly-2024-07-30 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.9</summaryHost triple: aarch64-apple-darwin Reproduce with: : </details
Based on the commits in that rollup, I feel like might be the culprit, but it isn't obvious to me why that might be the case (cc
Thanks for the ping, will fix this.
<!-- 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 have the following code, split into two files: This code, as expected, produces , shown below. However, the help message at the bottom of the error appears to be referencing line 2 in , while displaying the filename , thus suggesting we add the annotation to a comment in . It should instead point to the in . <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The issue is that in , the span we use to look up the file/line mapper is the primary span of the message, i.e. the error in
<!-- 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 this code: I expected to see this happen: Rustdoc compiles the documentation as for older toolchains (stable, < nightly-2022-08-10) or as it is happening for / Instead, this happened: Rustdoc reports an compiler error <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: nightly-2022-08-09 : : points to as merge that introduced this regression which is a roll-up PR. and are included there and seems to be rustdoc releated. Pinging and as authors of these PR's. <!-- 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 --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the bug is coming from cc EDIT: also, would be quite useful to have a minimum code that we can use as a regression test.
Reducing compiler errors coming from diesel is quite hard and takes a lot of time. Diesel is already part of the rust compiler tests-suite, although in an older version. So it might be easier to just update this version to a current diesel version.
This is due to my PR. claim
is not documented inside the compiler so it wouldn't be very helpful unfortunately. Also, I didn't ask you specifically, just thought it might be useful to say it, so don't worry if you don't have time for it. :wink: Thanks !
The corresponding test code is here: I think it did not catch this issue as it uses an older diesel version (and it does not enable the corresponding feature flag).
I minimized this: And fix PR incoming.
This apparently was not fixed.
I can confirm that this is fixed for . Thank you all for the fast fix :tada:
Rust 1.70 build on Solaris sometimes files on some machines: I wonder whether it can do something with: ?!
are you running in parallel? that's not supported on solaris (you made the PR removing the build locking IIRC).
I see it does: . I think I should look once again if it's possible make to use fcntl locking (as it's now in `rustix... You can close the bug. Thank you!
Adding reference to main proble - isn't supported on Solaris due missing syscall).
I'm confused now. I have seen the same error even with (just one ocurance, not two as mentioned above). Also tried to dig closely how locking works and put into some debug prints with process id and lock file name. But later when I was inspecting still running process it didn't have any lock file open. No file descriptor no lock?!
did you clear the cache before running ? if the build directory gets into an inconsistent state we don't recover it automatically. i don't know what's going on with fd-lock, but the file that bootstrap locks is .
Everything is removed before new build...
exactly what command are you running and what is your
If I see it right, lock file is created/opened here: and the file descriptor for the lock file is closed on block exit here: Isn't it mean that locking isn't working even on Linux?
no, it's declared outside the block
Right. Unfortunatelly version 1.70.0 hasn't fix for this (my) regression. And the declaration is still insde the block.
we do not support old versions of rust. the only supported release is the latest stable release.
Isn't version 1.70.0 latest stable version? I'm just curious.
yes, you're right. i'm sorry. i think you should ask someone else for help on this issue. i am having trouble focusing today.
I run: and then: Where on some systems helps to run while on others it breaks it. When I look into the directory where rustc should be present:
i'm not sure why this is looking in . can you verify that exists? i wonder if is a hard-link to and that confuses on solaris.
It does: It's hardling. When I remove the asserion the build passes.
The Windows CI build with LLVM assertions enabled recently hung without an error message. It turned out to be an LLVM assertion failure resulting in a dialog which needed to be acknowledged, see According to the such a dialog is always displayed, but that is not the whole truth. Apparently can be used to customize assertion failure handling. We should definitely make assertions failures exit with error after printing failure information to stderr instead of displaying a dialog and hanging. label O-windows
Could this be part of why we're getting so many hangs in the CI?
That was responsible for four stuck builds recently. I don't think it was responsible for many timed out builds before that.
Posted with a possible solution.
Minimal reproducible example, targeting the STM32G030F6 microcontroller: This panics in the computation of when built with: Note: this had to be tested with in the dev profile, in order to fit on the small flash size on the chip. This was confirmed on the and toolchains. <details<summaryGDB backtrace at the panic</summary</details<details<summaryFull to build</summary</details<details<summarymemory.x for the STM32G030F6</summary</details
Would it be possible to provide the output for this test case?
This is inside compiler-builtins. The arguments in the stack trace seem all sorts of wrong all over the place, though. But the shift width passed into is what you'd expect. An ABI mismatch, maybe?
To elaborate on my remark above: the LLVM IR will only reveal a plain instruction, which becomes a libcall only in codegen. To the issue author: can you please also post the exact command you're building? I'm not able to reproduce a similar issue when using a based approach – in particular I see many more functions being inlined away, functions which in your case don't appear to be. This is what I was trying:
Cortex-M0+ uses , which is also shipped via rustup
Hm, I cannot reproduce inside QEMU (using , steps described below), but maybe I'm missing something (maybe the error only shows up on the real hardware and not in QEMU). Please correct me, if I'm wrong. <details<summaryReproduction</summary</details
Sorry, I will put together a package that fully demonstrates it and upload a tarball later today. I'll also provide the LLVM and executable output. To be clear, I wasn't building using any direct invocation of rustc, just with cargo.
So I managed to simplify the minimal example further a bit, as it turns out that simply panics too, since the formatter for integers involves multiplication. This is reflected in the following attachments. I have tested these on a live STM32G030 chip; the GDB backtrace is from that (over openocd through the SWD port). I don't consider myself knowledgable enough with QEMU to try to reproduce it there.
Complete example: Executable: <details<summaryGDB backtrace at panic</summary</details<details<summaryLLVM IR</summary</details
does it also reproduce on Rust stable (or beta)? Just to understand here if it's a regression or this issue has "always" been here (I suspect the latter)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Good thinking... I just tested it on stable and it appears to not be present there (or at least not with all else equal). I confirmed the issue on again just to be sure I didn't change anything else. I'm not sure if there's a good way to bisect the rust toolchain to find the regression? If there is I may be able to script it to see if GDB reports a panic and use that. Of course QEMU would be better-suited for that, so I may try to repro in it as well.
cool then probably we can try to find the regression To bisect we use , it will download nightlies in a range of time and bisect them to find where the regression starts. You'll need to download the Rust sources beforehand (this repo) and then run it like: should be 755 and something like: cargo-bisect will then download nightlies. The first one must not reproduce the issue, so if it does, move a bit back in time until you hit one of the last good nightly. If everything goes well you should get an ouput similar to Thanks a lot for trying to bisect the issue! :-) label regression-from-stable-to-nightly
Here's the report: searched nightlies: from nightly-2021-04-01 to nightly-2021-06-05 regressed nightly: nightly-2021-05-15 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
That is a huge commit, but if it helps, I have a hunch that the regression may actually be in , since a) the version of it changed as part of that commit and b) that's where the implementaiton of this is.
On the other hand, the connection to is weird. Before reporting the issue I did delve into the source but most of the arithmetic implementation stuff kinda went over my head unfortunately.
This is highly likely to slip into stable next week -- let's ping arm to at least get some more eyes on it (doesn't look like that was done yet).
Error: Parsing ping command in failed: ...'t ping arm' ' to at lea'... Please let know if you're having trouble with this bot.
ping arm
Hey ARM Group! This bug has been identified as a good "ARM 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
I can reproduce this on qemu. I'm not sure precisely what I'm doing differently to but I'm using the source tarball uploaded (plus a modified memory layout for the QEMU machine). Possibly in the cargo config would do it. From the last working rust commit bumping compiler-builtins to 0.1.40 (from 0.1.39) is enough to trigger this. Unfortunately, patching out compilerbuiltins to a local path (checked out to 0.1.39) also seems to reliably trigger it so I haven't been able to narrow down to a specific compilerbuiltins commit. Additionally I can't reproduce on , only v6.
That matches what I observed on real hardware as well.
54 stable will be built today and released on Thursday, this will unfortunately have to slip into stable :( The target is not tier 1 so this won't block the release, but it will be in the compatibility notes section.
Is the build process documented somewhere? Is it a highly optimized binary?
The build itself is done by our normal CI and the full release process is . The build doesn't take that long to finish though. The Release Team prepares the final release on Monday to be able to publish a pre-release on Monday evening, allowing testing from the wider community before the actual release goes out. It's possible to do a rebuild after Monday if critical issues are found and need to be fixed, but is not a Tier 1 target so a fix for this would likely not result in a rebuild, and would slip into 1.55.
Thanks!
I noted that the python scripts use the aws cli instead of the excellent boto3 library. But probably the scripts are battle proof by now.
This is a bug in LLVM's expansion of 128-bit shifts: The 128-bit shift is expanded to a series of 64-bit shift via . Note how the shift value in is only masked with before being passed to . This means that the shift value passed to may be larger than 64, which is UB according to the specification for (shift value must be < 64).
A bisect on compiler-builtins leads to this commit as the incidental "cause": Reverting it does fix this bug if a quick & dirty fix is wanted.
On second thought, I don't think this is an LLVM bug: it seems that the code calls with an out-of-range shift, but then doesn't actually use the result of that call in that case. I opened which should fix this, could someone test to see if this actually resolves the issue?
looks fixed to me. Nice work!
I tried this code: I expected to see this happen: rustc prints the target spec successfully, because it knows it exists: Instead, this happened: rustc fails to load the LLVM specification: Note that this is different from the error we emit for an unrecognized target: Also, this only happens for local builds, because we don't use the LLVM in the component in rustup, only when building rustc from source. ... wtf ??? HEAD is branched from
cc do you know what could be going wrong here?
Thank you for bringing this to my attention. It is possible that the locally builds has enabled , and that prebuilt LLVM does not support LoongArch architecture. It would be great if you could provide specific steps to reproduce. Thank you.
Yes, that's exactly what's happened, I have download-ci-llvm enabled and the prebuilt LLVM differs. Here's steps to reproduce:
The RustDev component builds LLVM here: but I'm not sure how that differs from the component?
I think the difference is that the of ci-llvm does not contain LoongArch, but locally it does. Is it time to update ci-llvm?
Maybe need to bump download-ci-llvm-stamp to pick up the LoongArch enablement?
Thank you for catching that. I was mistaken to think that the cached prebuilt ci-llvm would automatically update over time.
no worries :) it updates every six weeks when we make a new release, or if the submodule is updated, but it's cached until then so it's not constantly re-uploaded on every change to bootstrap.
Is there any way CI could help prevent such problems? Like, complain if gets changed but the stamp file does not, or something like that?
we can use heuristics, but they're only heuristics and I wouldn't want to fail CI on them. That said, having rustbot leave a comment if you touch rustc_llvm or seems reasonable, so the PR author can make a judgement call but also doesn't forget about the stamp.
It seems pretty strange to me that the env variable would take precedence over --config. It would be nice to switch the precedence. cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Added in ; it seems like it makes sense for --config to override, though probably not typically all that useful. Happy to see a PR, should be pretty easy so marking as such.
claim
I tried this code: I expected it to work on Windows 7 the same as it works on other platforms. Instead, this happened: the code get stuck in the initialization of logging, we acquired same-ish stack from multiple people using Windows 7 It was always calling ! On Windows 10 as under Wine the application starts normally My rust code produces DLL that is loaded by C++ application from 10 years ago Latest working version: Earliest version that gets stuck:
seems possibly relevant, but since this is just hanging, I’m not sure we can blame it all on snake oil this time. Though maybe? Wouldn’t be the first time it breaks the system in incomprehensible ways. First and foremost – could you minimize the reproducer? Both from the perspective of the Rust code (sounds like simply calling from should suffice?) and the OS setup (does this occur on a fresh OS install? If not, what modifications are necessary for the reduced reproducer to start hanging)
The nightly that it first started failing under is the first nightly after was merged, which just happens to be directly related to ? That's really whack given that the stack trace above shows the hang taking place just before any of the changes that PR introduced are invoked.
I personally do not have Windows 7, and would prefer not not bother players with more testing unless really necessary. But I can confirm that at least one of the systems was clean Windows 7 Home Premium from . And calling directly seems pretty complicated :( It requires calling which still requires knowing which algorithm to chose, and what flags to use :( I also see this in the documentation: and this in the code: , but unfortunately I can not say how relevant that it.
It's unlikely to be a problem with itself as that works in the earlier version. Is this code being used in ? In any case, I think the fix here is to simplify the rng code so it's as close to the old version as possible.
Yes logging is initialized in DllMain, I will soon post a very small example
So it is related to it being library.