available_parallelism() return 0 I tried this code: : ! <details<summarycat /proc/cpuinfo</summary<p</p</details
Looking at the , it appears that if returned 0 it would indeed be a problem, but why would that be? Could you try to run this small program, and return us the output of it? If it prints out for the could you also attach . label +T-libs +I-prioritize +O-linux -needs-triage
!
Can you post the output of running your test program with ? I'm just hoping you have some way to get strace onto this router :pray:
Right, that's what I thought. Let's try to pin point where the bug is by trying the same thing in C. Could you try to run this small program, and return us the output of it?
I think for any reason, when the value of 'CPUCOUNT' is 0, 'availableparallelism' should return Err
Sorry, I don't know how to compile C program onto the router
Well yes, but we shouldn't get 0 for starter. Hum, that's a bummer. Then I don't know how to debug this further.
Can you provide the compiled binary for me to run? The system environment has been given
I'm sorry, I don't know your environment, and I haven't used any MIPS. However if you able to compile with  as a dependency, we might be able to continue debugging. Could you try to run this small program, and return us the output of it? <details if needed</summary</details
Related: Unlike numcpus, which returns usize, std returns NoneZeroUsize, so this is a soundness issue. label +I-unsound
should probably just handle this by returning if fails rather than using . It's a weird issue (obviously there is at least 1 CPU if code is running) but who knows.
Maybe it's worth saying this explicitly: As far as I can tell by reading the man pages, this is a bug in glibc or Linux. The man pages for and don't look like there is any wiggle room for a platform to behave like this. Has anyone tried reporting this upstream? This issue is not the first time this problem has been encountered, but it looks to me like everyone else has papered over it.
If we're down for cursed things, this program will print the raw bytes in the cpuset which would at least let us know if the kernel is putting anything in there:
libc::CPUCOUNT is implemented in pure rust with straightforward code: I'm not sure I think there's a way for that code to fail to miss any bits.
you haven't mentioned which target-triple you're compiling for. Some are tier 2 and some are tier 3. Some use glibc, some musl. This could be relevant if it's a bug in libc.
This kernel version and is below the for the tier 2 mips-gnu targets.
The docs for already mention that it returns an estimate, rather than an accurate count. I take this mean a lower bound, so a fallback of would be consistent with my expectations. But I'll admit the docs do also seem to contradict themselves a few paragraphs later:
Regardless of whether this kernel is EOL (we support plenty of EOL kernels) and whether the wobbliness of applies here (I'm sure it doesn't, and it would be terrible for us to retcon this as permitted behavior), I think the problem here is that your kernel is buggy. A quick Google search for "mips schedgetaffinity" turns up this patch: Just going off vibes, this looks like it fixes the bug we are talking about. As was pointed out correctly above, the kernel you're using is not supported by this target, and upgrading to a supported kernel would bring in the patch above. Can you confirm that upgrading to a supported kernel (at least 4.4)? If an upgrade to at least Linux 4.4 fixes this issue, I do not think we should try to fall back to returning 1 if says . Might be nice to panic instead of executing UB though.
Yeah, panic makes sense. We should notify users that the system is bugged and unsupported. I'll make a PR.


Fails to compile with linking errors:
Either this or require that they are .
I think I disagree. Lang items should be public - for the most part they are used just like any other item.
Though there is some appeal to being able to hide lang items that aren't part of the public API.
I don't think we'll ever expect someone to use a lang item directly, and for an executable there's no need for lang items to be public, there's not even a need for them to be reachable really. I suppose we could just require that libraries have public lang items? Regardless, this seems like kinda a corner case to me because there's not that much interaction with lang items.
I'm actually surprised that this example compiled. I guess something in rustc was ignoring visibility when encoding calls to .


The Rust documentation on states (emphasis mine): However, this does not specify the behavior for . This value is exactly representable, the issue is in fact that it is representable in two ways. According to the IEEE754-2019 standard the behavior should be: In other words, the behavior depends on the rounding mode. We should specify that in this scenario we also follow the roundTiesToEven rounding mode, that is, the result of should be .
IMO this is just a docs bug, where we were overly strict by specifying that the rounding mode only matters when the result "is not exactly representable". Patches should be welcome.
I agree, there is no reasonable world in which we'll use a different behavior for signed zero than what IEEE 754 prescribes for roundTiesToEven. What would better wording be?
Something along the lines of "is not exactly representable as a distinct f32" perhaps?
I made a PR with an alternate wording I like. It simply drops any condition on rounding, simply stating we use the roundTiesToEven rounding mode, and clarifying what happens with sums. "The result is the representable value closest to the true value, if there is a unique closest representable value." also perfectly covers any result that doesn't need to be rounded, so no harm in dropping the condition.


Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)


https://crater-
searched nightlies: from nightly-2023-08-01 to nightly-2023-10-10 regressed nightly: nightly-2023-09-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: </detailsthis bisection may look pretty nonsensical, but I did manually confirm that nightly-2023-09-14 worked and nightly-2023-09-16 didn't. I am surprised that this ever parsed, and given that there's only a single random repo that regressed, and the regressing code is a mistake, I don't think this is a problematic regression. anyways.
Agreed that we don't necessarily need a fix, but we should try to make sure that this is indeed limited to this one case (i.e., it's not some broader incompatibility that may have gone uncaught in Crater)
The change here is that AST validation is now checking that the attribute is valid. Some other cases: Marking as needs-test, with the new behavior being correct


snippet: 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
Regression in probably ? cc
This is due to . The function name in the stack trace matches the title of that PR. cc
oops race condition, clicked the button before I saw you self-assigned -- I already found a fix
yeah, go ahead please.


Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this


File: /tmp/icemaker/issue--2.rs 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
cc


Bootstrap no longer documents any / crates or in CI. now only contains a meager 20 or so crates. This has to have regressed fairly recently.
It regressed in the latest nightly, we have CI tests on checking for some of these and the last daily test succeeded.
If I'm reading the commit history right there were a number of PRs that touched one of CI, bootstrap or rustdoc itself:
This appears to have regressed in ... but I'm pretty confused by that.
Since mostly allowed to have an effect, it could be that the issue is in .
cc and also maybe you happen to have an idea too
I don't have a clue how either PR could have affected building docs.
I would do quick check between the recently merged PRs as there are not many. It seems not to be so hard to find and fix the problem. But I can only do that later tonight.. I don't have access to my computers right now.
Ok, so the problem is when we use as a backend with llvm, documentation outputs generated by these backends seem to conflict with each other during the invocations. It appears that one of them(most likely cranelift) is not generating the compiler documentation. As we purge the previously generated documentation output at we end up with output that doesn't have the compiler documentation. I am currently unsure of the exact reason why cranelift is causing this issue. I will open a temporary fix PR and investigate further once I get more time.
Indeed the search at is completely useless right now. If a fix would take more than a day, reverting the offending PR should also be considered, given that those docs are quite crucial for rustc contributors.
Fix PR is already open at
Yeah I've seen that, but I can't tell if that's the lowest-risk approach. :shrug: Reverting (or un-setting on whatever builder builds the docs) is something we know will obviously work.
I am quite sure that PR contains no risk, but I am fine with reverting codegen environment variable updates in the runner containers
I'm fine either way but can't approve your PR since I don't understand the context of it. So if we can have it reviewed fast, fine, but otherwise - the revert is trivial to review.
did fix it locally, but seems didn't fix it on actual environment..
To fix this, we can either disable cranelift on the gh action step which we build nightly documentation or revert until we find out and fix the problem of compiler documentations with cranelift.
Which one is that?
I guess (never worked on the infra side before) these ones
Those steps just do the uploading, the docs are most likely created before. We need to figure out which runner is doing this and disable cranelift there.
It's done in multiple place(creating and uploading). I think the question is which one is getting deployed to
It's been 3 days without docs, clearly this is not entirely trivial to fix. Let's revert.
The docs are back.
While the immediate issue is addressed, do we need an issue to track the underlying problem?
We could. At the same time, and are also still working on this, e.g. in this as it's quite important to fix. There's little chance we'll forget about this, and it should hopefully be fixed very soon.
The underlying problem is that symlinks are being dropped in a wrong way between invocations. I can easily fix this by copying the document outputs instead of linking them, but I would prefer to invest a couple more hours in fixing the linking issue rather than replacing it.


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'not implemented: Cycle'', 'thread 'rustc' panicked at 'not implemented: Cycle'' 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
/ ping :grin:


When a type parameter is expected, but an unconstrained associated type is found rustc suggests a syntactically incorrect fix with a misleading help message about trait bounds instead of associated type constraints. No response


Reported by a lz4flex user I created a small repo to demonstrate on a minimal example. BorrowedCursor::ensureinit from this PR seems exhibit exponential cost. The program creates a Vec and reads it in chunks of 32kb. Size is specified as a command line argument (100MB-400MB). (If your default is 1.73) <!-- 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-stable -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Maybe try (tutorial: https://rust-) to find which PR caused this?
Really nice bisect tool. From the commit list in that Auto merge it seems to be
cc author
The loop creates a new on each iteration, which is fine if the reader can fill the provided buffer in one go but does unnecessary work on short reads. Should be easy to fix. claim
Any chance of getting this fix in a backport to 1.73?


<!-- 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 expected to see this happen: Compiles successfully Instead, this happened: <!-- 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. --: label A-coherence F-negative_impls requires-nightly T-compiler
I'll look into it


<!-- 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. --<!-- 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. --: The same problem is reproduced by rustc 1.76.0-nightly ( 2023-11-24). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oo this looks like but it's much smaller and doesn't need any features.
searched nightlies: from nightly-2023-01-01 to nightly-2023-11-20 regressed nightly: nightly-2023-09-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
So that would be then. The panic originates .
After that error, something is still trying to create a valtree from a function pointer, it seems. I'd say that's a bug, my PR just turns it into an ICE -- but silencing the ICE does not fix the bug. Certain errors need to stop rustc from doing any further work with the faulty code. Cc
Can we turn it into a Constkind::Error instead of ICEing?
I mean we could I guess, though it seems suspicious to me that we even call this function after the type checker already determined that this is not valid as a const generic.
We check the type of const parameters separately from when we compute them. Not doing so results in query cycles iirc :thinking: so it's probably best to somewhere here instead of ICEing


<!-- 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. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is this a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.


After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with


I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim


! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.


<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: compiles <!-- 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. --Regression in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high


I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!


<!-- 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. -- In particular, this also happens with . <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label F-dyn_star requires-nightly
Regression in nightly-2022-10-16 found 7 bors merge commits in the specified range commit[0] 2022-10-14: Auto merge of - woppopo:const_location, r=scottmcm commit[1] 2022-10-14: Auto merge of - matthiaskrgr:rollup-xxsx6sk, r=matthiaskrgr commit[2] 2022-10-15: Auto merge of - joshtriplett:is-terminal-fd-handle, r=thomcc commit[3] 2022-10-15: Auto merge of - Aaron1011:stability-use-tree, r=cjgillot commit[4] 2022-10-15: Auto merge of - compiler-errors:dyn-star-plus, r=eholk commit[5] 2022-10-15: Auto merge of - Dylan-DPC:rollup-97cvwdv, r=Dylan-DPC commit[6] 2022-10-15: Auto merge of - Nilstrieb:query-cleanups, r=cjgillot ERROR: no CI builds available between and within last 167 days maybe ?


and WebAssembly book () In Rust some requirements for WebAssembly targets. This makes Wasm binaries compiled with Rust (at least with default options/out of the box std) incompatible with older runtime environments, in particular not-so-old iOS safari (). Here is for example the support for Safari iOS 15.5 simulator: ! I searched but did not find any place where these requirements are written down. I think that this is a problem.
In principle Rust can produce binaries that only target the core subset of wasm 1.0 just fine. You do need to set some additional options with and build your own standard libraries though. But point taken, is missing dedicated pages on the wasm target that could contain this information.
The 2nd sentence right after the one you quoted outlines exactly what you need to do to take advantage of rustc’s capability to emit outputs to the wasm 1.0 spec (or any superset of it:) Make sure to do this and report back if you're still seeing the unexpected instructions/types/other entities after rustc is told to produce wasm binaries the way you need them to be. AFAIK, not for WASM.
Sorry, I realized I misunderstood your answer and deleted my post while you were answering it. Do you know how to show which features are enabled by default for a given target? I searched and did not find. I'm trying to discover whether is enabled by default on nowadays. As it seems to be because I am seeing types in the emitted wasm, even though I disabled the feature by "" in an environment variable RUSTFLAGS. It would be surprising to me that is built with that feature by default on wasm32, but maybe it is.
Hm, I'm actually not sure why you might be seeing simd128 in your modules. As far as I can tell it is not enabled by default for any wasm target. In order to print out features used you should look for lines in: For what it is worth I’ve been using this exact target at my $DAYJOB with a pretty primitive runtime and it has been working largely OOB if my memory serves me right. So it indeed could have something to do with your dependencies possibly using something like ? Not sure!
It seems that the was built with as I see this WASM function: What I am not sure is whether 1. this was integrated with the standard library and then imported indirectly to my project, or 2. somehow one of the dependency managed to enable it by itself. I tend to favor 1 but I'm not sure. That is why it would be great for such things to be documented :-)
For reference, I asked on the about how the std lib is built.
I confirm that as of version 1.75, the standard library is not using any WebAssembly SIMD instructions. Here is my test: which shows nothing, so they get pulled in by the memchr package through some of my dependencies.
You yourself pointed out which crate produces the v128 types: . It uses to enable emission of these types, regardless of the global configuration it looks like. This is usually fine for other architectures, but rarely for wasm, so it might make sense to file an issue over there.
I fully agree and I just opened an issue there: BurntSushi/memchr
As a heads up I've proposed that close this issue with documentation of how to target MVP wasm.


Reading the compiler code (specifically the one responsible for mir output) I found these s where probably expected . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Have you actually encountered an ICE due to this?
No, I just happened to find that. It's not a ICE, just a typo in the code
claim


<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage


The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.


Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high


Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!


<!-- ICE: Rustc '' 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an ADT', 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an ADT' 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: [adtdef] computing ADT definition for [typeof] computing type of [collectmoditem_types] collecting item types in top-level module [analysis] running analysis passes on this crate --
Actually nvm, don't want to work on this. heads up that this code is broken. It does not verify that the unnamed field is an ADT:


<!-- ICE: Rustc '' 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead', 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead' File: --snippet: 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking [analysis] running analysis passes on this crate --
cc


I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or


<!-- ICE: Rustc '' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' 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


I'm referring to this particular line Even though in environments Global as a structure exists and is defined, and it only shows up in PhantomData, the use of the structure is most likely undefined if attribute is never used. Yes, there will be no calls to Global as it's only a phantom, and execution will not be affected, but just seems ill-defined at least. For completeness: compilation of code that uses with custom allocator under is not affected, and there is no sign of runtime bugs.
Does this matter? It holds it directly:
My issue is the opposite - it should be in the PhantomData too, but not implicit
I understand, but it already includes for dropck, so why should it include it in the too?
To avoid inclusion of Global that has no logical relation to the BTreeMap instance with custom allocator
If it's accepted as a bug I can quickly fix it, at least it passes tests


Trying to build Miri against latest rustc artifacts fails: Regression range: Likely cause: Cc
How does miri link against rust?
Just a bunch of :
Given that rustc CI still works and only builds against the distributed rustc toolchain are affected, it seems likely that the issue is related to the rustc-dev component -- maybe that doesn't contain all the required files any more?
Reproducing instructions: checkout out to install the right toolchain (that branch uses ) -
The necessary symlink is indeed not part of rustc-dev (only rust-dev). We could add it, but it's not obvious to me why it is needed. I'm not familiar with how rustc generates that linker invocation, but the fact that it explicitly includes in it seems wrong to me ( is a dependency of and just linking against should be sufficient).
There is no component? At least doesn't list one and comes back empty. I don't know anything about this linking magic either.^^ Cc
But evidently the symlink is needed... so in the mean time it'd be good to unstuck this by adding the symlink I think. I expect this will break out-of-tree builds of Clippy as well, and rustfmt -- basically every tool that links against rustc.
Ah, it's not a real component, just the tarball that download-ci-llvm uses. Main problem is that we have checks against shipping symlinks, and I expect they exist for good reason...
Ah, yeah probably Windows doesn't like them. Why can't rustc_driver link against the correct .so file, i.e., why is a symlink needed in the first place?
I think this is the reason why it gets to the linker line: This is because llvm-config returns something like and the symlink is needed to resolve that to . And it seems like rustc just embeds the original name in the dylib, rather than the symlink-resolved variant, so the symlink is still needed. Possibly that's a bug? Similar to how shared objects embed the resolved name, maybe rustc should do the same for its own metadata. Though independent of general rustc behavior, I guess we could explicitly resolve the symlink in the for rustcllvm. That might be the most straightforward fix.
If llvm-config inherently relies on a symlink, how do they support Windows?
That would break compiling an rlib which states that it links against a certain dylib when said dylib is not available on the host, right? Currently you only need dylibs to be available when actually linking (that is using a crate type other than rlib or staticlib). It includes , not . Even if just was passed, has a for and thus needs to be present in . Edit: Forgot it is supposed to be in llvm-tools-preview, not in rustc-dev. By the way has never been a symlink afaik. Instead a separate copy was shipped in both the rustc and llvm-tools-preview components. The first for rustc itself to link against and the second for user code to link against. Just like we ship in both the rustc and rustc-dev components. Both copies just happened to be identical.
I just looked at the latest nightly and is present in both and as it should and has the correct filename for it. also has as .
I got confused about when got merged. I though it was already included in the latest nightly. I just looked at the llvm-preview component for that PR and it includes rather than the that is expected. Is it possible to rename it back and patch up the ? There is no way to link against with all linkers without a symlink, while for that is not a problem.
Why can't rustc_driver include ?
Because the linker will prefix the name with and postfix it with , so would cause the linker to look for rather than . (notice the different location of ) The only portable way to link against is to create a symlink from to , set the to and then tell the linker to link against . But on Windows we can't use symlinks. While on linux is possible, this is not the case on most other targets.
Windows doesn't have a concept of sonames, so I don't think a symlink would be used there. I don't know what the dylib is called there. We use static linking there anyway. So I think we wouldn't actually ship a symlink on anything but Linux. More problematic is the other part of this comment: If rustup-toolchain-install-master can't deal with symlinks, that's also a problem for Linux.
Any platform except Windows you mean?
As far as I can tell, dist-x86_64-linux is the only configuration where we link LLVM dynamically. (Well and the llvm-16/llvm-17 images, but that's non-dist and a different situation anyway.)
CI also starts with this exact same issue.
So to summarize, I see a few options here: Undo the library name change by carrying a patch in our LLVM fork. Implies carrying a long-term patch to LLVM, though a fairly small one. Undo the library name change after the fact. As pointed out, this isn't just a matter of moving the files, we also have to fix up the DTSONAME, which doesn't appear straightforward. Would require adding a dependency on patchelf? Ship the symlink in rustup components like rustc-dev, on Linux only. May require updates to tooling like rustup-toolchain-install-master. Change the way rustc links against upstream dylib dependencies, by resolving library names. Requires replicating linker search path logic and may break other other things. Not sure if this is possible. Same as 4, but only do this in rustllvms Again, not sure about the consequences, but at least this is more limited. I think 3 is probably ideal long term, but depends on just how broken symlink support is right now. Is this a matter of "we'll copy the file instead of symlinking" or "rustup-toolchain-install-master is going to abort"? Maybe knows. The easiest fix would be 1.
There's another fix, which is to ship a with content
Oooh, that's a great idea!
I got klint CI working with the fix:
Option 6, convince LLVM that this way of naming libraries is a bad idea and causes problems? I can't tell to what extent this is caused by Rust idiosyncrasies vs LLVM doing something strange. Wait, a .so file can be just a text file...?!?
Basically, LLVM used to do it's own thing here, and now follows the standard convention for shared object naming on Linux. This turns out to be quite inconvenient for us, but I don't think it would be reasonable to ask LLVM to undo the change. (Though, imho, this change really should not have been done in an rc3 release...) It can be a linker script. Somewhat unusual, but things like or are often linker scripts.
Well, if that linker script solution works that would be great. :)
This is now beginning to block Miri development. If someone reading along knows enough about linkers to approve that would be great. :)


Fuzzer generated custom MIR This code has UB under Stacked Borrows, but UB-free under Tree Borrows. Right: Wrong: While it looks like an LLVM issue, I couldn't get an IR-only reproduction. It's possible that rustc is producing IR with UBs On latest nightly cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I am only refraining from adding I-unsound so far because there's no surface Rust repro yet.
We should get , but we get .
claim
Upstream issue:
I do not have such qualms, especially because a fix is already on the way.
WG-prioritization assigning priority (). Keeping an eye on this issue to evaluate what to do when the LLVM fix lands label -I-prioritize +P-high


<!-- ICE: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: --
cc


<!-- ICE: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seeeems to bisect to :thinking: cc
Thanks Will take a look. claim
Reduced further:
the original (none reduced) one still ices :sweat_smile:
From what I can tell, it seems to have been fixed : Looks like I'm missing something
I have now opened PR to test the below original reproducer:
Sorry for causing the issue to be closed via the PR merge without asking you first. If you still believe the ICE is not fixed please reopen it.


The compiler allows this code when it shouldn't The following code is buggy: Invalid string contains, as the name suggests, an invalid string; sometimes I get a string filled with , sometimes just garbage, and usually it will eventually assert that the string contains invalid characters. It appears that the first gets dropped when the second one is assigned? Either the first is supposed to be dropped as happens now, and the borrow checker should forbid this code (since the old no longer exists, cannot have a lifetime), or it should let the first live until the end of the current scope, and make the above work.
What platform are you running this on? This code compiles and prints for me on OSX
I hadn't actually tried in my own rustc, I created the minimized version on rusti: Inspired by an actual bug that I got after trying to read some stuff from a file. It seems what I posted originally does actually compile and work properly on my system as well, I guess I should have tested that... I'll try and find and find a minimized example tomorrow.
is getting old at this point, and I suspect that this was fixed by
This one asserts (sometimes, it's random) for real on my system, most recent build of master (debian 64-bit, rustc 0.10-pre 2014-02-12 14:51:48 -0800) Assuming the executable is named bug: run with Removing the line that says gives me the output: Otherwise it appears random, usually asserting:
Quite plausibly due to , though I haven't dug in in detail.
It seems the bug persists even without the shadowing so perhaps this is related to , except for the 'match' part?
It appears that we allow this code to compile: Nominating, that's bad.
Any suggestions for a better name for this issue? The current name is misleading. Perhaps something along the lines of "Stale pointers can be created in safe code"?
Updated title and description
cc me
cc
Interestingly enough, the compiler rejects this code: It appears that the type ascription is throwing off the compiler?
Another example taken from
0, P-backcompat-lang
The compiler correctly rejects:
cc me
has taken a major detour to fix other two more fundamental bugs first. On top of that fix, the root cause of this bug is also becoming clearer. Case 1: Case 2: Case 3: The difference here is that the RHS is directly assignable to LHS in case 1 but not in case 2 + 3 so takes different code paths. And in latter two cases, there's bug in which upstream and downstream code inside disagree with the order of two parameters so two regions are merged incorrectly. The fix is rather simple. But the variance inference adds another twist to case 3. The result of variance inference can be used to do type parameter substitution, which is not enabled yet. The net effect is two negatives become positive; the current rejects that too.It did compile on top of , which in itself is incorrect. So I guess the fix for this bug must wait for the PR to land.


When compiling my feature and is included I got the attached ICE. The following is the unstable configuration is the repository this occurs on. I will get a minimal verifiable example setup shortly. <details<summaryBacktrace</summary<p</p</details
Here is the full ICE output:
Turns out I was missing in my deny list. Not sure if that should be an ICE or not, feel free to close if that is expected behavior. This wasn't a fix, the behavior still happened.
Does this specifically only happen with clippy, or does this ICE also happen with a regular /? The backtrace and the fact that these are all rustc lints/features makes me think it's a bug in the compiler
and both produce the same ICE.
Moving to rust-lang/rust in that case, since it sounds like fixing this requires changes in the compiler and we can't do much about that on the clippy side
From what I can tell, MCVE is or, alternatively,
searched nightlies: from nightly-2024-01-01 to nightly-2024-03-12 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsProbably , cc
I filled to address 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 tried this code: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- 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. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry


<!-- 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. --(reduced) (original) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongCode</strong</summary<p</p</details<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- The in closed issue is same as the .
Regression in The PR introducing the regression in this rollup is : Provide structured suggestion for searched nightlies: from nightly-2024-03-16 to nightly-2024-03-23 regressed nightly: nightly-2024-03-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This was caused by the introduction of which has no parent. This seems like a gun aimed squarely at the foot of any user of or . I believe we need to audit all existing uses of these (if you haven't done that already).


<!-- ICE: Rustc '' 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)', 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to cc


<!-- 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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.


<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' File: --snippet: 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced


In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test:


<!-- 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: I expected to see this happen: There should be a remainder as will not be yielded. Instead, this happened: If this is intended behavior, then it should probably be documented, as the current documentation of states that it: <!-- 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


While checkout out this ice (which does not require a feature gate btw, so potential beta-to-stable regression, which is inconvenient <!-- ICE: Rustc '' 'error: internal compiler error: unsupported pattern for pattern type: Pat {', 'error: internal compiler error: unsupported pattern for pattern type: Pat {' File: --snippet: 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: [typeof] expanding type alias [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --I clicked the tracking issue from = note: see issue more information = help: add to the crate attributes to enable = note: this compiler was built on 2024-04-08; consider upgrading it if it is out of date which is about an attribute and does not mention patterns or links to a related PR at all? :thinking:
What do you mean? Why would this beta a beta-to-stable regression? It regressed with .
cc pattern types need a real tracking issue, and you need to delay a span bug here rather than ICE
right now: beta -nightly regression once nightly gets promoted to beta: stable -beta regression once beta gets promoted to stable: stable -stable regression?
yes? but you can say that about every single regression that ever gets filed lol
exactly, unless it gets fixed in time :)
I don't see the purpose of pointing out that this is a potential beta regression before it has even landed on nightly, unless there's some reason that this is particularly difficult to fix, particularly affects user-facing code, or we expect it to slip the beta promotion for some reason.
Well, there are a few cases where feature gates actually do work and prevent crashes on stable
maybe internal features should just hard abort compilation if they aren't set
might also solve some of the internal-feature ices we are getting from time to time
...I do not see how it would be a regression, because we can safely bet on no one requiring the macro before the feature's library API landed. The code did not travel back in time to 1.77 compilers and suddenly become usable stable API.
its a regression because the compiler now crashes/ICEs where it would previously just show an error message.
please show me the codebase that regressed.
code that was not committed until April 8th, thus incapable of regressing on stable, yes.
ah yes not yet. this is why I wrote ;)
If it arrived on 1.79 on stable, it would be code that, since the moment it has been useful to write, has always ICEd. 1.79 cannot retrocausally regress code, unless you have a TARDIS or somesuch.
I it was code that did not ICE on 1.78, and now ICEs on 1.79, so that makes it a regression.
It was code that did not exist in this world on 1.78. It didn't exist in some timeless platonic realm of Forms. No actual programs were harmed in the making of this music video.
I suppose if you insist we can call them "regressions" when they involve code samples that just came into being, but I wish to know what I should call it when my actual tests fail from version to version of rustc and I have to spend hours bisecting the issue and figuring out where in the codebase it has gone wrong and fixing the problem before the new version comes out, either in the code or in rustc. Because it sure isn't a just-fabricated problem with just-fabricated code, it's something that matters in code that is supposed to build and work on the latest stable Rust version.
What it is is a feature gated feature ICEing without the feature gate, so we would see it ICE on stable if untreated. This means it is a higher priority ICE than an ICE that is only reachable with feature gates. We have not used "regression" as a term for "error -ICE" changes, as by definition that'a true for any ICE that does not require feature gates. If we flagged it as a regression, that would flood and taint the actually problematic regressions. We do flag these as regressions if there is no error before the ICE, as the user then has no information on how to fix it. So while is technically correct, in practice we don't and shouldn't use this terminology


<!-- ICE: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' 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: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim


This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:


<!-- 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 in Alpine Linux cross compiled to : For reference I ran this in a container on an M1 Macbook: I always see printed, even when I pass the program arguments. I'm not sure this is an issue with the environment as the following C program works as expected: :
uh.
Could you clarify: Does this problem arise with code ran on an ordinary gnu system? Say, a Debian container? Or itself?
I can take a guess at why this happens. For glibc targets we assume that the arguments can be retrieved without needing to store and . However if this musl compatibility layer doesn't use the then we can't retrieve them.
Ah yeah, it seems that behavior is a GNU extension that Rich Felker doesn't want to support?
Does just not work at all on musl if we're a cdylib, then?
Correct. When libstd's start function isn't used, only works on Windows, macOS and Linux with Glibc. On any other target it returns an empty list.
Apparently we already have this comment: In other words, we are already hacking around this issue for the miri emulator, and not using the fact that we are still given argv "naturally" via execve. We should probably just unconditionally call .
That would fix on Linux + glibc too.
Note that this was intentionally done but there have been other issues
I still think we can consider to still be fixed, as we just get our and it will be the same thing, even if the s behind the have been rearranged, right? So we'll set the atomics twice to the same value, which sounds very Working As Intended.
— in Well, given the remarks here seem to position this as a "wouldn't it be nice if we didn't do extra work?" and that this seems to be non-resilient in practice, as it has caused more than one open issue, I think we should be unafraid of doing a bit of extra computation.
I more meant that the fact that libraries mess about with (what should be) immutable memory is a safety issue so ideally we would parse it at the point where it's least likely that the are multiple threads. But people would probably complain about doing unnecessary allocating and extra work pre-main. Just storing argc and argv should be cheap though so I'm definitely not arguing against that.
the dilemma: strictly conforming posix programs shouldn't mutate argc and argv, but strictly conforming posix programs also shouldn't be aware of argc and argv if if they're dylibs, eh?
Could we check, first, whether we've already had these initialized, and only call this in the unusual case where they're not initialized? That would avoid the extra work in the common case, and do the work in the unusual case.
I don't know what you mean? We aren't doing substantial extra work. The thing that costs the most in runtime startup, I expect, is having the static initializer at all, which we then don't get to make choices about whether its called. It simply is or isn't.
Nevermind: ; forgot that was just saving off the values and not doing anything with them.


As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:


Sometimes when things go really wrong the compiler emits a ton of error messages. This can actually take a while to render them all. And since somewhat recently, hitting Ctrl-C no longer interrupts that, I get a thousand error messages displayed after Ctrl-C. I suspect this may have to do with The Ctrl-C handler does nothing at all on the first Ctrl-C unless the compiler is in the middle of const-eval. Cc
Do you have a reproducer? I have not run into this myself. The implementation should also ensure that the compiler exits promptly if you hit ctrl+c again. Does it?
if stuff keeps going on ctrl+c, sometimes suspending the process (ctrl+z) and then killing the terminal does the trick somehow :sweat_smile:
Unfortunately no, I encountered this during some rustc hacking where I ended up getting well over 1k error messages in the standard library build and that turned out to be hard to cancel. I thought I had tried that, but I am not entirely sure.
Is it possible the shell is part of the problem? If, by the time you hit ctrl-c, it's working through a large amount of output it still has buffered then it might be awhile before you see a response.
It's possible, sure -- but usually it reacts to Ctrl-C immediately even when there's tons of output.
Have you tried reverting to check if that fixes it?
No. At the time I was busy getting a PR done and now I don't have a reproducing example any more.
only checks for ctrl-c during const eval, so if no const eval runs for an extended period of time, the ctrl-c will be silently ignored. This is not the only problem with that PR. It also caused , and shows the "compilation was interrupted" error after the prompt is already drawn by bash.
is there a good way to make rustc loop endlessly without ever touching const eval? maybe via the trait solver? :thinking: it would help for debugging this.
Yeah, just take any issue (none are anyway). I can reproduce this issue with for example: nightly-2024-03-26 (before ): Exits after a single ^C nightly-2024-03-27 (after ): Requires ^C^C to exit bjorn3's analysis checks out.
cool! I wasn't sure how much of the compiler's code flowed through const-eval, is why I asked.
Another case where this is observed: IMO we should revert or at least make the signal handler run after a short timeout.
I'll post a PR that adds a timeout later today, but by all means if you feel strongly just put up a PR. The initial handler here was just through the normal PR process, there's no reason to be more cautious on reverting or modifying it.


These types are now, however, the docs don't properly mention them everywhere yet: lists OnceCell in the overview, but not LazyCell. The docs should also explain when I should use which of these types, as they are superficially pretty similar. lists Once and OnceLock, but not LazyLock. The same point about "when to use which type" applies. (It seems like is basically the same as , but I am not sure.) Cc
thatnks for the PR! The question of Once vs OnceLock seems to remain unresolved though. If Once is to OnceLock what is to Mutex, then it should probably be considered extremely niche as one can't even safely protect any data that way?
Yeah, I do indeed have nothing useful to say about Once, basically, because it doesn't seem very useful except as a raw implementation primitive of OnceLock. I suppose we could add a comment that soft-discourages it?
Yeah I think that would be useful.


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'expected region for ('a//0) but found Type(&'{erased} mut FooImpl<'{erased}, '{erased}, T/) when instantiating args=[&'{erased} mut FooImpl<'{erased}, '{erased}, T/, '?27, ?2t, Closure(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), ['{erased}, '{erased}, T/, i32, Binder(fn((&ReLateParam(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), BrAnon) mut FooImpl<'{erased}, '{erased}, T/,)), []), ()])]'', 'thread 'rustc' panicked at 'expected region for ('a//0) but found Type(&'{erased} mut FooImpl<'{erased}, '{erased}, T/) when instantiating args=[&'{erased} mut FooImpl<'{erased}, '{erased}, T/, '?27, ?2t, Closure(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), ['{erased}, '{erased}, T/, i32, Binder(fn((&ReLateParam(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), BrAnon) mut FooImpl<'{erased}, '{erased}, T/,)), []), ()])]'' 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 [mirborrowck] borrow-checking --
ICEs on nightly and beta, but not on stable. Minimized further: <details<summaryProgram output</summary</details
The ICE is another one from , cc
Still reproduces on 1.81.0-nightly (2024-06-13 ) -E-needs-test
I'll look into it later today.


I tried this code: I expected to see this happen: no warnings Instead, this happened: : cc
It looks like there is an upstream issue about this , but it seems like this shouldn't be an issue for dependents as long as is on edition < 2024.
It is expected for the lint to lint on macro-generated code. It is also expected for the lint to lint on all editions (it is not a edition dependent lint).
What am I meant to do as a downstream of a macro crate that hasn't fixed it then? I don't want to be ing a FCW, but there's nothing else I can do to clear this warning from my code. (And that implies that the planned "hard error in 2027" actually means for all editions, not just Edition 2027?)
Allow the lint. Report the issue upstream. Consider switching to an unaffected crate. That's understandable, but until the upstream crate is fixed I don't have a better solution. Note, that it is quite unlikely that this point that the lint will become deny-by-default in Rust 2024. No, if hard-error there is, it would only be for edition 2027 and higher, not below.
Why?
Detecting and ignoring macro-generated code for a lint where possible is the expected behavior of rustc.
Because, in particular for macro-generated code, we can't lint at the source since, well it is only generated when using the proc-macro or . Yes, but we must still emit the warning in macro-generated code, since the goal is to make the lint deny-by-default and then hard-error in a future edition, and without the warn it would go straight to hard-error which is not good.
Is there no ability to enable the lint when in the same crate/workspace but disable it for "foreign" macro-generated spans?
Yes, but can't rely on this. Also, not all macros have tests. The lint is only warn-by-default so it wouldn't break any test yet. If you mean: "don't lint on external macro", that is possible for but not for proc-macro since they are always external. We did an crater run, to evaluate the impact, before merging the lint in We had many cases with derive-macro, most of them (82.2%) where fixable by a , the rest would need manual intervention, the crate in question here was detected, and I reported the issue upstream with the fix that would fix the issue.
that was why I was thinking of trying to reason cross-workspace, but hmm, true. And actually, proc macros are worse: they can , so at least some are going to almost certainly slip through either way.
I would love if we had the ability to do that, but unfortunately doesn't have that information. Workspaces are a Cargo-only concept. :eyes:
I was hoping that we could do something where cargo helps us out here by describing which things we pay attention to, but I am fully prepared to believe that such is not tractable, even if only because no one has figured out if the infra for doing such a thing is even possible.
Yeah, unfortunately there isn't really anything else the compiler can do, it would be great if we could lint at the macro definition but due to the way they work that isn't possible, we are therefore forced to do the second "best" thing and lint at the usage. should be make it clearer that the "macro needs to change". So let's reclassify this issue as not-a-bug but as a discussion. labels -C-bug +C-discussion


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [tagforvariant] computing variant tag for enum [evaluateobligation] evaluating trait selection obligation --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That is the transmutability check asking for the discriminant of an uninhabited variant. I'm not sure what that code is doing with this information, but probably it makes sense to just remove the assertion and treat uninhabited variants like niched variants -- writing their discriminant is a NOP, but then the validation we do will definitely fail as the uninhabited variant cannot actually be represented in-memory. Cc
claim


<!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely


Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


<!-- ICE: Rustc '-Zcrate-attr=feature(effects) -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion 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: [adtdestructor] computing impl for [checkwellformed] checking that is well-formed -- label +F-constmutrefs +F-consttrait_impl +F-effects
Regression in of
doesn't require any features actually, rip
Removed irrelevant errors:
Minimized: or


<!-- 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: then shows I'd expect DWATdecl_line to be 9 (the line where the macro is called), not 5 (the line where the static is defined inside the macro). <!-- 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. --:
cc


<!-- 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. --(hand-reduced) <details<summary<strong(original)</strong</summary<p</p</details<!-- 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. --: Command: I put the option to remove "async fn" error, but I guess it is not an essential option to trigger ICE. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE location: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
searched nightlies: from nightly-2022-02-19 to nightly-2024-06-19 regressed nightly: nightly-2024-03-08 searched commit range: regressed commit: ()


Reviewing PR had some oversight regarding valid utf8 checks. This was graciously brought to our (meaning myself and attention by in . Fix should really just be changing to setting to , unless we decide there may be some merit to iterating again through the buffer.
label T-libs C-cleanup O-windows
label -needs-triage


Running with doesn't include a trailing so the next shell prompt gets smooshed on: I can't imagine this is intentional since all other options seem to include the newline. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +E-easy +A-cli +T-compiler -needs-triage
claim


<!-- 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. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of


<!-- 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. --The error cleared up when I cleared out /target/ and I couldn't make a minimal example, but I thought I'd post the panic message anyway in case its helpful. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is that a... panic during a panic during a panic during a panic?
This specific panic should be fixed by along with some of the reasons to panic while panicking.
So I don't think there's anything else to do here but link and close the issue.


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium


I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.


<!-- 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. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsthis was at the end of the error <pi have put a comment in the code where the problematic line is, the problem could be caused by async trait object method in ResourceLoader::startloading<bri am using asynctrait crate<brhere is the library code that the problematic code uses<brthe ResourceLoader trait is at the end </prustc-ice-2024-08-02T150352-!


<!-- 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. --Repro repository and steps: I've bisected between 1.79.0 and 1.80.0: searched nightlies: from nightly-2024-04-28 to nightly-2024-06-07 regressed nightly: nightly-2024-05-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.9</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </details<details<summaryOld context</summaryIt's a company project with a workspace that compiles ~680 crates on a clean compile. From initial testing it seems like an incremental compilation bug :S works, fails, but when setting in , succeeds again. also reproduces the issue, dropping the number of crates down to "only" 203. This is our profile config: </details<!-- 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. --This reproduces on 1.80 and the current nightly (as of writing this ticket). This does not reproduce on 1.79.0. : and <!-- Include a backtrace in the code block by setting in your environment. E.g. . --There is no backtrace being printed, even with . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's a proprietary code base, but I'll try my best to minimize the dependencies and code and see if I can get to something shareable. If you've got any other ideas on what to test or try, please let me know!
That LLVM metadata in the error looks like the kind that would be used with , but it's particularly surprising to me because as far as I know rustc only ever emits range metadata with a single range in it: might have some guesses here? Not sure why it would be incremental-related, though.
It's weird. My guess is that it's due to some LLVM Passes.
My first guess here would be a bug in getMostGenericRange(), but at least the basic case seems to work correctly:
Making progress on figuring out the minimal code to comment out to successfully compile again, on the way I've now got this:
Fully-minimized repro: Do note the release profile settings. Run with to repro. with Notes: Reordering the enum variants in Outer fixes it. Reducing the discriminant value of B or C fixes it. fixes it.
Thanks!
Reduced repro even further, with the minimal B and C values (thx Reduce them any further and the error is gone. Also removed the slice and replaced with just an equals check (since the bisect pointed to a check anyway)
Very interesting, I can trigger random crashes locally at stage 1, for example:
Never really looked at LLVM IR before, but guessing by what posted with the metadata: According to : The generated IR between 1.79.0 and 1.80.0 has changed significantly for builds. Rust 1.80.0, : Rust 1.80.0, Rust 1.79.0,
Ah, the minimal reproducible example is: (But I'm going to bed.
IIUC, this should be :
Upstreamed issue: claim
This can happen in any version:


The documentation of and for any signed integer type, e.g.: In the "Panics" section it says "This function will panic if is 0 or if is -1 and is .", but I believe this is the wrong way around: the panic happens on , not on , as (correctly) explained in and all other related functions. Also, is there any situation where someone would want over ? Mathematically, should really just be 0, that it panics is more of an implementation artifact (the corresponding division overflows). Maybe it would be a good idea to add something like "If this is a problem, use instead." to the documentation of ? Though in most applications will probably be positive anyway. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
the error is also present on and .


<!-- ICE: Rustc '-Zvalidate-mir --edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'', 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'' 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-async_closure
nightly-2024-05-23 =
With this full minimization: The real blame commit is:


<!-- 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 : And compiled it with . I expected to see this happen: The compiler should generate a function which only contains the instruction. Instead, this happened: The compiler crashes with . <!-- 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. --: As requested in
This is an LLVM assertion
It was noted in that this comes from sanitizer annotations being to naked functions. Seems like we might not want to do that? Cc
Almost certainly, but is not supposed to be used in places where user input can cause it to be reached.
Reported at
To clarify, the fix that landed is just to make this an IR verification failure rather than a backend crash. The underlying issue with the kasan + naked combination still needs to be fixed.
Should we file an issue upstream to handle this in sanitizers as well, or is there one already opened?


I tried this code: I expected to see it work. Instead, this happened: This regressed in This only happens when coercing from safe to unsafe, not unsafe to unsafe or safe to safe. I probably forgot something about how we construct the adjustment from unsafe to safe fn.


<!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' 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: [coroutinebymovebodydefid] looking up the coroutine by-move body for [analysis] running analysis passes on this crate -- label +F-asyncclosure
As a step of reducing your code examples, could you please ensure that is necessary to reproduce this ICE before mentioning it in the issue? This ICE reproduces on edition 2021, which is the current stable edition.
My project fails on nightly also while using edition 2021.
Yep, a fix is already up and it's waiting for approval. I recommend downgrading to a slightly older nightly until this is fixed.


<!-- ICE: Rustc '' 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'', 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'' 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: [issizedraw] computing whether is [layoutof] computing layout of -- label +F-impltraitinassoctype +F-inherentassociated_types
ah lol this regressed in cc


When running any bootstrap command, it complains that it can't figure out whether my master branch is outdated. Of course it does, as it just YOLOs into , which is just a file and not a directory for worktrees: it should probably not do that (i don't have a suggestion on what to do instead) regressed by
i would say adding a bit of error handling that checks if it's in a worktree doesn't sound too hard. there's two options from there: emit the warning in a worktree. this is basically trivial, but if someone does 100% of their work in a worktree, they may end up with an outdated upstream and not know it back to a more reliable method when in a worktree


<!-- 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. --When compiled as a standard binary on the host system, the exit codes are returned as expected. When compiled with wasm32-wasip1, the use of ExitCode results in the exit code of 1, regardless of the value provided to ExitCode::from. The following are the minimal examples used while reproducing the bug: The above example produces the expected error code of 10 when compiling for the the host system and (executed with wasmtime 24.0.0). The above example produces the exit code when compiled for the host system but returns exit code 1 when compiled with (again run in wasmtime 24.0.0). Looking at the resulting WASM (decompiled to WAT) we see the main function returns a (here compiled with ): For source code of the reproducer, see: Tested against stable, beta and nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
It seems that we just call ?
Minimized: claim label -O-wasi
Oh, "cool"!
that is so concise! Thanks. I’d also be very interested in getting some insight on where to look in the code base for this sort of thing.
I'm kinda just abusing my IDE (RustRover)’s Go To Declaration & Find Usages shortcuts, you may need to tell yours to use the wasm target for name resolution/code indexing instead of your OS’ default one.
I ran the tests in my reproducer repo against the latest nightly (post merge of ) and the all pass now. Thanks!


E.g. if a test doesn't have a fn it can prevent the test from ICEing because ICEing codepath might not yet be reached before compilation is aborted. In this case, the stderr should be printed to help the person figure out that "I forgor to annotate crate type" is the cause.
you can set env var which should print stdout, stderr and exit code
Oh right, good point, I forgor this existed. We should (I'll do this later unless you want to work on it): Mention this env var in the panic message for when the crashes test no longer crash. () Mention this env var in rustc-dev-guide. () EDIT: ended up duplicating some description of ` in because I would not have thought to look there for docs specifically.


<!-- 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: I ran the following commands: <details<summaryOn 2024-10-01, this renders like this</summary! </details<details<summaryOn 2024-10-02, this renders like this</summary! </detailsNote that the bullet points are spaced farther apart. I'm assuming this is a regression?
I think this is a consequence of which was intended to address . GG is adding a UI regression test for the spacing in for . cc
It's indeed something that we changed on purpose.
Little modification: the changes are improving the situation but introducing some new other issues. Talking about it currently to figure out what's the best solution.
I opened Please don't hesitate to take a look. Hopefully I was able to improve the current situation without going back to the original issue.
Certainly seems better than before!


When I do , it says: Strangely, when I do , it uses the correct name: No idea how it is even possible for this tool to have two different names inside bootstrap...
I think this is just because cargo-miri's tool check step is generated through a macro this macro generates the check message via there's a in there too. The build step has a different name because that macro explicitly asks for a display name
If I make the macro use a display name,
Ah, I didn't realize those two steps were defined entirely independently.
Anyway, should make this more consistent.


The input for doc searches isn't sanitized, allowing for arbitrary HTML input.
Is this problematic? Afaik everything is done client-side.
Yes. For example, if rustdoc documentation is served on a site that uses a cookie for authentication, an attacker could perform XHRs on the victim's behalf by injecting a tag. It's not particularly problematic on the site, though.
But the search is done with client-side javascript on a client-side resources index; how can you secure that?
I'm not sure what you mean by the search being unsecurable because the index is searched on the client. The problem is that the Javascript responsible for rendering the search query does not properly escape it, so an attacker can insert arbitrary HTML and therefore execute arbitrary Javascript in another user's browser merely by tricking the user into following a link. This is easily fixed by escaping and here: If you're not convinced of the danger, see for an example. If I were more nefarious, and I knew of a site that served rustdoc HTML documentation on the same domain as another site that uses cookie authentication, I could impersonate a user of this site just by convincing them to follow a link I've sent them.
I see thanks for the explanations, opened up a PR for it.
I think this is the part that makes me go from "meh" to "OH!." There's not a lot of damage on rust-, but we shouldn't open up others to these issues.


When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:


// BEGIN CODE // -- rust -- fn main() { log "doing"; thisdoesnothingwhatthe; log "boing"; } // END CODE The following code compiles, wouldn't it be wiser to have the compiler report an error about "thisdoesnothingwhatthe"?
Closed by .


The expansion of and both currently cause code to fail the stability check because they expand to reveal unstable implementation details. A seemingly reasonable solution to this would be to just not run the analysis on any code that has been macro-expanded. cc
I definitely agree with this approach: we should be able to annotate a macro with a stability level, and that's what should count for its users. Do we have a way of telling what part of an AST was generated via macro expansion by the time we get to linting?
Mostly; there's the field of a : for normal code, for macro generated code (basically containing the backtrace of macro invocations that led to that point).
OK, that makes this sound like a pretty easy fix. I'll take a quick look at it tomorrow (unless wants to?)
Hm, this seems slightly subtle, since the contents of a macro would then never be checked for stability. This differs to a conventional function, e.g. given , won't warn, but the contents of is still checked, while where is just never checked. (Of course, macros and phasing are both feature gated so you have to opt-in to instability to use non-standard macros anyway.)
Good point. Also, it looks tricky with the current infrastructure to even lint on the macro invocation -- the backtrace of macro expansion does not appear to link to the def_id of the macro (or give any other way of getting at the macro's stability). Nevertheless, I think we should bail out of the lint when we hit the results of expansion; those should be checked, if anywhere, at the site of macro definition. One other question: do syntax extensions also produce the span information you mentioned above? I ask because original problematic cases are written syntax extensions. If not, is there some other way of telling that an expansion happened?
I have a patch ready that bails of out the lint on expanded code. This also seems to mask uses of . If y'all are ok with this strategy for now, I'll file a PR.
Sounds good to me. Thanks!
cc


Right now we are running 8-core/15GM VMs but only 2 builds at a time, usually with -j2. It seems like we could easily bump this to 3 builds at a time to improve our utilization.
We might also switch back to high-mem instances, which have 30GB RAM, but slightly slower CPU's. That would allow us many more builds.
I've bumped the builds per slave to 3.