jiebi/CodeConvo huggingface dataset:
<!-- 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: I expected that the help text would give syntactically correct code, or that there would be no help text. Instead, this happened: The provided code snippet is not valid - it tries to deference the else-block, which is impossible. Better would be to put the inside the else-block. <!-- 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 occurs on stable, 1.50.0. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I have a fix for this bug + an improvement. Gotta got for now but will submit the PR later today.
The following minimal example causes an internal compiler error. Error in question: rustc version: This error was encountered on stable, but I can confirm that it also occurs on the latest nightly ().
Hasn't the feature gate issue been fixed? :|
I've removed the nomination and this to the tracking issue for GATs . The current impl is highly incomplete and ICEs are, sadly, expected. Also, I verified that a feature gate is indeed required.
triage: P-medium
I don't know if I get you wrong, but the example above ICEs on stable, beta and nightly without feature gate
oops, looks like I accidentally left the feature gate in there when I tried it out, but it produces the same ICE when it is omitted as well.
No, niko edited your question. ping I think you got something wrong there. Can you please clarify that?
Oh, I guess I was indeed incorreect. I tried it on play but didn't notice that, after the "correct" error, it goes on to print an ICE.
What about adding the I-nominated tag again?
I'm not sure why we would nominate this for discussion. Yes, it is an ICE (and an ICE that occurs without the user adding a feature gate), but the message pretty clearly states that you're using an unstable feature. It would be great to fix it so that it issues the error diagnostic without ICEing, but I wouldn't re-prioritize that work above P-medium.
assigning to self since its a clear annoyance
triage: P-medium. (dupe of )
(the remaining bug, when the feature gate is enabled, is tracked in issue )
I tried this code, sorting 30 million random : On this machine: Using the vendored version of from mid 2022 see here I expected to see this happen: Runtime ~1.45s Instead, this happened: Runtime ~2s I bisected the issue down to with . The same happens if you do instead of . So this also affects the current implementation which is very similar to my vendored version.
Dinging into it, I think the relevant code that has this impact is in the function. Which has two blocks of logic one for if the left side is shorter and one if the right side is shorter. Previously both sides generated code that is branchless in terms of jumping based on the comparison result. Now the block handling left side is shorter generates a jump based on the comparison result. LLVM 15: ! LLVM 16: ! This can be fixed in code by using 'proper' branchless code: -This would fix the stdlib, but it would still mean a regression for any other code out there that relies on this.
I feel like I should attach the usual disclaimer that this kind of optimization can never be considered fully stable, specifically LLVM has various heuristics that affect whether it compiles a segment of code to use a "branchless" CMOV-alike or use a jump, however that doesn't mean there's nothing we can do here. label: +A-LLVM +A-codegen +regression-from-stable-to-beta +I-slow
WG-prioritization assigning priority (). label -I-prioritize +P-low +T-compiler
out of curiosity. What is the future for a perf regression marked as P-low? Is there any work planned on this? Personally I was surprised that it even generated branchless code in the first place.
A P-high or P-critical compiler issue means that it will be reviewed regularly by T-compiler until it is resolved, where "regularly" is a much higher frequency for P-critical. So a P-low implicitly means "this isn't so important that we need to keep putting it on the agenda". Though I should note that periodically, all T-compiler issues do get reviewed and triaged, just on a more irregular basis.
Performance work is one of those "never done" things so it's rare for it to be high priority in general, which isn't the same as "no one will work on it". It just means it would be addressed in a somewhat irregular fashion.
I'm not sure I understand the difference between "never done" and "no one will work on it".
"Never done" as in "never finished" not "never worked on"
Ohh, thanks for clarifying. Anyway from my perspective me and other people I've talked to were surprised this even generated branchless code in the first place, I'd be fine with closing this issue as won't fix.
since you have opened a PR (thanks a lot for that!), it makes totally sense to try fixing it, no matter the priority we assign to issues.
I think the issue can be split into two parts: A) A significant regression in . B) LLVM no longer generating branchless code for a certain pattern. I think A should definitely be fixed, and that's what my PR is for. B however I'd argue doesn't really need fixing, because the code in question was not obviously branchless.
In the followup discussion on , we discovered that their original problem was because they had chosen a path under their home directory for , but they had not changed the default . So most things installed fine, but they didn't have permission to write . Bootstrap could sanity check this when starting an install, seeing that is writable by the current user but the absolute is not. (A relative goes under , which should be fine.) This should also take into account as a further prefix on all installation paths.
I have just updated to version 1.71.0, and now I'm receiving the terminal warning: In my previous setup, I the line to my file.
yeah, made that effectively . That was reverted in , and now proposed for stable and beta backports. So you could add for now, but it will be going back to the way it was.
I was working on making a run-make test today for a particular thumb target. While looking over how we do this elsewhere, I found this bit of code: From my local testing, it seems like having multiple lines of this form has the net effect of making the test a no-op that does not test anything: since a target matching line 13 will not match line 14, and vice versa, there are no targets that can run on this test. We should either revert the portion of the commit that did this: or figure out some other way to express the desired property here (or change the semantics of when multiple targets are provided to make it gather all such targets up in a set before doing the check for membership... but I am wary of making such a change since doing it right would require differentiating e.g. processor target vs OS target, for example...)
Also, It looks like there may be other instances of the same mistake elsewhere in the test suite, such as in:
Oof, not good. It shouldn't be hard to make rustbuild outright reject this scenario though.
Further effort on has led me to conclude that these lines do not work at all, at least not for cross-compilation.
<!-- 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: always panic Instead, this happened: only -Zmir-opt-level=2 panic For mir-opt-level 0, 1 and 3, they all normally return <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
equals , so I think the panic case is incorrect?
Yeah, I think so.
Looks like it's JumpThreading that incorrectly removes the condition
I managed to create an example without panic, just wrong value
Most likely
ha, I found the bug. We're optimizing incorrectly in the jump threading code. Right now it's only written to handle bool correctly. I'll put up a fix 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
<!-- 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. --produces an ICE for the code given below. This code should produce an error (the implementation is missing associated items). (UPDATED: Here's MCVE: ) <!-- 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. --: Error also occurs on beta and nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Thanks! Further minimized:
Assigning as and removing .
Don't know the cause yet, but if you remove the keyword or the operator, then you get this error: My hunch is that somehow, lacking those items, the type of is coming up with something that doesn't implement the expected traits -- I would bet that we are getting an , based on some of the output at the end. Perhaps some of the logic in MIR is failing as a result. The actual ICE location though isn't that illuminating:
I did some digging here. The source of the panic is here, during HAIR construction: In this case, the binding below is of the error type (meaning type check for it failed). By replacing the binding with `` we prevent a local from being created for it, which means that when we try to generate code that reads the local we get a panic . I'm not sure what the correct fix is here. Replacing the binding with was done to prevent other ICEs, but we can't generate valid MIR without the local info. More fundamentally: We're building MIR during typeck because this is an async fn. In the past we probably never would have gotten to this stage. Backtrace: <details</details
When using async closures, rust since around 1.80 fails to infer parameter type in most scenarios. I expected to see this happen: All options used to work in past versions of rust Instead, this happened: Without explicit type hint it fails It used to work in the past, around 1.79
We don't typically mark nightly features with labels, so I'm removing those. Are you certain this regressed in 1.80? This should have regressed in , when I reimplemented async closures completely.
I am not 100% sure when it happened. I used to work with 1.7x a couple of months ago. Then I left my project for a moment. When I came back, after updating to 1.81 it no longer works. IIRC before leaving it was around 1.79, but I'm not sure.
This limitation to async closure signature inference has to do with the fact that the combinators you're using (e.g. ) take regular trait bounds. Is there a particular reason you're using async closures here? They're really not gaining you anything other than a dependency on the nightly compiler.
I posted a minimal example, indeed async does not make much sense here, but in project I work on it does. As a workaround I've just annotated parameters with original types, but I still believe this is a bug.
This indeed regressed in .
While the problem from first message in issue seems to be fixed, there are still cases when this fails. One of examples is when using instead of , when closure is expected to return : Should I open new issue, or this one will be reopened?
Please open a new issue, since it's likely a different root cause
I'm seeing an internal compiler error on the following input (found by ): The error happens on and but not on .
triage : P-medium, removing nomination, adding needs-bisect.
(the bisection here would be entirely automatable if were addressed.)
Bisected roughly: ICE occurred from but not panicked, panicked from
in particular looks suspicious. cc
Pre-, we return early with an error here: Post-, in the corresponding code happens in a call to : and the parser "recovers" from the error encountered in , allowing this line to be reached:
I opened , which takes the stance that is no longer appropriate here. It's possible that there's a better fix that changes the way works, but that would require a deeper expertise of how these things are supposed to work than I currently have.
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --the minimal triggering case seems to impl a trait that isn't visible from the location it ends up. edit: this turns out not to require macros at all. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: This also occurs in nightly (), but not in stable (which provides the correct complaint that is not publicly re-exported) <!-- 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 --
searched nightlies: from nightly-2023-11-11 to nightly-2023-12-28 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
0x7f6adfe7f645 - core::panicking::panic fmt::hcc at /rustc/ /library/core 72:14 180 x - <rustc resolve[]::late ::LateResolutionVisitor as rustcast[]::visit::Visitor::visititem 19: 0x7f6adee2d7ff - <rustcresolve[]::Resolver::resolvecrate ::{closure} 20: 0x7f6adee2ad1a - <rustcresolve[]::Resolver::resolvecrate 21: 0x7f6adeeb6d72 - rustcinterface[]::passes::resolverforlowering 22: 0x7f6adeeb5e2b - rustcqueryimpl[]::plumbing::rustbeginshortbacktrace::<rustcqueryimpl[]::queryimpl::resolverforlowering::dynamicquery::{closure}::{closure},
rustcmiddle[]::query::erase::Erased<[u8; 8usize]23: 0x7f6adef1f8ec - rustcquerysystem[]: :query::plumbing::tryexecutequery::<rustcquery impl[]::DynamicConfig<rustcquerysystem[]::query::caches::SingleCache<rustcmiddle[]::query::erase::Erased<[u8; 8usize], false, false, false, rustcqueryimpl[]::plumbing::QueryCtxt, true24: 0x7f6adef1eff3 - rustcqueryimpl[]::queryimpl::resolverforlowering::getqueryincr::rustendshortbacktrace 25: 0x7f6aded0bab3 - rustcinterface[]::interface::runcompiler::<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure} 26: 0x7f6adee3b25b - std[]::syscommon::backtrace::rustbeginshortbacktrace::<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed27: 0x7f6adee3b0b9 - <<std[]::thread::Builder::spawnunchecked<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure} as core[]::ops::function::FnOnce<()::callonce::{shim:vtable} 28: 0x7f6adfe3d8e5 - <alloc::boxed::Box<F,
Aas core::ops::function::FnOnce<Args::callonce::h5d7c8f150ab9c84c at 29: 0x7f6adfe3d8e5 - <alloc::boxed::Box<F,Aas core::ops::function::FnOnce<Args::callonce::h570d5b005c242c15 at 30: 0x7f6adfe3d8e5 - std::sys::unix::thread::Thread::new::threadstart::h36b0a20c0b2361ad at 31: 0x7f6ad9e97ada - <unknown32: 0x7f6ad9f2847c - <unknown33: 0x0 - <unknownerror: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.76.0-beta.1 ( 2023-12-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type bin -C embed-bitcode=no -C debuginfo=2 -C incremental=[REDACTED] note: some of the compiler flags provided by cargo are hidden query stack during panic: [resolverfor_lowering] getting the resolver for lowering end of query stack
That is line 18 to 33
WG-prioritization assigning priority (). label -I-prioritize +P-medium
An interesting issue, claim
interesting that the crash also doesn't happen if we qualify the trait with instead of the crate's name.
The is interpreted as referring to an external crate, whereas not
right; i'm assuming it hits a different resolver codepath, despite both working the same if the referred ident is public. thanks for the quick fix!
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'expected region for ('a//0) but found Type(&'{erased} mut FooImpl<'{erased}, '{erased}, T/) when instantiating args=[&'{erased} mut FooImpl<'{erased}, '{erased}, T/, '?27, ?2t, Closure(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), ['{erased}, '{erased}, T/, i32, Binder(fn((&ReLateParam(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), BrAnon) mut FooImpl<'{erased}, '{erased}, T/,)), []), ()])]'', 'thread 'rustc' panicked at 'expected region for ('a//0) but found Type(&'{erased} mut FooImpl<'{erased}, '{erased}, T/) when instantiating args=[&'{erased} mut FooImpl<'{erased}, '{erased}, T/, '?27, ?2t, Closure(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), ['{erased}, '{erased}, T/, i32, Binder(fn((&ReLateParam(DefId(0:22 ~ a[a197]::{impl}::foo::{closure}), BrAnon) mut FooImpl<'{erased}, '{erased}, T/,)), []), ()])]'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirborrowck] borrow-checking [mirborrowck] borrow-checking --
ICEs on nightly and beta, but not on stable. Minimized further: <details<summaryProgram output</summary</details
The ICE is another one from , cc
Still reproduces on 1.81.0-nightly (2024-06-13 ) -E-needs-test
I'll look into it later today.
<!-- 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 may be related, but I don't think this is the same bug because the above ICEs with nightly-2020-05-29.
cc
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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 --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2023-06-03 Regression in Regression in ?
This is fixed by .
assign
Tracking issue for: rust-lang/rfcs Functional record update does not mark the source as consumed, even if does not implement Copy. This means that e.g. the source's destructor will eventually be run, so the following code prints :
Note that, as discovered, you can also explicitly consume , also allowing code like:
:bomb:
Is legal, even if all members are private? It's a bit surprising
It is. There's the potentially-useful case where some of the members are private, and FRU allows you to update the public ones. Of course it should consume the source even then.
P-backcompat-lang, 1.0 beta
In my opinion the problem here is the privacy violation. The idea is that is expanded to and so forth. In this case, that does not trigger a move, because the types of those fields are . I think that part is acting as expected. What is surprising is that one can do this from outside the module.
That was (but my favored solution isn't minor).
When I initially saw this problem, I did not see it as a privacy violation, for the (obvious?) reason that since no private members of had been mentioned in the code , the client module is not breaking any abstraction introduced by privacy. I think this line of thinking is analogous to outline of the useful case where FRU allows one to update the public members of a type and silently move the private ones as well, via . This is useful for the case where the author of wants to reserve the right to add new private members to while still allowing for clients to use the convenient FRU syntax. I originally was going to try to explain my point of view via analogy with something from hygienic macros: If I were to define (and export) a macro within 's defining module: then it should, in principle, not be a privacy violation to use from client code outside 's defining module. (That is, in principle, hygiene should allow macros to expose controlled access to private internals.) Then I realized the crucial problem with that kind of analogy: is something that the designer of has to choose to put into the module; i.e., it is opt-in. But currently in Rust, FRU is not opt-in; its not even something you can opt out of.
Any struct automatically is given support for it, whether it be appropriate for that struct or not. And that seems wrong, at least given examples like the one provided here in . This latter point, that providing support for FRU should not be something that is silently attached to a type like , seems somewhat in line with the thinking given in . But I am also pretty sure we cannot adopt anything of the scope given in that draft. (Still, maybe there's a hint of solution embedded within, in the sense of having some way of marking a type as data vs abstract; see final two bullet points below.) So, as I see it, we can either: out a way to support the point-of-view outlined here in the description for , in that should somehow be treated as consuming . Such a change seems like it would be quite subtle, since we would need to have some way of expressing that code like is sound, even if the types of the fields and are consumed by their respective and methods. (In other words, need to consume , yet somehow not completely consume it. Maybe there's a way to think of it as consuming "whatever is left of the type", I do not know.) Advantages: This would address the bug as described by the issue author, and would not break any code that was not already broken. Drawbacks: It is not clear what the semantics are for this form (in other words: the phrase "would not break any code" above is only true if you first accept that this hypothesized semantics exists). Also, there may not be time to do this properly for 1.0. , try to adopt a data/abstract-type distinction along the lines of the one in draft RFC. (I'm not going to write Advantages/Drawbacks for this; I think we clearly do not have time to do it that way for 1.0) , change FRU into a non-hygienic expansion into the record construction form with all fields listed, in the sense that is synonymous with and subject to privacy checks. Advantages: Seems really simple to implement, and is consistent with at least one core team member's mental model of FRU. Drawbacks: If we did this, then code like the example above would break.