<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis is the most minimal example I could find, it needs tokio with the features "macro" and "sync". While this error occured on Nightly I could also reproduce this on stable (as far back as on 1.39, didn't test beyond that because my build started failing because of other reasons) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is very reminiscent of (await in if guard in match statement)
MCVE: Yeah, very .
Thank you for reducing this further. Totally forgot that I could just declare my own async function this way! But I do understand correctly that the linked example is just related, not the same? (Since it's still occuring in latest nightly and the linked issue seemes to be already fixed)
Yeah, just related - my immediate guess is this is some case that was missed in the fix for that issue. The difference appears to be that is used in a index expression after the await instead of some other way.
Another example: Any usage of in the if guard after the that does not cause to be autorefed (like just from the MCVE would) appears to trigger the ICE.
claim
Assigning as and removing .


For example: There are two issues here: actually helpful? All the code runs in the same thread with the same name, so it doesn't add any more info 's no space between the output and the header, so it's hard to read the logs. cc
I believe the crate, which is using, provides methods for and when constructing its layer, so it should be possible to turn this off. I believe the missing space is probably a bug in that crate, so I'd . It's possible this was the intended formatting, you'd probably need to ask to be sure.
Thanks, I'll do that :)


<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: no warning. Instead, this happened: ~The attribute is actually applied correctly, otherwise we would get undefined symbol error.~ Also, the extern variable is clearly declared as static, so the warning does not really make sense. Edit: it seems that the code also works without the attribute. So is the attribute actually not needed? Anyway, the warning about is confusing. This problem occurred in our embedded project , where the static global variables are used to provide references to linker symbols. <!-- 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.47 stable. Haven't tried newer nightly. : modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No, this is working correctly. does nothing on extern items, which already do not get mangled, even without the attribute.
OK, sorry for not understanding the behavior of on extern items.
So maybe this should not be marked as regression, this is just a confusing but indeed correct warning message. Is there a way to remove the labels?
claim


Adding the follow method as part of a benchmark to which exercises results in the following assembly (extracted with objdump): The ghidra decompile for the same function (comments are mine): Note the useless loop. The number of loop iterations (or rather the pointer increments) is needed to calculate the new length of the output . LLVM already manages to hoist but then it fails to eliminate the now-useless loop. The issue does not occur if one uses instead, which always results in length == 0. I tried several variations of the loop (e.g. replacing with a simple ) but it generally results in the same or worse assembly. Note: The assembly looks somewhat different if I but the decrementing loop without side-effect is still there. I assume the differences are due to LTO or some other compiler settings. Tested on commit 2020-11-21 22:46 modify labels: +I-slow
It looks like this can be solved with more ~dakka~ passes. On godbolt it can be made loop-free by adding And branchless with Using as starting point requires the same passes to be to achieve these results, i.e. it does not provide a better baseline. I failed to reproduce this improvement locally but that might be due to argument escaping issues when attempting to put the space-separated list into
Surprisingly targeting a current CPU results in only one extra pass needed to achieve the loop-free result:
Inserting one loop deletion pass directly into also results in the branchless version without having to change target-cpu or adding additional other passes. So I assume that the other passes are only needed due to the way that works.
It looks like that this removed on nightly now. On nightly: On stable:
That's only true for types because I implemented a specialization for that purpose. The suboptimal assembly still exists for types not implementing Copy, e.g. newtypes. I'll update my initial post.
Something that was is that this case also fails for - i.e. with the specialization - is when the wrapper type is
Seems to work in the other direction weirdly is optimised away, whilst is not
Is there a case here that still doesn't optimize? It looks like all the existing godbolt links do.
Looks good, I'll update the existing codegen test.


<!-- 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
It doesn't fixed in rustc 1.52.0-nightly ( 2021-02-14) link to playground : <details<summary<strongBacktrace</strong</summary<p</p</details
i dont think the fix was merged by then. it works in 1.52.0-nightly 2021-02-16 :)


I tried this code: This should give a suggestion to reorder the keywords to , something like: Right now it gives this error, which is not very helpful: Tested on 1.48.0 and 1.50.0-nightly (2020-12-03 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Releasing assignment as I'm not really sure how to fix this at the moment. release-assignment
This could be handled directly in the parser code which generates the above diagnostic.
claim


(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.


Unclear on the extent to which these are the same problem: https://crater- https://crater- cc
The error looks like an old bug that was fixed by
only lists 0.1.0 so we should probably nag about a point release one more time :)
Whoops, looks like I half-fixed it. One of my dependencies is too strict. It does look like the same error so probably not a regression...
cc
and I both feel unclear about this: Is this a Rust regression or a regression in a library that was then picked up by Crater?
This is a regression in the Rust compiler.
The error seems to me like fallout from implementing . I'm guessing the issue is that it's expecting a block but immediately gets a literal. Not sure how this is supposed to behave though. Reposting the error here:
But I'm not quite sure; the span seems potentially wrong.
ping cleanup would be nice to get an MCVE
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Somewhat minimized (): On stable, it produces a bunch of semantic errors (which make sense since I removed a lot of type definitions), but on beta it produces:
Assigning as and removing .
Much more minimized: () Errors:
Here's the code again: I think the issue is that on beta the compiler thinks the in the macro invocation is starting an expression because of the new feature – thus it thinks it's using the first rule in the macro. But then when doing macro expansion, it realizes that it's actually not a valid expression because it's missing braces. On stable this is not an issue because the compiler never thinks that is starting an expression. I think the fix might be to not treat as the start of an expression if it is not immediately followed by braces. See the original PR: . cc who has been implementing
My bisection is in line with my diagnosis: searched nightlies: from nightly-2020-10-15 to nightly-2020-10-19 regressed nightly: nightly-2020-10-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
I'm going to try working on this. If I get stuck I'll release my assignment since this is P-high!
So I'm trying to figure out which code is the culprit here. The PR is the one that introduced the regression, but looking at its changes I don't know if it's actual the underlying cause. I think the issue might be in the macro expansion code, but I'm not familiar with it at all. Since this issue is P-critical and potentially a release blocker, I'm going to release my assignment so that someone more experienced can take it over. Though I'm happy to help if there's some way to do that!
Actually, I just noticed that petrochenkov responded to my message asking for help finding the code
This should be fixed on the next nightly.
Reopening to track beta fix.
Should be backported to beta as part of
I think this can be closed as has been merged?


The rustdoc search results page has three tabs of results: "In Names", "In Parameters", and "In Return Types". In my browser with the default theme, the selected tab heading is drawn in black on black. !
modify labels +T-rustdoc +A-rustdoc-ui +regression-from-stable-to-nightly
Yes, I've been having this too. You beat me to reporting this bug and ; thank you for making good reports!
I did some bisection and it seems the most likely cause is .
Ah, I think I know what the issue is.
Labeled as P-medium since I made the fix and it's in the bors queue.


<!-- 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 steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
Cc for
This will be fixed by .


I haven't been able to minimize this yet. The similar, already resolved, bug report doesn't seem to help - changing the 's return signature from to the full definition doesn't help here. The bug is also present in the nightly build (). <details<summary<strongBacktrace</strong</summary<p</p</details
:
Note the error goes away if you add , or if you change to . So I think the bug is that the trait bound is not being checked. cc
Triage: no change
No longe crashes with master toolchain
Crashing again after
This is also a compiles -ice regression
This never should have passed. Removing regression label; this can remain open to track the ICE.
no longer produces an ICE as of rust 1.81.0


<!-- 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. --code from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis happens since cc
Oh my, I'll fix that now. The syntax is gated but evidently the flag can still reach into the parts which were not completed yet. Update: Ah but I misread the code, this is actually using const generics defaults. They're not done yet, ICE-ing is expected until the feature is completed in . how did you hit that ? Were you trying to use const generics defaults or did the ICE come up unexpectedly ? I can open a PR that will do nothing here instead of ICE-ing.
I made a small program that executes rustc on all the rust files with different flags and filters the ICEs. The file showed up as previously unknown crash.
On nightly-2020-12-31 (commit ), I get a parse error with the code you provided:
Yes, the PR was merged ~7 hours ago, it's not in nightly yet.
Ah, things move fast :) How did you get a build with the commit then? Did you use ?
There are inofficial "master" builds released for every merge commit in the repo (the latest one is then promoted to "nightly" once at some point of the day) You can install them with and run something like or afterwards.
Oh, I forgot about RTIM
will remove the ICE so that only the appears


The "Notable traits" popup for [] shows notable traits for when it should show (or at least ): ! Note that this happens for other functions on . Another example is [] which shows when it should show . I'm not 100% sure this is a bug, but the behavior is definitely confusing: I'm not sure what the notable traits popup is referring to when it references an type parameter ( doesn't even appear in the file that is defined in...). []: []:
I think this is a duplicate of
Hmm, that seems possible. Wow, that issue is so old: it refers to ! Off-topic: is there a way to see what the docs from then look like?
Yes, you can manually type the version number in the URL:
Thanks! I forgot about that. However, I meant for the docs pre-1.0. Do you know of any way to view those?
Followup: 0.11.0 is the earliest version I could find docs for:


A code attached below used to compile with rustc 1.48 (stable) and stopped to work with 1.49 (stable). Two thing help to make the code compile: 1) comment out 2) explicitly deref . To compile code below one need to add to dependencies. Maybe this is due to some conflict between ArcSwap instance method and Access load method? I tried this code: I expected to see this happen: It should compile properly (it worked with rustc version 1.48 and earlier versions as well). Instead, this happened: I got compilation error It most recently worked on: Rust 1.48 :
searched nightlies: from nightly-2020-10-01 to nightly-2020-11-14 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing .
:
The examples now print actionable feedback for the user, in the form of errors complaining about multiple applicable impl's. For example, the now prints: So I think this might just need a regression test. label: E-needs-test


See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:


Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim


Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.


The LLDB provider for hash maps has been broken since . Repro: Run this, notice that it doesn't print any values for the hash map: Using an older version works (1.49 or earler): I don't understand the motivation for , as you can see the older versions are able to display the type. can you clarify what is going on? I did some debugging, and the and values are invalid. Another way to check this is to run the  test. Due to it hasn't been running on CI. It has a check for the following output: But the actual output is:
I checked the issue with two different LLDB: shipped with LLDB built from LLVM 10.0.1 sources with Rust patches by adding the following code to the method: So it seems like the problem only occurs with . Probably this is due to the lack of Rust patches in . AFAIU the Rust patches still have not been to (I remember this related issue ). To fix this problem, the following code should be used insted: I've opened a PR with these changes: However, I believe that should use Rust patches not only to avoid this specific problem but to provide a much better debugging experience, with proper type rendering (e.g. instead of ), some expression evaluation support, and so forth. It is really unfortunate that Rust debugging support is not maintained enough except for some independent forks, for example, and CLion's LLDB.
I may be misunderstanding you, but is just a that runs the system lldb. Building lldb with patches was removed a long time ago (), and I suspect is not coming back in the foreseeable future.
Oh, that's even worse since macOS LLDB has very poor Rust support. I believe that debugging support is crucial for any compiled programming language, surely including Rust. So it would be really great to consider shipping rust-enabled LLDB and, more importantly, to maintain and improve Rust support in both GDB and LLDB.


Hi, When running doc-tests with the latest Nightly on my crate, I get an ICE after the first doc-test is executed twice in a row. The issue does not occur on Stable. The issue seems to be caused when multiple threads are used for doc-tests. The ICE is caused by in . The issue occured on the and targets. Curiously, there are multiple targets on which it does not occur (according to Travic CI builds). The Travis CI build status is available here : . the repo for the ; commit ; either or . The actual number of threads does not seem to matter as long as there is more than one. In my case, specifying was not necessary, since I think the number of threads is determined automatically in this case. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This is now a regression from stable to beta.
Bisection says the regression happened in . label -E-needs-bisection
cc do you have time to take a look?
It seems like the underlying problem is that it’s possible for different tests to collide to the same when macros are involved. Minimal example: /// asserteq!(1, 1); /// /// asserteq!(1, 1); /// Before , this produced and now it panics. We should fix the underlying problem, but a simple band-aid for beta would be to turn the into an . The only side effect would be that we don’t get the benefits of in the presence of these collisions.
I’ve submitted that workaround as .


The following is an attempted minimum reproducible sample that causes ICE. From a few minutes of experimentation, I wasn't able to further minimize the example, but I feel as if it should be possible (perhaps an example can be formed with just an async boundary and a mutex?). <!-- 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. --: Also saw the ICE on nightly, but I can't seem to get my instance of cargo to recognize the 1.52 toolchain. Testing on shows this still is present: The following outputs are the result of building on nightly playgound: <details<summary<strongBacktrace</strong</summary<p</p</details
Smaller:
Relevant code: So I think that just needs to be a .
I've actually been looking to contribute to Rust—would this be a good first issue to tackle?
This would definitely be a good first issue!


After I see this spam in output: As I understand wants to run some third-party tool called (with ), but it actually runs the rustbuild's which doesn't support such command line use. (Also this expensive probing happens unconditionally when running any test, even it is not related to rustdoc.) Originally posted by in
I can't replicate this (specifically, confusing for ) on Linux. is on Windows and I think is too. Can you post what your PATH environment variable is?
Semicolons replaced with newlines for clarity: Interestingly a turns up nothing and attempting to run gives a not found as well. Is this something in the environment created by x.py?
This is indeed Windows only. This is the culprit: On windows, is : so PATH is expanded to include and . The strange thing is tidy isn't in either of those directories :confused: it's in (without ). Hopefully I can change this so that only commands that compiletest runs get this variable set, not compiletest itself. If not, maybe I could just rename the binary.
I think I figured it out. The tidy that's being run is in buildx86_64-pc-windows-msvcstage0-tools-bin, which is the same location as That's how it's finding a tidy without one being anywhere in PATH.


I visited nightly-generated docs, e.g. With the dark and ayu themes, some texts appear black although they shouldn't. This includes: tab buttons in searches ("in names", "in parameters", "in return types") theme selection buttons, including those in the settings page IIRC this wasn't the case yesterday, so this must have regressed in today's nightly (2021-02-26)
I think this might be due to ? cc


While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Caused by :


From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.


<!-- 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 isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).


Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):


Most of the types in are implicitly copyable. This results in some confusing situations and is also incorrect since it's doing non-atomic copies.
I don't think an "atomic copy" is a thing? Since all the atomic operations essentially just work on the pointer, copying an atomic type results in an entire new value, in a new memory location. I'm pretty sure that an "atomic copy" is impossible since it requires a read and then store to 2 separate memory locations. The only thing I can think of is the lack of an atomic load. I'm also not sure that being implicitly copyable is an issue, other the above point, and would prefer to keep this way to be honest. There is no semantic difference between using the types and the methods on them and using the atomic intrinsics directly pointers to the values you want to manipulate. The only real advantage of the atomic types is a nicer API. The way it currently is means that the atomic types are identical (except for ) to their non-atomic counterparts.
It's doing a copy of the value at a memory location that is only accessed through atomics without doing an atomic load. It's not true that they are identical to non-atomic types. They encapsulate a memory location to which they only allow access via atomics - except for this non-atomic load.
would make sense, I think.
Nominating


You can also see a somewhat similar compilation error on Rust Playground . I tried this code: And I get this compilation error: It most recently worked on: rustc 1.53.0-nightly ( 2021-03-26) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bisected: searched nightlies: from nightly-2021-03-01 to nightly-2021-04-28 regressed nightly: nightly-2021-03-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI believe the cause is either or . cc
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium +requires-nightly -regression-from-stable-to-nightly
With removed: Note that removing the feature gate makes it compile and run without a problem.
looks like we aren't normalizing here. That shouldn't happen. is what introduced this but i would expect us to fix this by adding a call to normalize somewhere before creating symbols.
see , should still be fixed :laughing:


Crashes when running . <!-- 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-2020-10-28 between ... Does occur since 1.49 modify labels: A-meta regression-from-stable-to-stable
This is an error-ICE case, with a nice error as well. <details<summaryfull build output</summary</details
modify labels -I-prioritize +P-medium As discussed in the prioritization working group
Minimized
Interesting thing… my minimized example only regresses at ( to ), however I can confirm the regression at ( to ) for the original example. AFAICT possibly .
Ah, that makes sense… the later regression is due to . Using takes it back to .
Edit: Probably not the underlying problem, see comments below.
label -A-meta +A-frontend
Nevermind, further minimization to puts the regression point earlier than .
The (error -error+ICE) regression of the example happens at . cc <details<summaryCompiler output/backtrace</summaryon on (with backtrace)
As a reminder: Please add [both][0] code [snippets][1] as testcases in the final PR. They seem to be triggered differently, therefore it shouldn't hurt to add them both. [0]: [1]:


Given the following code (): The current output is: This is rather confusing. It's not immediately clear what the difference between and this working code is (): Since is accepted, the user might be confused why would be considered a nominal type when isn't. The real reason why is an error is because it is an block for . Ideally the output should look like:
It seems like this only happens with auto traits. Regular traits already emit E0116 in this case (): Note that this still happens with auto traits in the same crate, but in this case wouldn't be applicable (): The diagnostic is still confusing in this case and could be rewritten to explicitly point out that is not allowed. modify labels: +D-confusing +F-auto_traits


Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools


As noted in which tracks the diagnostic issue, the standard library previously accepted code (with differing behavior) on a number of intrinsics with "intended to be const" arguments. Since , though, this code is rejected at compile-time. For example, this compiles on stable but not 1.54 (nightly as of this writing). I think at minimum we need to identify the set of code that changed behaviors and document that in release notes.
cc -- on the point about documenting this change in behavior in the release notes, would you be up for either identifying the set of intrinsics which changed behavior or documenting how to do so?
Looking back at the crater run, we only ran it in mode, which doesn't perform monomorphization. This is the reason why this wasn't caught earlier. The full crater run for beta is currently running, so we should be able to get a clearer picture of the breakage once it is done. Documenting this is difficult: the new behavior affects all intrinsics which use const arguments. A quick grep of stdarch shows 1741 intrinsics, of which about ~150 are stable.
This is in 1.54, not 1.53, so the currently running beta run won't catch anything, right? It may make sense to run a crater on the PR itself, though. It is worrying that so many intrinsics are affected towards a compile-error, vs. e.g. having a warning - perhaps deny-by-default - like clippy's on the atomic Ordering params...
run mode=build-only end= start= name=issue-
:okhand: Experiment created and queued. :mag: You can check out and . :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
The mechanism used to validate the immediates using const generics is: offering the validation feature: a post-monomorphization error while evaluating a forcing the evaluation of the const for the const generic parameters of a given intrinsic: e.g. the above is as and the body of the intrinsic will start with a static assertion ensuring is indeed a 4-bit value. Note that I've linked to the more common macros, but this mechanism is applied throughout including arch-specific intrinsics and validations: e.g. , or . Any intrinsic using these macros can cause an error like in the OP with an argument that doesn't pass the checks, but this set of functions should be equivalent to: all the intrinsics which have been ported to . This means this mechanism is very well centralized and could be deactivated depending on the new crater run results, however that'd mean that we would return to the current situation of, depending on the intrinsics, having assertions or crashes in LLVM instead.
And the move to 'proper' const generics and the new validation are coupled because we would otherwise have undefined behavior (or be unable to codegen? -- what would happen)? Or can we decouple them?
We get LLVM assertion failures if invalid values reach codegen. I'm not sure if decoupling is even possible. For example, these don't work in debug builds:
It might be possible to do something involving specialization on const arguments... that seems rather fragile though. An alternative might be to change the LLVM IR generated by rustc, but it seems like currently rustc has no idea about the structure of these LLVM intrinsics so that probably won't be easy either. How is it then possible that the example in the OP here compiles and runs on stable?
Previously stdarch had massive statements to convert the value to a constant argument for the intrinsic.
:construction: Experiment is now running :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:rotatinglight: Experiment has encountered an error: command failed: exit code: 1 :hammerandwrench: If the error is fixed use the command. :sos: Can someone from the infra team check in on this? :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
retry
:hammerandwrench: Experiment queued again. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:construction: Experiment is now running :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:rotatinglight: Experiment has encountered an error: command failed: exit code: 1 :hammerandwrench: If the error is fixed use the command. :sos: Can someone from the infra team check in on this? :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
edit end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master# name=issue-
:rotatinglight: Error: failed to parse the command :sos: If you have any trouble with Crater please ping ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
name=issue- end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master#
:rotatinglight: Error: it's only possible to edit queued experiments :sos: If you have any trouble with Crater please ping ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
retry
:hammerandwrench: Experiment queued again. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
name=issue- end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master#
:memo: Configuration of the experiment changed. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:construction: Experiment is now running :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:tada: Experiment is completed! :barchart: 56 regressed and 14 fixed ( total) :newspaper: . :warning: If you notice any spurious failure ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
All of the new failures that weren't in the previous report seem to come from , which is already fixed.
And it seems it's only 2 new crates that depend on this version of . So while post-monomorphization errors are tough errors to trigger and find consistently, the results are at least encouraging. It can also be noted that the rough "evaluation of constant failed" error in the OP, has since improved on nightly, to somewhat acceptable levels. <details<summaryHere's how it looks now</summary</detailsAnd could be improved still if we, for example, specialized in the handful of actually used widths. It would allow mentioning the range bounds in the error message (or we could do some of the const fn string formatting hacks here of course).
Closing as working as intended. The error message has been improved, and a description of the potential breakage will be included in the 1.54 release notes ().


<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since i don't know which version, when running on a project, the left sidebar of the docs no longer has a nav for all crates in the dependency graph. However, the documentation for all dependencies is still compiled. a Rust project with a few dependencies. : Left sidebar has a list of all dependencies, linking to each crate's local docs. : No such thing. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: I honestly don't remember. I update my nightly before every dev session. Allegedly that bug is 27 days old. <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Appears to be a regression from , the call to was moved into , but this function is not called on the crate-root doc page. I tested locally that it fails on and works on .
Checking looks like this has made it onto the 1.53 beta.
cc
I think the ideal fix is around We should emit a sidebar- for the top page that just calls . And remove that comment, since we now have dynamic crate loading. A quicker fix is to just move the call to addSidebarCrates so it gets called independently from initSidebarItems. I like that less since the crates really are a sidebar item and should be treated as such.
I can do that if no one else wants to do it!
Go for it! I'm happy to review.
Assigning .
It's actually something I fixed in (still waiting for approval/review).
I propose we plan on landing and backporting to fix the regression: it's much smaller and limited to the specific fix. Then we can work on landing in nightly.
No, the approach taken in is problematic. The information is already there and we don't need this new file. EDIT: also, is ready, there is a debate for the other part of the PR (the change on module's sidebar) which I can move to another PR.
See - after some discussion, and concluded to merge as our quick fix. To explain why I proposed to add a tiny sidebar- We have one that's loaded by a variety of different pages. It also potentially has many different entry points. For instance, the primary entry point is that when itself is loaded, it runs various functions, adding event handlers and so on. Another entry point is that when sidebar- loads, it calls . That's the root cause of this bug - code in expected would get called, and for a subset of pages it wasn't. It's a bit inelegant to have a small file whose purpose is only to call a known function. But I think that inelegance is balanced against the improved maintainability of having most doc pages follow closer to the same code path through The more code paths, the more chances for bugs and the more complexity in testing. Another way to address this longer-term would be to eliminate the entrypoint entirely. Instead, when runs, it would trigger the load of sidebar-items and run any callbacks based on that load. Yet another way to address this would be to separate out from , so that is called unconditionally for all pages.


<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this: (at ) windows-gnu nightly: wasm target: the package for : Result: The invokes . depends on that is not present in the distribution. If I add it manually, the issue goes away. The flavor ships with that does not have this dependency. and (and likely everything between)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low +T-compiler +O-windows Edit: my assessment was wrong, this requires more prompt attention label -P-low +P-high
I have the same issue with "stable" rust 1.52.1 ( 2021-05-09) on Windows 10 with a wasm32-unknown-unknown target. Can you elaborate on how to quick-fix this by adding manually? Where can I get, and where do I put I only have from Mingw64, Mingw32, and many other SW packages. Is it the same? Btw. what hit me instantly is the move from LLVM 11 to 12. Might that be the issue?
Yes, at least enough so it works for me. Just rename any zlib binary, the library interface has been stable for a very long time, so it should just work. Or, if you are ok with using binaries received from strangers, take this: . When you have , you need to make it visible. Either place it in any location visible in environment variable, or place it next to the . For me it is located in . See if you want in-depth explanation where the Windows looks for the DLLs.
It works, thanks a lot. It was a bit confusing that I don't have rust-lld in the wasm target folder. Now I can work on my fullstack project again without worrying about OS specific issues :-)


I tried this code through miri: I expected to see this happen: No observable behaviour, including from miri (aside from "Unsupported Operation" errors). Instead, this happened: reports undefined behaviour in "Destroying locked mutex" when calling (Note: this report is correct, calling on a locked mutex is prescribed to be undefined behaviour by POSIX) This was tested on all latest versions of rustc, all using miri 0.1.54, on <details<summaryMiri Backtrace</summary<p</p</detailsThis is caused by issue presented in . However, I believe that it deserves new attention given that it causes miri to fail in safe code (and is not a miri false positive, as miri is correctly reporting undefined behaviour in calling ).
Assigning a priority according to the and removing . modify labels +P-high -I-prioritize
Well, Miri is just a tool to detect issues like this. It looks like back then the decision was made to ignore what POSIX says and instead to rely on what certain implementations do. Since Miri checks POSIX compliance as strictly as it can, this leads to Miri errors in safe code. Ideally we'd work towards getting the spec changed (there seems to be no good reason for this UB, and without something like Rust it is unclear why anyone in reasonable code would even want to do this). That's probably very hard though. Are there work-arounds where we can avoid calling when the lock is still held? Seems hard to do that atomically...
Indeed. And, as I've mentioned in the thread, I wouldn't consider this a bug in miri, for precisely that reason. One half of it could be destroying it potentially concurrent to it becoming locked, since destruction is presumably not atomic, though this wouldn't be an issue for rust. Another reasonable possibility would be for enhanced implementations that, for example, check and trap deadlocks, but as a consequence, couldn't permit being destroyed while locked (the issue was discussed somewhat on the Rust Community Discord, in the #black-magic channel, and this was one potential reason for the POSIX UB). I've actually considered this previously for my implementation, and that's really the only option to avoid strict UB, without fixing the spec (which will take some time, though I don't know how much). Since the destructor is &mut self, it doesn't need to be atomic. It could just be an AtomicBool (or any other atomic, possibly AtomicPtr, which IIRC is the only atomic dependency in libstd) that gets set on being locked, and cleared on unlock.
We could , and if we successfully acquire the lock, do and . If we couldn't acquire the lock, just leak...
I was about to ask what if someone else acquires the lock again just after we ... but that cannot happen since we have here. So, yeah, that could work.
Posix says it's UB to call that function on a different thread than the one that locked the mutex, so that wouldn't work, unfortunately.
I assume that was in the case that successfully called , so it's being unlocked on the thread that locked it.
Oh, right. I misread the comment. :) Then the only question that remains is whether it's okay to not call but still drop/reuse the memory. Without calling destroy, pthread doesn't know that memory is no longer a mutex it is managing. If it has some kind of linked list of mutexes or something, that could result in UB.
It probably has to be properly leaked. I would assume that the raw mutex needs to be properly treated as ned.
We can leak the box or drop the box depending on whether it's UB or not.
We have to leak the box.
A more extreme option is to get rid of pthread mutexes entirely. (So, implement our mutex/rwlock/condvars directly using atomics and platform-specific syscalls, like we already do for on most platforms.) That's still somewhere on my to do list. ^^'
You mean like (not sure if there's an issue for that)?
Yeah, either parking_lot, or something other thread parker based, or maybe something not thread parker based but directly using a futex (or whatever the platform supports) might be a better fit for std. It's a bit tricky to make those trade offs for all std users at once, but not having to deal with all this pthread stuff (and not having to Box them, etc.) would be very nice.
Lowering priority to P-medium because of the previous discussion in .
I honestly think this is the only reasonable solution. POSIX’s semantics are not a good fit for us.
We discussed this in a recent library team meeting, and we'll be going forward with this.
Yay!!! That gives Rust an opportunity to have better performance than pthreads, too. The one caveat is robust mutexes, but I don’t think Rust needs those.
That effort is now tracked here:
This has been fixed on Linux. We no longer use pthread locks on Linux. :)


is not updated (line 1636) when (line 1623) panics. This lets 's implementation to retain the already dropped element. The bug was introduced in and affects stable Rust versions = 1.52. Here is the that demonstrates the double free without using unsafe Rust 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. --:
label regression-from-stable-to-stable
Assigning as discussed by and removing . modify labels +P-critical -I-prioritize
Interestingly there was a test for this, but it is wrong. The vec contains the index=5, even though it is the item that panics in its drop implementation. I guess the author of this test thought that returned the new value instead of the old value?
Learning about a double-free I introduced, a year later... :eyes: And honestly, I can clearly remember that when the test was first written, it caught the bug, but I just assumed it was an off-by-one error in the testing code itself, yikes


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!


<!-- 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: Compiling with , after the emsdk is activated and emcc works, to compile properly Instead, this happened: Prints this error: I've tried adding to no avail <!-- 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
runs successfully
Also is broken on ubuntu with the same error message (at least windows subsystem for linux)
rustc 1.53.0-nightly ( 2021-04-24) emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 2.0.12 () Here's some info I gathered: Rust tries to . I think Rust is assuming that this symbol comes from emscripten. emscripten has a : libc++abi.a: emscripten exceptions: this is what rustc is trying to use; libc++abi-noexcept.a: no exceptions: does not compile libc++abi-except.a: wasm exceptions: experimental; in emscripten's repo shows that was never compiled into libc++abi.a by This commit looks suspicious: Prior to emscripten SDK version 2.0.10, I think has been and never did anything. Rust probably shouldn't be calling a stubbed function. seems untested if you ask me because I don't know how it could ever have worked. I successfully compiled hello world with emscripten SDK version 2.0.9. That version still has the stub.
label I-prioritize T-compiler O-wasm
thanks for the analysis. Assigning priority as discussed in the of the Prioritization Working Group. Let's find someone who can have a look at this. label -I-prioritize +P-high +I-nominated
I recall with the LLVM 11 upgrade, the compat notes mentioned which version of Emscripten to use when compiling with the target. Once this bug is resolved, can we add a similar note for the releases that upgrade Rust to LLVM 12?
As mentioned the panic=unwind strategy is broken on wasm32-unknown-emscripten. I recommend to switch default to panic=abort. Note that also rust std lib has to be rebuilt with panic=abort to fix the undefined symbol errors. Testing on my side showed that the problem could be fixed by changing TargetOptions on line 38 to "panicstrategy: PanicStrategy::Abort," in file. Unfortunatelly I do not have experience in preparing pull request and have no capacity to get into it now.
This issue can be solved by setting the env var which will override any flags passed to emcc. See this comment - Passing these flags using the won't work, as they are not passed to the linker. I received this error in two places, one for symbol and one for , hence the flag.
Reported this on Emscripten:


Look at this iterator. We all know that when ’s resulting implements , then the side-effects can be re-ordered. However, judging by the implementation of one would probably at least expect that it’s impossible to hit the without first either going through at least or first. Right? Well, here we go! on beta on stable 1.52.0 () label T-libs-impl, A-iterators, A-specialization, regression-from-stable-to-beta
cc
~As mentioned in the other issue, I think this is just another instance of ~ Edit: Nevermind, not really since it doesn't involve calling on Zip, rather this is about use of in Zip.
It’s related to . I guess the “random” aspect of is a bit weird for iterators like . You can do the same thing (accessing the from the center without “walking” there) with only, too, on stable already like so: <hrThis issue is only “really” a regression if out-of-order side-effects for iterators aren’t wanted.
steffahn brought up some general concerns about the implemention on () in I'll have to think some more about whether combining Take, TRA and backwards iteration is even doing the right thing under all circumstances, beyond the side-effects issue raised here. I am generally in favor of eliminating iterator side-effects that are not necessary to produce the final results. But of course that's currently undocumented and possibly surprising behavior and needs to be approved by the libs team, which hasn't happened so far. So while I like what it does it shouldn't have landed without discussion. I don't think so? At least that would be another implementation gap. That's what the whole thing is supposed to prevent. Oh, sure, that definitely is
https://rust- I'll submit a revert PR.


With on , will not drop the inside , just like does not drop the original before overwriting it. However, a manual implementation of can only make use of the efficiency of a overriden on (e.g. memory reuse by a ) by simply forwarding to it, which means that will not forget the old value. This new (forwarding, so (potentially) dropping) behaviour was in , and (for now) reverted in So question for What behaviour would be correct? There are arguments for both. Whatever the decision, we should document it and add a test for it.
I feel that the old behavior is correct (not calling drop). should behave like which for means not dropping the old value. I don't think there is much loss of efficiency in practice: use of is already pretty rare and I don't think there are any cases of it being used with .
Sounds good. Closing this.
No wait, we still need to do this part. :)


has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.


I'm not sure if this change is intentional or not, but I thought it's worth reporting in case it's a bug. ! !
cc Was this change intentional?
I don't think so!
We found it out with and we weren't sure whether it was good or not (from a "look" point of view) and simply decided to wait and see if people liked it or not. So, should we revert it or not? :)
As a random person on the internet, I prefer the old look better. Although I admit that's at least partially due to familiarity with it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I would revert it
I'll change the look then.
I think I might like the new look better, but it's a slight preference and I seem to be outvoted. :)
I don't think we should be changing the UI by accident. I'm open to a discussion in changing it, but it shouldn't have changed without a discussion, so we should change it back in the meantime.
Agreed. I'll send a fix in the next two days.


<!-- 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. --Regarding a minimal example I am afraid I'm not quite able to provide one, this bug occured when i was migrating to Rust 2021 as part of the testing efforts. The branch/PR with the Rust 2021 modifications can be found here I did cfgment all modules except the ones that are required to trigger the bug out: And removed most code and modules from the rcc module: , nailing the bug down to (as the error message suggested). Then i minized further in (its 200 lines now, the rest is just tests) And I was in fact able to pin point the panic to this piece of code: , if I comment it out the ICE doesn't occur anymore so I would guess that this is what the compiler is having issues with. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Compilation command I used was: <!-- 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 --
Thanks for the report! Here's a somewhat minimized reproduction:
cc
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
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly


<!-- 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. --When trying to compile this incorrect code using cargo, nightly rustc panics. When compiling using rustc directly without further arguments (or using the same command cargo calls with removed), it outputs an error message instead. I also noticed that changing to will also result in an error message instead of a panic. <!-- 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
I seem to have run into the same issue with this code: <details<summaryBacktrace</summary</details
I believe these ICEs trigger because of / are made visible by cc
I'm not able to repro this with rustc 1.56.0-nightly ( 2021-08-02): Could you verify that you see it with a recent nightly? There have been significant changes in this area recently. Edit: ah! with enabled I see it:
I am able to reproduce my issue and the other one on by simply running :


The following ICE was found migrating 0.26.0 and  0.4.38. cc which was an error on the same line, though I think the cause is slightly different. Note that I think this is also triggering an incorrect lint for the parameter (the actual code uses the parameter). <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


The following is minimized from , which is regressed as of nightly-2021-08-15.
Relevant commit range is Of the 9 landed PRs, the ones that look potentially relevant to codegen are and .
I tried all the merge commits in order of merge: : pass : pass : pass : pass : pass : pass : pass : pass : regressed so that narrows this down to (
This passes under Miri, so I suspect that we've exposed an LLVM bug.
Not sure it's an LLVM bug because it seems the IR is broken even before any LLVM passes. I tried: Before: After: Diff: The looks like legitimately broken input IR. Notice the extractvalue insts relocated from the front of bb4 to the end of bb0 (invalidly after the terminator). What in LLVM is actually running during a -Cno-prepopulate-passes build?
I think we should do a quick revert and then figure this out without any pressure
the mir changes are that seems totally reasonable, so we need to check what codegen_llvm makes of it
I wonder why the goto collapse only happens if the zst assignment is eliminated. it seems like we need to preserve bb4 in mir or inject it in codegen_llvm, but first we should find out why the goto collapse is happening at all
There are no control-flow simplification passes after removal of dead local variables, which is why it didn't happen so far. Still, it seems a bit surprising it wasn't reported earlier: Adding a new cleanup pass before codegen would be one way to address this.
I swear half of my PRs break the compiler I'm excited for what bugs arise when we start using undef for uninitialized consts... Revert PR:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
The issue was not fixed, it is an LLVM crash on stable as shows
Relabeling regression because worked in 1.51.0. It bisects to nightly-2021-03-02 ().
is the only codegen change in that nightly.
Reopening to track the stable-to-stable regression.
Backport was merged.


fixed but this issue still fails: Found trying to migrate . Let me know if you need any more information. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign
The culprit is
Let me know how I can provide assistance on this one
label +A-closures +A-edition-2021 +T-compiler +I-ICE
claim
This seems like a similar problem as . We end up at a point where we to determine type of a variable and end up returning early without possibly capturing.
release-assignment
claim
Reopening -- I was able to trigger this on rustc_errors: Going to try to minify...
Triggers with the following (rustc --edition=2021), both on beta and nightly. I think this requires if let guards, though.
We ICE after attempting to resolve the for here: I believe we recently the option to have in pattern matching arms, but we never consumed the expression when "visiting" the arm leading us to not "read" and hence not being able to resolve it. cc:


Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low


<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case


<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)


<!-- 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. --When compiling on an Apple M1 processor: <!-- 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 also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Test failures are fixed in rust-lang/miri; all this needs is a submodule sync.


The test fails due to an arithmetic overflow when debug assertions are enabled. The offending code likely intends to use the explicit wrapping math methods, as the test does pass with the overflow. The test was implemented in <details<summaryBacktrace</summary<p</p</details
The overflowing code is To me, it actually seems like the overflow might be a bug. it looks like you this code. Is it incorrect for it to be overflowing?
This is introduced in with guards like near call-site. So I suppose just swapping the order should be sufficient?
Overflowing here is a bug. Given that we haven't seen an index out of bound panics on like 562, I would guess that the actual logic here is correct (so, we underflow, then overflow). I do want to prove to myself that again (and put it in a comment).
If it is really intended then should be used.
Oh, I think I ran into this as well and thought it was due to a local change I had made violating an invariant.
Duplicate of ?
no, that issue is in diagnostics, while this one is in trait resolution. I'll try to get to the diagnostics issue next week
label -I-prioritize
Ah my bad, thanks. I think I've been running in to both issues and conflating them.


removed from to make it : We can't do these checks at compile-time, since , for example, involves ptr-int cast to check the alignment: So, as the FIXME suggests, we should enable the checks only at runtime. Recently intrinsic , it allows for exactly this use case - running different code in CTFE and runtime. cc and (it seems like use of requires approval of all of the above teams) label +T-lang +T-libs +A-const-eval +A-const-fn <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Did you intend to nominate this for lang, or for libs?
kinda both: lang: for whether constevalselect is ok in general libs: whether we should start using it in stable const fn
As the assigned reviewer on , and per some of the discussion in today's T-libs meeting, it feels like it would be good to have a more thorough writeup from or someone else on wg-const-eval about what is being asked here. In particular, "lang: for whether constevalselect is ok in general" seems like a question best asked with a considerable amount of context lacking in this issue, perhaps even RFC-like text targeted at the T-lang audience. While I'm not on T-lang, I definitely couldn't make a decision without that document on what the requirements for its usage should be, and this currently doesn't place it into that context. It also seems like the question is better suited to a tracking issue (or perhaps ideally the PR adding it, rather than this issue), but that's a separate question. I imagine a similar level of context would be helpful on the libs side as well, but again, not on that team either.
Thanks for the very kind way of informing me that I was writing useless comments again. I should know better, I do know better, but idk... Anyway: The intrinsic (initially considered as a solution to , but also useful in several other situations), allows calling one of two different functions, where the function is chosen depending on whether we are const evaluating or not. This allows you to write code that behaves differently between runtime and compile-time, and we have no way of checking whether that happened. You are not allowed to use the intrinsic to actually do that though. Both code paths should behave exactly the same, but you may make the const-eval path slower or otherwise different so that it can actually be const evaluated, without losing runtime performance. Notable examples of where it would be ok to use them as far as is concerned: implementing SIMD or platform intrinsics, where the const-eval part is just a slow, pure-Rust version of the same logic skipping pointer alignment or other pointer math checks that are going to get checked by the const eval machinery anyway unsure yet: avoiding debug! and dbg! statements at compile-time (or having a different mechanism entirely for reporting them) There are no plans to expose such behaviour to users at present, this is solely for libstd/libcore implementations. The intrinsic itself (from a runtime perspective) is a trivial type-safe function and completely written in safe Rust code. Its sole magicness comes from being a lang-item that const evaluation intercepts and then chooses to behave differently on. The intrinsic is documented at Do we want to use such behaviour in an easily accessible way in std? Up to now we hid each such case behind a custom intrinsic for just that specific case. Now we have a generic mean to do so. Furthermore, but not relevant this issue, we could in the future, instead of implementing intrinsics like in CTFE wrap it in and have const path execute a regular checked division. Similar changes may simplify the CTFE machinery by transferring some of its logic into libcore Assuming T-lang has no concerns, are you willing to stabilize some const fns that are impossible to stabilize without this. The main concern is that if we ever want to back out of , doing so may require significant work in the CTFE machinery (per function using ) in order to actually remove .
Correction: the const eval machinery does not do pointer alignment checks (Cc ). But if those checks are optional anyway (as is the case here, since these used to be debug assertions), then that is okay.
Note that this does not really save code, since Miri still needs to implement the intrinsics (it will run the run-time path, not the compile-time path). So I am not sure I like this proposal -- having the intrinsic shared between CTFE and Miri gives a lot of coverage to the Miri core engine intrinsic implementation that we would not otherwise get. These comments would probably better fit some consteval_select tracking issue though?
We discussed this in today's meeting. We don't have any issue with adding these checks to or . Also, as general guidance, nobody in the lang team meeting felt that non-observable uses of in this style need direct lang team review. We'd like to see such usages CCed to for review, and cases that wg-const-eval thinks are fine (such as the three "invisible" cases in comment above) seem fine and entirely in the libs domain.
We discussed your question in the libs meeting just now. We're happy with 'low risk' usages of this intrinsic in the standard library, even in stable functions. What counts as 'low risk' we'll leave up to since y'all can best judge what the alternative would look like if would have to be removed.


<!-- 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. --: Also checked beta and nightly at : <!-- 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 --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.


Tracking issue: . The assembler directive allows to treat data as instructions. This allows to generate CPU instructions that are otherwise not possible using assembler commands. It is platform specific and mostly relevant for RISC-V platforms, but I could also find uses for it on MIPS targets as well. More generally speaking, any solution that allows me to produce custom machine code instructions without a performance overhead will be okay for me. The current best workaround is to write the assembler code externally and then link to it. However, this adds the overhead of a function call that cannot be inlined due to the FFI boundary, so this is not acceptable in the long term. See also for some more discussion of my problem.
This will likely work automatically once LLVM supports it. A commit has recently landed () but is not yet in any released version.
label +A-inline-assembly +F-asm
I tried building rust+cargo from source with cherry-picked. Sadly it did not make the error message go away. A good way to check is to use on a minimal example instead. Turns out that I somehow wasn't.
Okay, it actually does work. What is the procedure around Rust's LLVM dependency? How often is it bumped? Is this a candidate for cherry-picking onto rust-llvm?
LLVM procedure is at https://rustc-dev- I think this is a candidate for cherry-picking but someone needs to do the work.


I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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
Seems related to


I tried this code: I expected to see this happen: The documentation is empty. 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. --: rustdoc 1.58.0-nightly ( 2021-11-12) cc I suspect this is related to one of your recent changes to visibility.
This does appear to have been . I'm not entirely sure how to fix this. Basically, what's happening here is that the query is checking if the use statement is accessible from its parent module. It is, because the parent module of the top level of the module is itself. Before this, it would have been documented if you did a , but not with just . The new behavior is more consistent, and better in that sense, but perhaps not ideal. Do you have an idea on how you'd like this to work?
Some additional thoughts: If we want to stick to the "visible from parent module" thing, the simplest way to do that would be to add a check for whether is the top level module. Of course, I'd also have to add a check for the visibility being actually public... sighs. Might need to break this into a seperate thing. I guess the problem I'm struggling with after thinking about all of this is that I don't fully understand the justification for all of this logic. Why is it that we want to show some imports but not others? If these were structs, we'd just show all of them, regardless of their visibility. That said, if this really is the behavior we want, it shouldn't be hard to implement.
I think we should inline neither nor bare (pretty sure I said so on the PR, but I guess I forgot to check for a test case). Because the structs are only visible from the module where they're defined. The use statements aren't intended to be used from elsewhere in the crate.
I think I explained this poorly above. We generally don't inline either or bare . Not doing so is the intended behavior from the PR. Because of how I implemented it, the top of the crate ended up being an inadvertent exception, and we didn't have any tests that covered the top of the crate as opposed to lower level modules. It's an easy fix if we want it not to be an exception, I was just trying to make sure we had a clear philosophical reason for wanting things to be the way we were trying to have them be. (In other words, I was double-checking that the behavior the PR was supposed to create is really what we want before submitting a PR to do that.) It sounds like it is, so I'll get working on a bugfix. I feel like I'm expressing myself rather unclearly at the moment. If there's anything I need to clear up about this explanation, please feel free to let me know.
Oh oops, I missed this bit. Yes, I think this should be consistent with the submodules of the crate.
I agree, that sounds like the right behavior to me.
Quick update: I've got a substantive patch, but it's taking a while to get the tests to a point where I'm satisfied with them.
My PR is up! Also, I'm going to assign this as a , per the discussion in of the prioritization working group.


Source: It is worth noting that this code should not compile. This bug occurs in both beta and nightly. : <details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since


An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue:


<!-- 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 a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .


Repro steps: create a new cargo binary with . Replace with the following code. Then run . Hope this is helpful! I've tried to minimize the code as much as possible. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The same issue happens in the latest nightly as well.
This bisects to nightly-2021-06-25. Commit range: It only reproduces with , not , which means bisecting to the old nightly needs in In that range, looks the most relevant because it is the only thing introducing edition-specific behavior, and it's dealing with closure capture and the presence of a closure appears necessary in the minimal repro. would you be interested in taking a look?
For comparison, the same code with doesn't emit a compiler error and has a bit more info:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
In both and , function returns value every time but somehow in value unwraps into error, even though it's This is the returned value:
Triage: This is no longer ICE with the latest nightly, since (presumably ). Marked as .


Error is with genericconstexprs : <!-- 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 --
I actually hit this same issue with capturing un-normalized types in generator interiors when playing around with . I think I know a fix. claim


The section of the Manual would benefit from some code examples, especially those that clarify how traits and impls interact with the new name. I find the term "type definition" confusing because this section seems to be describing what I think of as "type aliases". Aren't and also examples of "type definitions"? If so, is it worth changing this terminology?
Here are some relevant thanks to
cc
Yeah, I'm not sure what the right terminology is here. Hmm.
what do you think?
+1 for "type alias" -- much clearer.


<!-- 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. --With the experimental feature (), there's a compiler issue that surfaces during documentation generation but not a regular build. In the code example below, produces an unhelpful error message. <!-- 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 error on running is: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Isn't it the same as ?
No, I don't think so, that initial instance did not require to be enabled (we controlled for that variable using ).
looks fixed to me, marking as needs-test


Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax


<!-- 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. --Please clone and build it. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This is a new incremental compilation issue, distinct from the previous 'called Option::unwrap' issues. cc
Thanks for the great reproducer - I was able to reproduce this by first building commit , then building commit
This is caused by the way that we handle (which is an anon dep-node). The current query system is set up so that we will never try to force a query with a stale . Normally, the only way of invoking a query with a is to obtain that from another query result, or to receive that as part of the query argument. If a query 'A' obtains a by invoking another query 'B', then removing the corresponding definition from the crate will change the result of query 'B', causing it to be marked red. When we try to mark query 'A' as green, we will see the red dependency 'B' and bail out, before we ever attempt to force another query with the stale that we saved from the previous compilation session. When we actually invoke a query during the execution of some query's body, we will try to find a matching from the previous compilation session. If the input to the invoked query contains a (e.g. as part of the inside of a ), then a change to the will cause us to compute a different hash for the query input. As a result, we will never try to load the depnode from a previous session, since we will not find a node with a matching hash. However, anon dep nodes break this assumption. Specifically, when we create a , we invoke queries like using s taken from the surrounding . From the perspective of the query system, these s are essentially pulled out of thin air - the query system sees as having no input. Specifically, we call: Inside a (recursive) call to , we may call queries with s obtained from the predicate - for example, to look up constituent types for auto trait impls. As a result, trying to mark a node green can cause us to try to force a query with a stale , since our edges vec will not contain a dependency on a query used to produce the to begin with. With normal non-anon nodes, the dependency on a particular will always be explicitly carried through the graph of query invocations - either being forwarded through a query argument (thus affecting the hash), or by using the result of another query. The fact that we will never legitimately try to force a stale has helped us find bugs (e.g. ), so I think it would be unfortunate if we had to start silently ignoring the forcing of a stale . I'll need to think about how we can adjust anon dep nodes to fix this issue. Ideally, we would just remove the concept of anon dep nodes entirely - however, I'm pretty sure that it's the only way to make the global evaluation cache work with incremental compilation.
I've determined the root cause of the issue - we're failing to keep track of the created when using the provisional cache. When evaluation finishes 'normally', we store the created anon depnode into the evaluation cache: When we later read from the evaluation cache, we will generate a read of that : This ensures that any queries using a cached result will still get all of the dependency edges created during the initial uncached execution (e.g. a call to when determining constituent types). However, when we store a result in the provisional cache (due to an auto-trait cycle), we don't store the generated : When we later move entires from the provisional cache to the 'real' evaluation cache, we insert them using a different : In the provided reproducer, we first store in the provisional cache, and then move it to the 'real' evaluation cache. This means that any queries using the cached result of evaluating (e.g. a call to ) will not get dependency edges for any queries invoked during the initial 'provisional' evaluation of the predicate. In particular, we will not get the edge to , which has a changed result between the two compilation sessions. I've confirmed that storing the provisional result into the evaluation cache using its original fixes the ICE. However, I need to do some more investigation - I think we may need to combine both 's to ensure that we don't miss any edges.
Minimal reproduction script: : : produces:


: <details<summary<strongBacktrace</strong</summary<p</p</details
this is not exactly ICE, but I did not find an appropriate variant for this
label -I-ICE +I-crash
searched nightlies: from nightly-2021-12-01 to nightly-2022-01-18 regressed nightly: nightly-2021-12-06 searched commits: from to regressed commit: cc
Looks like a stack overflow in . Needs a call to somewhere, probably at the end of around , although there might be a better spot. This will have perf implications, however.
Fixed by , marking as E-needs-test.


(desktop) Safari the search box here: a letter the letter another letter how the empty space below the search bar changes size cc – I think this is a recent regression; it's in nightly. I presume it has some connection to either your "All crates" change or your sidebar change. This bug is not present in beta.
Hm, I can't reproduce on desktop Safari 15.1. Can you share a video? I can observe a small change in the width of the sidebar between typing a letter and deleting. I'll investigate that.
I'm on Safari 15.2, though I'm not sure if it matters. I'll see if I can get a video sometime soon but I'm a bit busy right now.
https://user-
Thanks!
Thanks for the video that really helped me figure out what I was looking for. I was able to bisect it to (moving the crate dropdown onto the search page). Surprisingly, the minimum diff that causes the issue was not any of the CSS, but removing the dropdown element. So long as the search input has a previous sibling of any kind, the bumpiness does not happen. It's quite mysterious. I haven't been able to find a style that causes this.


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: intradoc links for the block residing in (where is not defined) are valid links. Instead, this happened: Rustdoc thinks that , resolved to , is not in scope here: A workaround is to make sure that , without prefix, is in scope: In other words, it seems that in intradoc links resolve to the name of the item, not the full path? <!-- 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'll see if I can look into this. If someone else wants to work on it, feel free to claim it from me!
This appears to have since been fixed, probably by .
Actually, it'd probably be good to add a test for this.
Thanks! That looks to already have trickled down into recent stable rust releases, as I can't reproduce it with . Awesome!


Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim


<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This code panics on Windows: According to the documentation for , it should either succeed or return . Instead, it panics due to an out-of-range index: <!-- 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 bug is also present in nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I can confirm this. The problem originates in . A minimal example:
It seems that the in causes the issue, I'll try to fix.
claim