I was looking at namely issue when I thought about this. If work is being put into improving error messages when somebody uses a keyword that defines a function in another language, there should also be improved error messages if someone uses the incorrect directive to bring something into the scope of their module or namespace/ Given the following code: The current output is: The error message should preferably suggest the user to use the directive to bring something into scope of their module. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
For the record, on nightly, both and suggest using . I'm sure it's not that difficult to add .
ah. I was not aware of this. Less work to do then!
[Ignore this, just notes]
And also add ? Rust may go tooooo friendly in diagnostic message . Do you mind that I make a PR for it? I'm a newbie in hacking Rust compiler.
Sure! The earlier message should clarify where the edits are needed to be made. Ain't nothing as a diagnostic too friendly. =)
Remember to assign yourself using rustbot. Just a note for the future, usually if someone has already claimed an issue, it's not exactly common for someone else to fix it [aside from if the issue is abandoned by the claimee]. Since you're a newcomer here, I removed my assignment (and because I was working on another). However, you can find loads of easy issues with the E-Easy and/or E-Mentor tag for gaining experience. A few resources that might be helpful - Have fun hacking on Rust!
claim
Totally forgot about ! Good catch!


should be to guarantee that we emit an error when that flag is set. This is already done for of other types in rustc. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
renamed to to keep consistent.


<!-- 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: App P: App C: Build this in Windows. Since has "windows" subsystem, it will create no console window (i.e. no process). Since is a console app, when the process is created, I expect to see one console window that prints "Hello World" infinitely. App creates its console window but no text is printed. In Windows, spawn() eventually calls to with a , whose  is hard coded to . Additionally, it also with , and set them to the . Since app uses "windows" subsystem, it does not have console. stdout is always . Combining with in causes the unexpected behavior. If I make a call to with same parameters except a "zeroed" , it exhibits the correct behavior. spawn() should only conditionally set the flag if it can obtain those device handles, and never set any of those handles . Like this (pseudo code): <!-- 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 think this will need a T-libs-api decision as the current documentation for  (and stdin/stderr) is: I would guess that this "inherit by default" is why it's implemented the way it is. But perhaps there's some wiggle room with what it means to inherit handles that don't exist so we can change it. In either case it would be good to have some way to use platform default behaviour here. label -T-libs +T-libs-api
That's exactly my point. If there is nothing to inherit in the first place, just inherit nothing. The current behavior () is simply wrong. I believe fixing it doesn't violate the current specification.
Basically, currently there are only two options when handling the stdout/stderr: inherit or pipe. I think there should be a third option: isolated - make the child handle its console by itself. For example, if user calls and , he basically says "the parent process doesn't care about the child's output". It is the same as the "windows" subsystem case above. In this case, the flag should never be set, regardless if or is called. More importantly, this is de facto the default way of how a process is created in Windows. Defaulting to really makes me confused before reading the internal source code.
Not always. Parent process can still set those handles to something other than . For example, if you launch App P from IntelliJ it actually prints "Hello World!" in a loop but not in the spawned console which is empty, but in IntelliJ internal terminal. returns non invalid handle. This solution would make behaviour different depending on how you launch your app. Also, you can explicitly ask to create new console with even if your app already uses console subsystem. In this case you also likely want to avoid inheriting handles because you want output of the spawned process to be displayed in the new console, not in the existing one. This solution doesn't help with this.
I can't verify your statements since I don't have IntelliJ atm, but even it's true, isn't it IntelliJ setting up the console with maybe some special debugging API? How to you modify the code of P to achieve the same? And realistically speaking, do people actually do that with GUI apps? I think in this case, it's impossible to be 100% sure where the user wants the output at. New option might be the way to go.
Your prediction was dead-on, as it came true in While we can do this, as is proposing, it seems best here that we create a function, or set of functions, that explicitly handle this kind of situation rather than guessing.
Even with new APIs, we still need reasonable default behaviour. And the Command API is documented as inheriting handles by default. However, currently the API neglects the "no handle set" case entirely as that's not really a thing in POSIX or ISO C (well, you can close stdio but that's usually considered a Bad Thing unless you're being very very careful).


<!-- 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. --The condition seems complex, but a practical instance is I tried this code: I expected to see this happen: it compiles Instead, this happened: error: Notes: It compiles in , but failed in works, and works <!-- 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 --
label F-typealiasimpl_trait
works, and breaks
Caused by Any ideas? cc
also works (a version before which is reverted by
TAIT and RPIT were made to work the same in the revert, thus TAIT was changed from before instead of just reverting to the old behaviour. I will need to look at some typeck logs to see what's goin on here
FYI, it seems that the bug is not related to but to every nested .
I've tested with the following codes: It seems that the result of for is wrong: It seems that wasn't be resolved correctly.
I think fixed this (inadvertently?) in
Just tested it and I can confirm it works now! Thanks! BTW, what about adding this issue as a test cast?
Yes a minimized test PR would be appreciated.
claim


with rustc master looks like the stabilisation version is borked? :sweat_smile: cc
Hm, it actually says it like this in the code :D
This is correct, but not ideal: https://rustc-dev- cc maybe we want to special case this in the diagnostics
Yeah seems I've missed correcting that lint. For GATs, the stabilization version will be adjusted very soon, in the coming days, as we are close to the release cycle. But this needs to be fixed for future stabilizations as well. Working on a PR. label bug
Error: Label bug can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Yeah it warns correctly for lib features so only lang features are affected:
PR filed:


I would expect the following code to compile successfully since we explicitly opt out of implementing : However, the code fails to compile with the following error message: label C-bug A-lint F-negativeimpls <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The compiler only checks if the type implements already to return early and not emit the lint diagnostic but it doesn't check if the type implements :
I think this makes the trick, you are right! the last think is to explore what is the code of the method The code of the method looks not so trivial :) If you did not find already I can play with your on it by mentoring you, I had some experience in "git archeology" :) label +E-mentor
claim


Example: yields <details<summaryBacktrace</summary</details
cc and
This has to do with late-bound regions and RPITITs. I have a fix, but it's probably not right nor is it cleaned up much. I'll put it up for scrutiny soon though.
Actually nvm, it was a silly little resolver bug.
label +I-ICE +C-bug


<!-- 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. --found via fuzzing <!-- 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
It seems that the ICE does not need and no_core feature. A little bit smaller example is:


I tried this code: I expected to see this happen: I expected to see two diagnostic messages, telling me about the distinct parse errors on lines 1 and 2. Instead, this happened: The first error was treated as non-recoverable, yielding this output (): I'm assuming recovering in the face of this parse error would be a relatively simple task, given that there is already the present that should be a strong hint that someone meant to type . So I'm tagging this with labels indicating that its a good opportunity for someone who wants to acquaint themselves with the code base. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(This needs a mentor. I am thinking that if someone doesn't pick it up by Friday, then I will see about using it as the basis for one or more instructional videos.)
I can mentor whoever wants to work on this. See for the general area where changes need to be made, and ping me if someone needs help on Zulip.
May I work on this?
You can , and I recommend checking out the to find out what the contribution process looks like.
i would like to work on this with your help.
claim
release-assignment
This is mostly about adding checks around such that it recovers when encountering . However, we would also need the ability to recover to be configurable as arguments to , as we would want to recover from as well. PS: don't take this as is.. I am not that familiar with ast and recovery, but I think this is the main idea
I will take a quick look into this. claim


Latest mingw has broken headers () therefore missing definitions locally. This causes error on mingw-w64 since its header is not broken. :( cc
Quick fix is adding at . mingw-w64 doesn't define them, defines instead. I think we should prepare a plan when mingw also fixes it. (They already fixed third one of on w32api-4.0.3.) However, seems like mingw doesn't increment : both 4.0.0-1 and 4.0.3 have value .
mingw-w64 gets its' own section in , doesn't it? So adding mingw-fix-include to include path in can be conditioned on some macro defined there. As for mingw fixing their headers, I think we can just remove fixed headers from mingw-fix-include when that happens.
I'm building rust on mingw-w64-32bit but rust thinks it is on mingw. I'm not sure this is "legal", but I don't want to cross-build from mingw to mingw-w64-32bit since their difference is small.
has three mingw entries: i686-pc-mingw32 (normal mingw), i586-mingw32msvc (anyone who know this?), and x86_64-w64-mingw32 (mingw-w64 64bit). We don't have i686-w64-mingw32 (mingw-w64 32-bit). I don't know if it is good idea of adding it, so quick fix seems sufficient for now.


Instead, this happened: Successful compilation Tested on the playground, all versions and editions. Stable channel: 1.64.0 Beta channel: 1.65.0-beta.3 (2022-10-10 ) Nightly channel: 1.66.0-nightly (2022-10-19 ) I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet. label +T-compiler +A-lifetimes +regression-from-stable-to-stable <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01 regressed nightly: nightly-2022-07-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
claim
Actually, this behavior is correct as : There is exactly one lifetime used in the parameters (), so assigning it to the output lifetime is as expected. release-assignment
That verbiage but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) mirrors in specifying input positions, not counts. Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional. label +T-lang
Ok, so we will consider this for now a regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (). label -I-prioritize +P-critical
Filed
Nominating for lang team to figure out what we should do with this. Will also ping on zulip.
Discussed in lang, dropping nomination. Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window). Considering whether we want to make the behavior change can happen in a follow-up proposal.


<!-- 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: The program terminates. Instead, this happened: The program loops indefinitely. I encountered this while working on <!-- 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. --:
Hangs here: label I-hang
CC
Thanks for the report. Priority wise, this seems like it isn’t going to be super high priority to resolve, given that 1<<47 is 128TiB. 128TiB, unfortunately, is half of the maximum supported address space on many modern x8664 and aarch64 deployments, so it is conceivable that this could be actually hit. Still would be nice to actually fix it. As for the strategies to fix this, there are a couple of approaches to consider: could store the into a u128 (2 usize on any supported platform today.) This is not super future-proof, and unfortunately probably somewhat more costly in the non-const-evaluated case. could use instead of . When overflows on the last iteration, it will become the maximum value that fits in and the termination condition will be hit. Not super clear what codegen quality implications are for using saturatingmul; a widening/checked multiplication and additionally compare the high bits for in the terminating condition. This is an alteration of 1. I suspect this is going to produce the best code, but that remains to be seen.
Would it work to change the termination condition from to ? Where means it wrapped, so the logical value is out of the type's range, and thus bigger than .
Or weirder: store instead of , so the comparison can be done using and the squaring operation can be replaced with a doubling (bit shift).


: Fails on nightly 1.66.0 but not on stable 1.64.0. <details<summary<strongBacktrace</strong</summary<p</p</detailsEdited: minified the code
Also ICEs on beta
stable error -beta ICE I tried moving things around so lifetime is on , but that's fine. This also requires the lifetime .
Going to preemptively assign P-medium, since this code isn't correct anyways. I think this has something to do with our error recovery here, since this valid code is fine, which only changes the trait:
I got a fix here.


<details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression from () <details<summaryBisection details</summarybisected with <a href=''cargo-bisect-rustc</av0.6.4 searched nightlies: from nightly-2022-10-06 to nightly-2022-10-28 regressed nightly: nightly-2022-10-09 searched commit range: regressed commit: Host triple: x8664-apple-darwin </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
this function call crash for the assertion fail, from the log, is with count = 1, and is also 1 when crashing. Do you have any clue? is implemented at here, I'm still not quite familar with the query part:
It looks like the parens are parsed as generic parameters for a type that doesn't have generic parameters? The simple fix is just check .
I think a reasonable fix is modifying the API for , It reasonable to add assertion for , but it's better to return false for outside of expected range?
Have a test on C++'s , which also has this assertion: emm, it's better to keep it for .
claim
I'd be curious to know if we can maintain an invariant in the HIR that it does not contain generics that do not align with . That was what I assumed when writing that code, but that may be too optimistic.
I considered removing the assert too, but I think it's better to have it since it exposes invalid assumptions as in this case.
We should (replacing the assertion) -- that's probably fine as long as it's understood why the does not line up here, and it's understood why we can't fix it somewhere upstream (e.g. in parsing or lowering instead)
I have a general question for , why we just exit when we find a fatal error in parsing (which can not recover by simply autofix). I have a real Dev experience when working on , I was editing an file with 3k+ lines of code, and I forgetted remove an extra '{', then the compiler give about 20+ errors, the first two are from parsing: But there are many many other errors from later phases... I need to scroll up several pages to the beginning of error to find the rootcause.
If we can not get valid AST in parsing, later phases such as analysising will report out extra (mostly unhelpful) errors?
The assertion is inside of the data structure. I generally expect data structures to simply assert on pre-conditions. We could put a delay-bug before the call, but that also seems like overkill since that is already on the error-reporting path. I agree there are cases where rustc should quit sooner. But in general I think we have to err on the side of recover-and-continue if there is some possibility that more helpful errors may be emitted.
This can happen. The parser should be more realistic on what it recovers and avoid errors from later passes that do not make sense. A few years back we would stop as soon as any error occurred in a given pass and avoid trying any further evaluation, and that was also a usability issue, because people would get a false sense of "how much work is left to fix". We shouldn't have a blanket evaluation stop, but maybe be more aggressive about pruning the AST when multiple parse errors have occurred.
do you want to take over this issue? I currently don't have any clue about the rootcause. Or we give it an simple fix now.
I can take a look.


Our CI system building artifact for aarch64 with the release of Rust 1.65 I tried to reduce the bug a bit: dependencies Build with (same with ) Since Rust 1.65, we get this error: Can still be reproduced in nightly
I wasn't able to reproduce this (on either stable or nightly).
You're right, trying in a fresh project i couldn't reproduce. I realized the original also contained a that was also necessary I edited the original description to add Thanks for looking into this.
Also, contrary to what i wrote initially, the bug appeared first in 1.65 (and not 1.64)
Thanks, I can reproduce the issue now. Reduced test case:
Upstream issue:
The upstream issue appears to be fixed. What needs to be done now to apply this fix?
I can still reproduce this on 1.68.0-nightly ( 2022-12-15).
Can confirm that the issue still exists.
New upstream issue:


<details<summary<bbacktrace</b</summary</details<details<summary<bfull stderr (two panics / backtraces)</b</summary</details: label requires-nightly A-associated-items F-inherentassociatedtypes
Context: The recent PR implemented the resolution of inherent associated types but it appears that parameter substitution was overlooked.


In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


I was chatting with today, who mentioned it'd be helpful to mention the newly stabilized APIs from the docs. The benefit of using is that even if the type widens, the result doesn't change. It'd be nice if someone could contribute docs mentioning from . This probably just needs to be a one-liner. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


I tried this code: I expected to see this happen: Successful compilation (because this would succeed for the target ) 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is It should probably be applied to riscv32 too
Doesn't seem like anyone else has picked this up yet, if it's as simple a fix as it seems I would be happy to make the PR.
claim
The mismatch still occurs if extra features are specified by (e.g., ).
Sorry about the delayed response. I just tested it, but I'm not seeing the error. Could you test again as well? I was running the following command: Here is the version I'm on:
Hm, I actually encountered the issue in a more complicated setup () with bare-metal targets and assumed from the symptom that it was caused by a similar underlying problem. I'll look into it again and open a separate issue after getting a better idea.


I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign


Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.


Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (


<!-- 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: text //! #..#.####.#....#.....##.. //! #..#.#....#....#....#..#. //! ####.###..#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.####.####.####..##.. //! I expected to see this happen: When I run , I expect to see ASCII art in the output that matches the above example. Instead, this happened: In the output, this actually appears: It appears that if a line starts with at least three s, one gets "swallowed" somehow. <!-- 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<summaryBacktrace</summary<p</p</details
It's because of how are handled for rust code blocks. I'll send a PR but we need to ensure that people are not relying on to hide a line for non-rust code blocks.
This is actually a regression. I haven't bisected, but it occurred sometime between 1.50.0 and 1.63.0 based on a quick test. In 1.50.0, the following code block markdown /// # Header /// rendered as , but in 1.63.0 it renders as a blank code block.
Thanks for the information !
The regression is in nightly-2021-07-15 Commits in range: commit[0] 2021-07-13UTC: Auto merge of - camsteffen:hash-lint-resolved, r=oli-obk commit[1] 2021-07-13UTC: Auto merge of - cjgillot:expnhash, r=petrochenkov commit[2] 2021-07-14UTC: Auto merge of - Mark-Simulacrum:edition-no-clone, r=petrochenkov commit[3] 2021-07-14UTC: Auto merge of - tlyu:option-result-overviews, r=joshtriplett commit[4] 2021-07-14UTC: Auto merge of - JohnTitor:rollup-8ltidsq, r=JohnTitor commit[5] 2021-07-14UTC: Auto merge of - michaelwoerister:const-in-debuginfo-type-names-fix, r=oli-obk,wesleywiser commit[6] 2021-07-14UTC: Auto merge of - GuillaumeGomez:rollup-pfz9jbk, r=GuillaumeGomez commit[7] 2021-07-14UTC: Auto merge of - cuviper:fuse-less-specialized, r=joshtriplett Maybe this happened in (merged by ) (cc


Found with a error]: auto traits cannot have associated items thread 'rustc' panicked at 'internal error: entered unreachable code', <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2022-11-05, somewhere in rollup , likely (CC 2022-12-14 label +F-autotraits <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Fixed the ICE, the error message now is: I think the second error message should not come out, considering the is an auto trait.


Compiling the  from failed on nightly due to lifetime error while it works on stable. The code in question looks like this and is in taken from On nightly, this failed with: :
modify labels: +regression-from-stable-to-beta
labels +E-needs-bisection
searched nightlies: from nightly-2022-12-06 to nightly-2022-12-10 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details labels -E-needs-bisection
searched nightlies: from nightly-2022-12-09 to nightly-2022-12-27 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Sorry, false positive in bisect labels -E-needs-bisection Also raced, sorry :(
You can manually bisect the PRs in that rollup, contains the list of each of their artifacts. I'd start by looking at though.
Yep, it's cc
Possible other examples from beta crater: https://crater- https://crater- https://crater-
Any update on this? I've tested the code on: and it still failed.
AFAICS your bug report has been acknowledged and has an assignee, looks like it's a regression in the beta channel (). The new stable will be out in a few weeks, might be fixed by then.
Thanks, so looks like it's going to take quite some time. I might go ahead and release without waiting for this one.
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler


<!-- 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: One error occurs from the missing semicolon. Instead, this happened: An additional unexpected error occurs when when I obviously do not want to invoke a closure. Also note that the semicolon error is after the supposed closure invocation, when I would expect it to be after the . Occurs on latest stable and nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label A-diagnostics D-newcomer-roadblock D-terse
The compiler would consider the case the same as I think it's hard to determine if the user wants invoke a closure or not by writing the "()" to the next line. Rust allows syntax like this(actually a lot of languages allow this type of syntax)
We should definitely be able to look at the spans of the callee and the argument list, determine if they are on separate lines (via the ) & don't originate from a macro expansion and if so at least add a note to the diagnostic suggesting to add a semicolon. Of course, there will always be false positives.
The case should be handled in both the parser and the call error. In the parser we can't be certain that the call expression is incorrect, except for maybe literals, but if you had we are back to ambiguity, so that should be handled in E0618 and suggest a semicolon there as well. You could also have which would parse successfully but fail only in the call.
claim
When adding a nice parser error you have to make sure that you never emit a parser error for valid rust syntax. So for the example Esteban described above handling it in the parser is fine since the statement is missing a semicolon, making it invalid syntax. But you have to make sure that something like doesn't give a parser error but only errors during type checking. This is because of macros, which may transform code that is valid syntax but invalid semantically into something entirely valid.
At the very least, these cases should be handled
I guess I should also be clear that the suggestion currently provided by rustc could never be correct: function (and closure) names can't start with integer
The diagnostics currently emitted by the compiler are absolutely correct: An integer cannot be called and the let-statement must be followed by a semicolon. Indeed, identifiers (“function (and closure) names”) cannot start with a digit. However, this is not relevant here: Syntactically speaking, the callee (the thing being called) in a call expression can be an arbitrary expression. Consider (this might even be well-typed depending on the definition of and its s). So is syntactically well-formed but semantically it is not (according to the trait solver) as there is no primitive integer type (e.g. ) that implements or friends. Technically speaking, could very well add a implementation for that makes semantically well-formed, too. This is the reason why you see the error messages you posted. Edit: I hope it's already clear from context but I'd like to emphasize that I am not saying that the diagnostics as emitted today should stay the way they are (we should definitely suggest to add a as mentioned above), I am just trying to clarify the semantics and disputing the quoted statement.
Ahh right, I forget briefly that function calls could be on values, I was thinking of the integer literal being seen as an identifier only (and of course integer identifiers don't exist). Silly me!
the point you're making is why we can proactively catch the "literal followed by ()" case in the parser, and avoid the second, unnecessary "invalid call" error. But for the general case, where the parser doesn't have enough context (a, b and c in my examples), we would have to emit two errors, or delay the parse error until resolve.
According to the discussion, the current diagnostics emitted by the compiler are correct. Can we close the issue now?
the compiler errors are correct, but they are misleading, so we'll put some effort to improve the output to make it clear what is happening to everyone, regardless of expertise level, at a glance.
ok. So we still let the compiler emit 2 diagnostics, one is from the parser, another one is error[E0618]. How about the output being like this? Which won't be misleading the user to program code like ;
Hmm, I haven't really been keeping up to date with this so this might not be ideal/possible but: This parser error is, IMO, wrong. It should say "expected , found ". We shouldn't leave out the here.
Disclaimer: I might be biased by the phrasing of existing diagnostics. The error message expected , found looks like it's describing a syntax error, even though it's not (it's a type error) as I've previously mentioned. The wording expected / found [token] is exclusively used by the parser as far as I know. If I see that message I assume that annotating the container with or adding the CLI flag would not make the error go away. Because of this, I caution against using such phrasing. I expect it to look similar to:
Sorry, I should have been more clear: doesn't really make sense to me, it leaves out the which is obviously important in this context. EDIT: AFAIK, it still remains in the parser, and it definitely is still a syntax error. As for your suggested diagnostic, the proposed suggestion doesn't seem quite right in terms of wording. Adding a semicolon does not fix the error; it does not provide a function, but rather makes the error go away by removing the expectation of a function in the first place. This has to be explained to the user, otherwise it just looks even more confusing.


rust version: Do you think it would be useful to add a hint here? Something in the lines of <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
i was hoping this to be my first PR to the compiler, if accepted as necessary. :D I need some guidance as to where this code might be though...
claim
hups sorry
I was testing the bot feature
The 'is not an iterator' message comes from the attribute. One solution would be to add a new case to that attribute which detects literals of the form (where both sides are numeric) and suggests the iterator syntax.
thanks!
is this in the right direction?


Today I synchronized my local version of the rust repo, made a few changes and formatted. This prints: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is a known issue, it means that you have a remote to the rust-lang repo that is outdated. The 35k lines likely means that it is at least behind the test move. Does running (replace with the remote name if different) fixes it ?
Maybe we should remove these logs?
There is the same problem if you created lots of file in the formatted directories, but did not track them in git: It will print the name of all of these.
I think we should avoid printing the names of the files if there are more than 10 (or whatever number). That would avoid all similar issues.
claim
Hi! May I know if you're still working on this issue?


The problem is that the configure script assumes that all keys are in a section and there are no top-level keys. This forces people to use instead: We should make it possible to set top-level keys through , both and . We should also update the line in the readme linked above to suggest instead of printf. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: look around I think the fix would be something like .
In the , from where exactly do we get the top-level keys? from the set function?
I'm not sure off the top of my head. How could you find out that information?
Hi are you still working on this?
do you think it's okay to unassign ? This issue is blocking as well.
Since there's no response from the assignee, I think you can take the issue. Are you still keen on working on this issue?
Yup I am interested! claim
Hi and thanks for mentoring! Assuming I run , I think will be 2. So I am not sure if this path would work. It seems like the first blocker is that does not contain or as keys. Should the approach be to expand with those keys? Or should we just allow / as special cases? I am guessing it's closer to the latter, since that might affect the definition of which searches for . Finally, I am a little confused what top-level keys mean - do they exclusively refer to [, ] ? Are there more?
I am able to expand when parsing to include and but I realise I may either have to make changes to or write a new method. Before I do that, I would like to understand how the configure script is commonly used. Could you give me some sample commands, say if I want to modify the field of llvm?
Shall we refactor the 2 top level keys under a section? this makes the parsing logic more consistent and unwieldy lol
you can take a look at for a complete example of what a configuration could look like. I think that would resolve most, if not all of your queries(: Hope this helps!
try running
Got it, thanks I put up a PR. This is kinda my first PR so would appreciate all the tips and advice!


(and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.
I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole


This occurs with binary crate that is able to target macOS and is most visible when cross compiling. is sufficient. The command produces the error on Linux machines, with or without . [ ] Previous Stable [X] Current Stable [X] Current Beta [X] Current Nightly I encountered this when cross compiling from Linux to macOS. Setting to some path that does exist but isn't a valid macOS SDK gives the expected linker errors of not-found libraries and undefined symbols. <details<summaryThe correct linker errors, which occur with (or any other path that exists) </summaryerror: linking with failed: exit status: 1 | = note: "" "-flavor" "darwin" "-arch" "x8664" "-platformversion" "macos" "10.7" "10.7" "/tmp/rustcmRdv6R/symbols.o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-L" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps" "-L" "/home/qyriad/code/hello/target/debug/deps" "-L" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "-lSystem" "-lc" "-lm" "-syslibroot" "/usr" "-L" "" "-o" "/home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-" "-deadstrip" = note: error: library not found for -lSystem error: library not found for -lc error: library not found for -lm error: undefined symbol: UnwindResume referenced by () /home/qyriad/code/hello/target/x8664-apple-darwin/debug/deps/hello-(symbol ZN4core3ops8function6FnOnce9callonce17hf4bc1fd436eb6a1eE+0x1f) referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb84e30cb55012ce5E+0x80) referenced by () (std-):(symbol ZN4core3ptr104dropinplaceLTusizeRPGT$17hed3f267c6b45955bE+0xd1) referenced 89 more times error: undefined symbol: memcpy referenced by () (std-):(symbol ZN4core3fmt5Write10writechar17hdfc69d6746a59f51E+0xd4) referenced by () (std-):(symbol ZN50RFu20u20u2010writechar17h93a4c2621e683652E+0xe5) referenced by () (std-):(symbol ZN50RFu20u20u209writestr17h37febf5394bdf526E+0x38) referenced 82 more times error: undefined symbol: UnwindGetTextRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17h8d16de3fdc0c0a05E+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hebef1726d888f975E+0xc) error: undefined symbol: UnwindGetDataRelBase referenced by () (std-):(symbol ZN4core3ops8function6FnOnce40callonceu7bu7d$17hb69dca3e57cf94bbE+0xc) referenced by () (std-):(symbol ZN3std11personality3gcc14findehaction28u7bu7d17hbca95bb609e12226E+0xc) error: undefined symbol: pthreadmutexunlock referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x2e) referenced by () (std-):(symbol ZN4core3ptr175dropinplacestd..syscommon..remutex..ReentrantMutexGuardLTGTGT17h7737580f0f37fcd6E+0x20) referenced by () (std-):(symbol ZN4core3ptr46dropinplaceGT$17hf0f24132fd49ff9eE+0x43) referenced 7 more times error: undefined symbol: munmap referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0xce) referenced by () (std-):(symbol ZN4core3ptr65dropinplaceGT$17hf85f5ce9a3e31452E+0x31) referenced by () (std-):(symbol ZN4core3ptr68dropinplaceGT$17hc7e97f0fcf430b3cE+0x6) referenced 6 more times error: undefined symbol: pthreadrwlockunlock referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x33) referenced by () (std-):(symbol ZN4core3ptr71dropinplaceLTRPGT$17hd1e2d6a084e6fddbE+0x1a) referenced by () (std-):(symbol ZN3std3env7varos17h3777805ff41a36e7E+0xab) referenced 3 more times error: undefined symbol: pthreadmutexdestroy referenced by () (std-):(symbol ZN4core3ptr73dropinplaceGT$17hd8239a4ac87360b9E+0x6) referenced by () (std-):(symbol ZN4core3ptr98dropinplaceLTGT$17hb027e78f6c4c6db8E+0xd) referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x6f) referenced 1 more times error: undefined symbol: pthreadmutexattrdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17hca493304f47198a7E+0x6) referenced by () (std-):(symbol ZN108u20u20GT$4init17ha3b0898f5c42f4f6E+0xdc) error: undefined symbol: pthreadrwlockdestroy referenced by () (std-):(symbol ZN4core3ptr75dropinplaceGT$17h7c423d2bc244a6ffE+0x6) referenced by () (std-):(symbol ZN3std10syscommon8lazybox16LazyBoxT10initialize17h760b822df99198c6E+0x70) error: undefined symbol: memmove referenced by () (std-):(symbol ZN4core3ptr90dropinplaceLTGTGT$17hcdc9da9cacd190baE+0x36) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x269f) referenced by () (std-):(symbol ZN9addr2line16ContextR11findframes17he44479834bec168fE+0x1223) referenced 18 more times error: undefined symbol: memcmp referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x13e) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0xda) referenced by () (std-):(symbol ZN4core5slice4sort12choosepivot28u7bu7d17h1db2e1cfbb6463b0E+0x5a) referenced 31 more times error: undefined symbol: pthreadmutextrylock referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17h1dfce2778cdf5d36E+0x17) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x1c2) referenced by () (std-):(symbol ZN3std4sync4once4Once9callonce28u7bu7d17h9c07188eab35bf0eE+0x7f) error: undefined symbol: dispatchrelease referenced by () (std-):(symbol ZN5alloc4sync12ArcT9dropslow17ha7ab73c110de5a07E+0x31) error: undefined symbol: abort referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x570) referenced by () (std-):(symbol ZN3std3sys4unix14abortinternal17ha17a3eb079646e02E+0x5) error: undefined symbol: error referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x3a3) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x334) referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0xb5) referenced 19 more times error: undefined symbol: mprotect referenced by () (std-):(symbol ZN3std2rt19langstartinternal17hd56d2fa7efb2dd60E+0x256) referenced by () (std-):(symbol ZN3std3sys4unix14stackoverflow3imp12makehandler17h50336235e5e30f96E+0x85) error: too many errors emitted, stopping now (use --error-limit=0 to see all errors) </detailsOn Rust 1.66.0, it simply emits the (non-internal) error: , which makes sense. I imagine this would also happen on non-cross builds targeting macOS if isn't available and isn't set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label regression-from-stable-to-stable O-macos A-cross A-linkage
This is an issue with a buggy translation message: This should be , not .
This is fixed as part of
assign


searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:


<!-- 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. --Example code: In rustc 1.67 stable this generates a number of moves (I suppose for calling convention?) that I don't think need to be there, especially when inlining: See While this is a pretty pointless example, this comes up in situations where you might want to convert a tuple of slices into a struct of slices in order to assign names to the tuple members.
LLVM should probably be able to elide the below and pass the original pointer. label +A-llvm +I-slow
This seems to be resolved on current nightly by & Thanks :tada: (I'm not so sure about an incoming inherent problem on alignment attribute)
Fixed as part of the LLVM 17 update (), needs codegen test.
Making the sum a little more vague than the above code prevents the removal of memcpy. Edit: It seems like not so, precisely, the above argument is a function pointer, not a closure, and I now think function pointers never capture any variables (because of ?, ). So is this another missing opportunity?
Yes, the removal is only allowed in the original example, because the called function is known. It does not work with an unknown function due to missing . Note that the is on the by-value argument of , not the by-reference argument of the function pointer .
That sounds reasonable. Thanks! So, in this case, if the assumption that the function pointer never captures the argument was correct, missing attribution opportunities for the callbase?
I don't think there is any missing attribution opportunity here. In your example, if is nocapture, then that does not imply anything about being nocapture (it's a completely different object). Even if you directly passed through the argument to the call (without intermediate memcpy to alloca), inferring nocapture is still not straightforward, because allows interior captures (i.e. it's possible to capture the pointer within the function, as long as it does not stay captured after the function returns).
(Edit: Now I think that on case, capturing in LLVM might happen. Thanks!


I tried this code: I expected to see the warning: Instead no warning was reported by the compiler. Observed in nightly, 1.67. Seems like the warning was shown in 1.63 and stopped showing in 1.64.
Bisected to CI has expired so I couldn't automatically bisect further, but looks like a likely candidate
It looks like the issue is that dead code detection doesn't work inside closures and generators (which async functions use in their desugaring) This is denied by 1.63 but allowed on 1.64+. label +regression-from-stable-to-stable Here, the parent of the closure is so checking dead code is skipped.
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high


The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim


cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.


<!-- 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. --Hi, I hit a strange build failure in CI where fails to build for . Here's a reduced reproducer: <!-- 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'm using current nightly, but this is a regression from stable () to beta (). : points to (in ), but this feels like an LLVM bug. I can't trigger it via and though. The LLVM version matches, but I'm probably not reproducing 's interactions with LLVM faithfully.. Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side :slightlysmilingface:
It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.
i hit the same problem. build failed for
May be caused by a trigger for
FYI, this can be worked around by enabling optimization. The same workaround works for error from when using build-std in the latest nightly. (, , , )
Maybe its relocation is too far then that has been truncated?
This issue should be fixed by . Initially, the cause of the issue and the solution are explained in , but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.
label llvm-fixed-upstream
Can someone confirm that this is fixed on nightly?
Yep. My initial reproducer fails with but compiles on . :chartwithupwards_trend:


<!-- 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
Minimized with : label +S-bug-has-mcve
searched toolchains through Regression in
Alternative: Would the error change if the compiler is built with ?
Triage: This is no longer ICE since today's nightly, I assume fixed it. Marking as E-needs-test just in case regression tests there didn't cover this case. labels: +E-needs-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: The API should report the given path exists. Instead, this happened: When passed a path to a UNIX domain socket on Windows, I get: <!-- 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 think this is simply an unintended consequence of supporting symlinks on Windows. It is interesting that seems to be producing a correct result here (IMO this metadata should be returned by ). The differences between () and () is the flag. On Windows, UNIX domain sockets are implemented as reparse points just like symlink. However Rust is only setting the flag when we are testing for symlink. Without this flag is going to return the access error above. I think the issue is that, the standard library didn't consider that the possibility to have other type of files that are reparse points but not symlinks. I'm not sure what is the best fix for this, but this is kinda surprising. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is indeed a long standing issue. You also get the same thing with app aliases, etc. The fix I've been considering would be to add a fallback to stat so that if is encountered then it uses . Though it would then need to discard the result if the reparse point tag has the name surrogate bit set (which, incidentally, is what  tests for). If anyone is interested in trying to implement this then feel very free. I'd be happy to provide guidance if you as the reviewer of your PR.
I can give this a try. 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
`
label +S-bug-has-mcve
What is the expected output here? Can this actually compile, and if so, what does refer to?


Found this while minimizing :smile: So maybe related? didn't seem like duplicates. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +S-bug-has-mcve +F-typealiasimpl_trait
Regression in nightly-2022-07-01 reproduced based of a modifiction of which does not need any feature gates and crashes stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium


<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably fixed by (
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in same as ..?
You should update your cargo-bisect-rustc version to make it bisect the contents of rollups as well^^
I already have the git version installed :o
Note that we don't have the artifacts for all rollups. I think it requires a perf bisection to be run on the pr or something?
Regression in nightly-2021-09-01 `
Ah, the rollup predates unrolled builds.
I think this is a different issue, it's not fixed by that PR anyway. I'll try and investigate anyway claim The ICE occurs while trying to report this error Changing to fails earlier:
Actually this can be reduced further -


Impl 1: Impl 2: Godbolt: These functions should be equivalent, but the second function generates one more if than the first one. This also happens when using and then doing the slicing manually. I expected the impls to generate the same code.
Quoting myself on Zulip:
This is a metadata preservation failure during SimplifyCFG speculation: Preserving here used to be illegal, but thanks to we are allowed to preserve it now. Only need to drop .
Upstream patch:
Fixed by , needs codegen test.


(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable


<!-- 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. --Excessive (extremely excessive) chaining of operators causes a stack overflow in rustc. In my experimenting I found that this happens with precisely 6115 chained operators in the playground, but it appears to depend on your compilation environment as it took approx. 8000 on my machine. This is easily avoided by splitting the chain (or having an iota of sanity), but I would expect to at least exit gracefully in this case. The code below uses only the Not () operator, but at least the Neg () operator also works, as does mixing the two (ie ). <details<summaryCode</summary</details<details<summaryLocal (Windows) Error Message</summary</detailsThe playground error message was too long to include here, but a copy can be found in this gist: <!-- 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 above code was tested in the playground (Debug, Stable, v1.68.1), and a version with 8000 chained operators crashed on my local machine with the following :
Technically, it did (in the Windows case). The stack overflow was caught by Rust's handler and a message emitted to explain that it had reached stack overflow, instead of simply exiting without remark. This fulfills the letter of your expectation for it to "exit gracefully", but perhaps not your intent. You may wish to clarify how graceful an exit you were hoping for. It may also be interesting to know if you somehow found a way to use this to cause a stack overflow that did not emit such a message. I am not sure how to interpret the Playground case, honestly, perhaps that qualifies... Possibly we can manage to avoid overflowing, in any case. I only make such a pedantic note because it can be hard to do better in the face of resource exhaustion.
That's a very fair point. I had actually done the playground one first after someone on Reddit mentioned this, and only tried on windows while writing this. What's weird is that while windows was able to at least give me a general idea of what happened, the playground straight died with a SIGSEGV.
The way the Playground one goes, I really wondered if there is something that happens due to libc??? But no, the backtrace is really thousands of lines like this:
Disregard that, I was talking nonsense and looking at the wrong values. Stack offset is only a bit over ~1KB but consistently is about ~1KB each time. I think the problem is more just "no attempt to guard the final page" or something like that.
Well, I see this note in So that might be a possible fix here (if it's not already called in there).
Diagnosing stack overflows is imperfect on Linux. It's always a at first, and then we have a signal handler that tries to decide if that fault looks like it hit the stack guard page so we can report a nicer abort. But the kernel manages the guard page in the main thread with its dynamically growing stack, so we have to try to guess where that may be. We should do better with fixed thread stacks -- but I think also messes with these heuristics.
Example now compiles with... more operators, since , but still meets its demise and that grody error. Why? Because it hits the parser: Note that the signal handler dumps that huge error message on Linux because we install a custom signal handler, which feels like it was written in the Medieval Rust Era or something. On Windows, we simply wind up using std's signal handler, which prints that simple message. So I guess to resolve this bug we should improve the error message or simply delete that code.
I have opened to make the error message less cryptic, when that merges I think we should declare victory on this.
Victory declared.


Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.


<!-- 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. --You need rustc built with debug assertions in order to reproduce this! <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim


The example currently uses , but now that the macro has been stabilized in , it should probably use that instead. This should be an easy contribution for someone who wants to land a first contribution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
hey can u help me from where i can fix this
Can u tell me how u solve this?
I have already solved this one and it is in the process of being reviewed for merging. If you wish to solve an issue, you need to pick one that has not been assigned yet. Try looking at this:
hey im new to open source, i want to grow in this field . Can i contact with u ?
I am pretty new to this project myself, but please reach out if you have any starter-questions and then I might be able to help you out. There is a chat on https://rust- - I am just "Mads Ravn" in there.
Thanks


While logged in as on Linux:: the Rust repo The suggestion to run isn't helpful if you don't already have a Rust toolchain installed. That leaves: "Alternatively, use the pre-vendored dist component." It's completely unclear to me what this means or how to do it. Perhaps providing a link to documentation would be useful. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh this is very funny, is what rustup calls it, which is of course completely unhelpful in this scenario where you don't have rustup and are building from source. Mentoring instructions: should link to
Hmm, I guess for this particular scenario you might be building from a commit other than latest master as well. We do technically package it for individual commits: but AFAIK that isn't documented anywhere. Maybe we should add it to forge?
claim
hello, i'm taking the liberty of claiming this pull request, but I'd like some information. Should I propose a solution (like the curl command with the right url?) or just propose the documentation page?
claim
claim


I tried this code: I expected to see this happen: rustc prints the target spec successfully, because it knows it exists: Instead, this happened: rustc fails to load the LLVM specification: Note that this is different from the error we emit for an unrecognized target: Also, this only happens for local builds, because we don't use the LLVM in the component in rustup, only when building rustc from source. ... wtf ??? HEAD is branched from
cc do you know what could be going wrong here?
Thank you for bringing this to my attention. It is possible that the locally builds has enabled , and that prebuilt LLVM does not support LoongArch architecture. It would be great if you could provide specific steps to reproduce. Thank you.
Yes, that's exactly what's happened, I have download-ci-llvm enabled and the prebuilt LLVM differs. Here's steps to reproduce:
The RustDev component builds LLVM here: but I'm not sure how that differs from the component?
I think the difference is that the of ci-llvm does not contain LoongArch, but locally it does. Is it time to update ci-llvm?
Maybe need to bump download-ci-llvm-stamp to pick up the LoongArch enablement?
Thank you for catching that. I was mistaken to think that the cached prebuilt ci-llvm would automatically update over time.
no worries :) it updates every six weeks when we make a new release, or if the submodule is updated, but it's cached until then so it's not constantly re-uploaded on every change to bootstrap.
Is there any way CI could help prevent such problems? Like, complain if gets changed but the stamp file does not, or something like that?
we can use heuristics, but they're only heuristics and I wouldn't want to fail CI on them. That said, having rustbot leave a comment if you touch rustc_llvm or seems reasonable, so the PR author can make a judgement call but also doesn't forget about the stamp.


I tried this code: I expected to see this happen: No panic during runtime Instead, this happened: Panicked during runtime <details<summaryFormat: was already formatted once</summary</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.70 (beta) and Rust 1.69 (stable) <!-- Provide the version you are using that has the regression. --: None I also reported this here , but I think this one is on . assigning you, because I suspect this has something to do with recent changes.
I'll look into this tomorrow. Can you check if it also happens with -Zflatten-format-args=no?
This is unrelated to and was caused by a recent change to the panic runtime. I've posted a fix at


Happened during probably since cc
You'll need to delete the directory. There was probably a file left behind, and git won't delete the directory automatically.
Hm, there is no such directory ?! :sweatsmile: There is a though
My fault. I forgot to update Will send a PR.
What is most concerning to me is that this actually did not fail the entire , so this would/did not even break CI..? is there something we can do about that?
Run in CI probably? I supposed to run it locally before submitting a PR. However, that was an unlucky day. Something on nightly cannot build, so I blindly pushed .
Oh, sorry, I misunderstood what was going on. There have been some issues with those directories being moved around, but this was different. The issue here is that the credential helpers are being included on an "as available" basis. Because they are nightly and experimental, they were intentionally marked as being optional so that if they failed it wouldn't cause problems here on rust-lang/rust. Eventually, if it gets stabilized, this will need to change to make them required tools.


There should be a test for ensuring that it does not have the same bug as and , that inside of the const refers to instead of inferring a lifetime. The following code is what passes and should be as a test: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
are you still working on this? If not, I would be happy to claim :slightlysmilingface:
there is no activity from them for almost a month, so you are free to claim it now
claim


This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with


I decided to try address sanitizer on WSL Ubuntu today, but ran into 2 errors. These errors are only present when using the sanitizer, so my crate compiles normally. To give context there are 2 crates: and . On there is a procedural macro called , which is named the same as my crate which I am re-exporting it to. I don't really know if this a bug or a problem on my end, but I thought I'd mention it just in case. : I included the full error output in a file below
If you use sanitizers you need to pass the flag, but I guess you missed it. See also :
Oh I did miss it and that fixed it. The documentation made it sound optional though, so I didn't realize that was the issue. Thanks for the quick reply!
Re-opening because the error is very confusing. See also
On the error is: which isn't great, but at least suggests some issue related to asan. On the error is: Which is very confusing. was merged between those two versions and changes in which cases E0519 is emitted. ping who wrote that 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</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic


Apologies for the not-very-readable reproduction. It was generated by a fuzzer and this is the best I can minimise it to. The program has no UB under , and Miri prints 22, this is also the result with Very strangely, if you drop to 0 or 1, the result becomes 11 which is wrong. Reproducible on both Apple Silicon macOS and x8664 Linux cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Executing the program trough reveals that under Stacked Borrows there is UB:
It does, and since the UB involves and which carry the wrong and right results (11 and 22), the miscompilation is likely due to an assumption that was valid under SB but not under TB. Though this bug probably isn't in mir-opt as a low gives the wrong result. It could be in IR gen or LLVM itself
(defensively labeled this as unsound because that seems more likely than not)
is relevant:
Here's the diff that ConstProp produces. Does this look relevant? Relevant stuff is buried down in the pile of scopes ugh. The relevant diff smells like
This is the relevant diff, but ConstProp is correct here: ( in the original source) is not aliased by anything, 6 can be propagated. Indeed the result with ConstProp is right and without_ is wrong, it actually mitigated a bug further down the pipeline
Slightly edited to make the executed control flow simpler: no loop is taken more than once except for , which executes one line and then returns on the second iteration. <details<summarySee</summary</details
I put this together to look through what LLVM is doing with and without ConstProp enabled:
Regression in nightly-2022-08-13 which was when we did the llvm 15 upgrade
WG-prioritization assigning priority (). Provisionally assigning a P-high priority, will be discussed in the next compiler meeting. label -I-prioritize +P-high +I-compiler-nominated
Note that the compiler is not intended to exploit SB yet so this is still a bug (either in rustc, or in TB failing to represent some UB that we really need).
Since this only happens on low optimization levels, and based on the regression range, looks like an LLVM issue masked by rustc ConstProp? Cc
This version has no UB under Stacked Borrows but still triggers the misoptimisation
I've started to minimize it further: more updates will come later repo:
I don't have a compiled LLVM lying around, could you run your reduction with an LLVM built with ASan? My fuzzer was also running into this segfault , and on this repro when I tried , I would get segfaults if I put the index too low (i.e. disabling too many optimisations!). I have a suspicion that they are related
I don't have an LLVM built with ASan around either right now, but I do have alive2 yelling at me when I feed in a reduced version of this test case. I'll create an issue soon I guess. But I can look into ASan as well.
I checked with ASan and it all looked fine. As backlinked already, I also created an LLVM issue: llvm/llvm-project
The bug has been fixed in assign


<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
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
Regression in nightly-2023-02-05 Regression in cc
Fixed on the latest nightly, marking as E-needs-test labels: +E-needs-test
I don't think this is actually fixed, just that the ICE cannot be triggered currently, but might resurface when the effects feature is fully implemented.


is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself


<!-- 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
cc
This also ICEs on stable with the same error, so I don't think this is related to any of my recent changes at a glance. Having a look at it though
Regression in nightly-2021-09-01 commit[0] 2021-08-30: Auto merge of - sexxi-goose:issue-, r=nikomatsakis commit[1] 2021-08-30: Auto merge of - lcnr:cec-rename, r=oli-obk commit[2] 2021-08-31: Auto merge of - HTG-YT:edition2021-compopt-stabilization, r=m-ou-se commit[3] 2021-08-31: Auto merge of - Aaron1011:guess-foreign-head-span, r=estebank commit[4] 2021-08-31: Auto merge of - sexxi-goose:issue-, r=nikomatsakis commit[5] 2021-08-31: Auto merge of - RalfJung:miri, r=RalfJung commit[6] 2021-08-31: Auto merge of - m-ou-se:rollup-az6xtc5, r=m-ou-se commit[7] 2021-08-31: Auto merge of - m-ou-se:rollup-jeusxbo, r=m-ou-se commit[8] 2021-08-31: Auto merge of - Mark-Simulacrum:fix-rlibs, r=ehuss
I suspect that might be a false positive bisect?
ah meh, probably, if the feature gate was renamed or something, the code with the "new" feature gate might no longer trigger the ice once needed the old feature gate -_-
Bisected to nightly-2022-11-27, probably caused by . <details<summary<codecargo-bisect-rustc</codeoutput </summary</details


<!-- 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
Can be reduced to
Also causes the out of bounds panic (), but not the earlier type mismatch ICE
Triage: Fixed on the latest nightly, marked as E-needs-test labels: +E-needs-test


I tried this code: and I expected to see this happen: All tests passing. No doc tests running when using 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The tests pass for me and they're passing in CI. So I suspect there is something about your system that differs from mine and CI. Can you post the contents of your ?
Also, could you share how these tests are failing? Failing tests usually explain why their stderr differs from expected, or otherwise explain why the test happened to fail.
Hi there, I just did a fresh clone and got the same failures (target x86_64-unknown-linux-gnu). The file has not been changed. The test pass when I used my Mac device. The test each have "The actual stderr differed from the expected stderr." The actual stderr seems to have extra lines " full type name has been written to.." which are not in the expected stderr. Could that be the cause of the failure? If so, what can a fix look like? Full output on terminal:
is your copy of rust cloned into some really deep directory path? like... ? the problem is that your tests are failing because your build is producing type names that hit the length limit and are spilled to disk, and that file limit is dependent (unfortunately) on the path that the rust clone is located at...
we should probably fix this so that UI tests don't spill any long type names to disk by default. We could do this by adding a compiler flag that disables this behavior, and enable that flag by default in the ui testing suite.
this is a great idea — if we do this, we should also remove the code that enables remap-path-prefix in CI.
I can reproduce this locally by cloning under a long path. I would like to work on this. I'll take a look to see if I can identify where we have the logic for spilling the type names to disk, and guard it with a flag. I'll ask questions if I have trouble with that. claim
alternatively, we could gate it under the existing flag
I have code that works for this, but there are some tests under that seem to actually test specifically this behaviour of spilling to disk. So I'm thinking, under we skip spilling to disk, unless there is another flag, enabled, in which case we spill long type names to disk so that logic can be tested as well. Thoughts?
Two examples I found where we are testing the long type name spilling behaviour: with
:+1: this seems good. i would bikeshed the name as and uncouple it from (i.e. compiletest would start passing instead of you changing the behavior of ), but i like the idea :)
I have a pull-request for this, but I'm getting an error in the CI pipeline that I haven't dug too deep into, was wondering if there is a simple explanation for this? Thanks
The pull-request is going through well, but I'm now wondering about this part: Do you mean to basically revert this pull-request:
Pull-request to remove remap-path-prefix code for CI builds:


When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- 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 is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with


This is a regression from
in general the fix for this is usually to add before the line so that they don't overlap
we might want to consider changing to bypass the type-based cache so it catches ordering bugs like this cc
I don't understand how dry run is relevant here, isn't this a problem in all cases? Dry run and real should have roughly the same ensure graph to the extent possible and our tests rely on that... It also seems like based on the linked PR here this assertion is always guaranteed to show up at runtime pretty much constantly anytime someone accidentally adds additional nesting with a group? I could see that the right fix is to track the group and end + restart it so that there's no nesting and instead a linear non-nested list of groups...
dry-run and real have the same problems, yes. my idea was to do extra checks in dry-run so that without arguments would have caught this - the reason it only gets triggered with the filter is because normally, an earlier Step will happen to call , so the dynamic GHA check never gets run. correct. i was hoping that the check was eager enough they'd notice immediately and fix it in order to make CI pass, but this issue shows that it's non-trivial to do so because of the way it depends on the cache. this is how dry-run gets involved - when it's enabled, bypassing the cache is cheap and we can just do it unconditionally, which would have caught this bug before it got merged. hmm, that might handle our current cases ok, but it's not correct in general - consider something like that will split up the single message before and after, which doesn't seem quite right, although i suppose it might be better than panicking?
Ah, I see. I'm not convinced that we'd not stop catching other problems and/or introduce them by changing dry run. The split example you suggest feels right to me - in some sense more right - it means we are putting things in finest granularity groups. It also matches what we do for metrics emission, I believe... I will say that I don't really understand the value in the grouping, so perhaps that would change my thinking there.... At minimum, we might consider not panicking outside of GHA workloads, since the grouping doesn't matter then?


<!-- 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. --: Not posting the entire 1.7K lines backtrace :upsidedownface: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
You can also reproduce this in the rustc repo itself where will encounter the error with
Reduced: label F-typealiasimpl_trait
Found another repro I think: this one bisects to
`
prioritize
going to also link and as other reports of the same issue
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Ok, after a bit more back ond forth , I'm tentatively bumping this issue to P-critical and raise these questions (echoing the comments from the discussion): would it make sense to revert ? cc or would it make sense to revert (which IIUC leaked in the std library an unstable nightly only feature) ? cc Next week Rust 1.72 will be released, artifacts are going to be build real soon, I think. Thanks for additional comments to help improve my understanding of the context here. label -P-medium +P-critical
The underlying issue here is an issue with TAIT. was an implementation-only change simplifying some backtrace code in that was made under the assumption that TAIT was reliable enough to be used inside . As it is not user-facing it should be easily revertible. So the question here is whether it is safer to get TAIT working (potentially by reverting ?) so it can be used internally or to just hold off on using it until the issue has been resolved, reapplying once that happens. I have no compiler experience, but my initial hunch would be that the library change is preferable for now. I'll get a PR ready until tomorrow, unless someone beats me to it.
should not be reverted. All it does is cause us to now eagerly reveal opaques that were being skipped over during normalization, which means that we're just not hitting this code anymore: It does not introduce a bug, it just reveals one that already existed. I'm gonna use the minimized example () here. What's happening here is that we're generating a drop shim for that looks like: which then tries to validate that . However, it has type , where is a , which does not hit the code I linked above. Before , we'd emit something that looks like: which is a field that is incompletely normalized, but does* hit the code above.
Submitted the PR reverting : .
fixes this issue by not considering mir validity on shims until they have been optimized, which uses the reveal-all param-env for that shim. This ICE shouldn't be possible to trigger without , since it has to do with one of the intra-pass mir validations that are only done when that flag is active: I don't personally think that needs to be reverted, either.
This was also possible to trigger even before using an associated type. The test in exercises this too.


<!-- 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
This is not an RPITIT bug, for the record.