jiebi/CodeConvo huggingface dataset:
Change:
fn main() { <del> [0].iter().flat_map(|a| [0].iter().map(|_| &a)); //~ ERROR `a` does not live long enough </del> <ins> [0].iter().flat_map(|a| [0].iter().map(|_| &a)); //~ ERROR closure may outlive </ins> }

Discussion:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.
Change:
<ins> // Makes sure we deal with escaping lifetimes *above* INNERMOST when // suggesting trait for ambiguous associated type. impl<I, V> Validator<I> for () where for<'iter> dyn Validator<<&'iter I>::Item>:, //~^ ERROR ambiguous associated type {} pub trait Validator<T> {} fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in cc
Change:
<ins> // Test the parse error for an empty recursion_limit #![recursion_limit = ""] //~ ERROR `recursion_limit` must be a non-negative integer //~| `recursion_limit` must be a non-negative integer fn main() {} </ins>

Discussion:
The following code since it exceeds the default recursion limit. Using as the recursion limit works as expected. This is because we don't check for integer overflow errors when parsing limits: There's a few options here. My preference would be to silently default to when overflow occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi! I'd like to try and handle this. If I understand this correctly, we should check if there is an , and if that error is an overflow. If it's an overflow, we default to ? claim
correct
Change:
impl<'tcx> ToPolyTraitRef<'tcx> for PolyTraitPredicate<'tcx> { fn to_poly_trait_ref(&self) -> PolyTraitRef<'tcx> { <del> self.map_bound_ref(|trait_pred| trait_pred.trait_ref.clone()) </del> <ins> self.map_bound_ref(|trait_pred| trait_pred.trait_ref) </ins> } }

Discussion:
This takes ~2 seconds to type check (according to ): Doubling (respectively, halving) the number of invocations multiplies (resp. divides) the time by 4. It applies to arithmetic in s/s too which is, I imagine, where this will occur most often in practice (it's how I found it). Observations: for , , and , annotating either side (e.g. ) or both sides makes it take only 0.03s and behave linearly (AFAICT) for and : annotating the LHS () reduces the time to ~1.5s, annotating the RHS () reduces it to ~1.1s but both are still quadratic, annotating both takes it to 0.04s and linear it seems to only be dependent on the number of operations in a single function/item, separating the 4 big chunks above across 4 functions reduces the time to ~0.5s. there's no significant difference between using the macro or writing the operations inline (I only use to allow easier experimentation) cc
This must be what's making my old macro-abusing inflate implementation take almost 300 seconds in typeck. It almost sounds like type-checking a function is quadratic over the number of inference variables. Having ran callgrind on the sample and also half of it, I'm seeing the following trace: An unrefined conclusion is that either shouldn't call or should be constant-time.
Is this the same issue as ?
I'm not too familiar with fulfill and infer, but couldn't track the latest snapshot it processed and look at the new information there?
We have exactly for this reason. It doesn't work for some reason tho.
This is the same issue as This is a different issue from (I think I will fix that one separately).
Change:
let upvar = ty::place_to_string_for_capture(tcx, place); match tables.upvar_capture(upvar_id) { ty::UpvarCapture::ByRef(ty::UpvarBorrow { <del> kind: ty::BorrowKind::MutBorrow, </del> <ins> kind: ty::BorrowKind::MutBorrow | ty::BorrowKind::UniqueImmBorrow, </ins> .. }) => { format!("mutable borrow of `{}`", upvar)

Discussion:
Compiled with gives:
This was caused by prioritize edit: in beta, this gives the following error: `
Assigning as discussed as part of the and removing .
Looks likely that is the cause. cc
Re-prioritizing as and removing as in the prioritization working group. label: +regression-from-stable-to-nightly +P-high -P-medium -I-prioritize
Change:
} // For parameterizing over mutability. <ins> #[cfg(stage0)] </ins> impl<'t, K, V> Deref<RawTable<K, V>> for &'t RawTable<K, V> { fn deref(&self) -> &RawTable<K, V> { &**self } } <ins> #[cfg(stage0)] </ins> impl<'t, K, V> Deref<RawTable<K, V>> for &'t mut RawTable<K, V> { fn deref(&self) -> &RawTable<K,V> { &**self } } <ins> #[cfg(stage0)] </ins> impl<'t, K, V> DerefMut<RawTable<K, V>> for &'t mut RawTable<K, V> { fn deref_mut(&mut self) -> &mut RawTable<K,V> { &mut **self

Discussion:
As titled. Add the following trait implementations: This allows generic code that accepts smart pointer can take references too, e.g.
cc
yes I want this :+1:
This would also allow code to be polymorphic over &T and &mut T by accepting . A huge win imho.
The branch creates some .
Change:
use clippy_utils::{is_expn_of, match_function_call, paths}; use if_chain::if_chain; use rustc_errors::Applicability; <del> use rustc_hir::{Expr, ExprKind}; </del> <ins> use rustc_hir::def::Res; use rustc_hir::{BindingAnnotation, Block, BlockCheckMode, Expr, ExprKind, Node, PatKind, QPath, Stmt, StmtKind}; </ins> use rustc_lint::{LateContext, LateLintPass}; use rustc_session::{declare_lint_pass, declare_tool_lint}; use rustc_span::sym;

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- is likely cause (cc
I'll fix this.
Fixed on beta with and on master. will be a more complete change and will likely land in 1.63 (or later).
Change:
if location.statement_index != block.statements.len() { let stmt = &block.statements[location.statement_index]; <del> if let StatementKind::Assign(box (p, Rvalue::Use(Operand::Constant(c)))) = &stmt.kind { match c.literal.val { // Keep assignments from unevaluated constants around, since the evaluation // may report errors, even if the use of the constant is dead code. ty::ConstKind::Unevaluated(..) => {} _ => { if !p.is_indirect() { trace!("skipping store of const value {:?} to {:?}", c, p); return; </del> <ins> if let StatementKind::Assign(box (dest, rvalue)) = &stmt.kind { if !dest.is_indirect() && dest.local == *local { if let Rvalue::Use(Operand::Constant(c)) = rvalue { match c.literal.val { // Keep assignments from unevaluated constants around, since the // evaluation may report errors, even if the use of the constant // is dead code. ty::ConstKind::Unevaluated(..) => {} _ => { trace!("skipping store of const value {:?} to {:?}", c, dest); return; } </ins> } <ins> } else if let Rvalue::Discriminant(d) = rvalue { trace!("skipping store of discriminant value {:?} to {:?}", d, dest); return; </ins> } } }

Discussion:
The doesn't have any effect. (Labeling because this prevents codegen of the like . Which may result in a few extra instructions being emitted to move registers and jump to the return block for cg_clif.) modify labels: +A-mir +A-mir-opt +A-cranelift
We already have a pass that propagates the terminator, it should be possible to make it handle as well. (however can leave sideeffects visible to the caller, so maybe this should be a proper dead code elimination pass instead)
For background, this is a side-effect of (see the MIR diagram in the PR summary) and . The MIR for the above example used to contain a frivolous open drop of . After my changes to drop elaboration, all branches of the open drop become no-op s, which are then removed by the pass. The read of the discriminant as part of the open drop remains, however. To my knowledge, we don't have a dead-code elimination pass for the MIR, which would be the proper way to handle this.
Change:
config.try_run(cmd) } <ins> fn extract_curl_version(out: &[u8]) -> semver::Version { let out = String::from_utf8_lossy(out); // The output should look like this: "curl <major>.<minor>.<patch> ..." out.lines() .next() .and_then(|line| line.split(" ").nth(1)) .and_then(|version| semver::Version::parse(version).ok()) .unwrap_or(semver::Version::new(1, 0, 0)) } fn curl_version() -> semver::Version { let mut curl = Command::new("curl"); curl.arg("-V"); let Ok(out) = curl.output() else { return semver::Version::new(1, 0, 0) }; let out = out.stdout; extract_curl_version(&out) } </ins> /// Generic helpers that are useful anywhere in bootstrap. impl Config { pub fn is_verbose(&self) -> bool {

Discussion:
We're passing --retry: but by default that only retries 500 errors, not any error: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is a regression from when I moved the downloads from python to rust (about a year ago now I think).
Mentoring instructions: Add the option to the invocations, in and This doesn't affect the Windows Powershell fallback, since we already retry on any error. There are many other invocations across the repo, but they seem to not be causing problems.
claim
This is quite new flag shipped with recent versions of curl, which is not supported on many machines/platforms(including our CI runners). We can consider using as I also suggest at
I'd like to take a look at this. Looking through the PR history, we would like basic retry logic written in Rust versus using a curl flag like to retry during the bootstrap process. If it's a 404, then do not retry, but any other errors should be retried. I assume there is a http library already vendored in, so no new dependencies should be .
claim
Thanks! This shouldn't be needed. For now, retrying on "connection refused" () should be fine.
I'm a little confused as to why was closed then. What more is there beyond adding the retry refused connections flag?
I forgot that our CI runners depend on very old curl versions which doesn't support the flag I suggested. Sorry, you are right. As jyn also said() in that PR, we can handle this in Rust
are we ok with adding the dependency to facilitate sending requests to the payload URL? I'm very hesitant to add another crate dependency to the core payload. But without it, we would need to manually built a request via the standard library tcp library. Which is a little awkward. doesn't actually have support for sending requests. I suppose, in the case we decide to use it, another library would need to be as well?
What about using curl arguments to read the status code and handle it in rust logic? It might be a bit ugly, but adding a dependency solely for this purpose seems like overkill to me.
I agree adding a new dep seems extreme.

I can try parsing the curl exit code, great idea.
claim
claim
Hello Is this still relevant?
please don't ping me about rust-lang/ issues. is the current maintainer.
We didn't change any curl flags since then; it should be still relevant.
release-assignment
Change:
<ins> // check-pass // compile-flags: -Zvalidate-mir fn foo(_a: &str) {} fn main() { let x = foo as fn(&'static str); let _ = x == foo; } </ins>

Discussion:
<!-- 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 glacier / <!-- 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
another case 
Probably caused by cc
Oops. That's my b, I'll have a PR up in 10 minutes
Change:
&self, impl_candidates: Vec<ImplCandidate<'tcx>>, trait_ref: ty::PolyTraitRef<'tcx>, <ins> body_id: hir::HirId, </ins> err: &mut Diagnostic, ) -> bool { let report = |mut candidates: Vec<TraitRef<'tcx>>, err: &mut Diagnostic| {

Discussion:
<!-- 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. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.
Change:
| LL |     B == 2 |       ^^ help: try using `=` instead <ins> | = help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }` </ins> error: expected item, found `==` --> $DIR/issue-101477-enum.rs:6:7

Discussion:
<!-- 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. --Although I know Enums take to form of: I sometimes find myself accidentally defining them as I would a Struct (): The current output is: This always takes more than a few seconds to parse and then realize my mistake. Is it possible to change this to something like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Do you have any suggestion for how the compiler should distinguish between "trying to write an enum with struct syntax" and "trying to write a struct but used the enum keyword"?
Linking to the topic on internals where some other folks have left suggestions (). Although none of those directly address your question. My gut reaction is to assume that if the "enum" keyword is used that truly was the intention of the developer, but if it wasn't, hopefully some help message like the : Would provide enough information to trigger an "Oh wait did I really want to use an enum here?"
claim
Change:
<del> // aux-build:arc_wake.rs extern crate arc_wake; use std::future::Future; use std::pin::Pin; use std::sync::{ Arc, atomic::{self, AtomicUsize}, }; use std::task::{ Context, Poll, }; use arc_wake::ArcWake; struct Counter { wakes: AtomicUsize, } impl ArcWake for Counter { fn wake(self: Arc<Self>) { Self::wake_by_ref(&self) } fn wake_by_ref(arc_self: &Arc<Self>) { arc_self.wakes.fetch_add(1, atomic::Ordering::SeqCst); } } struct MyFuture; impl Future for MyFuture { type Output = (); fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> { // Wake twice let waker = cx.waker(); waker.wake_by_ref(); waker.wake_by_ref(); Poll::Ready(()) } } fn test_waker() { let counter = Arc::new(Counter { wakes: AtomicUsize::new(0), }); let waker = ArcWake::into_waker(counter.clone()); assert_eq!(2, Arc::strong_count(&counter)); { let mut context = Context::from_waker(&waker); assert_eq!(Poll::Ready(()), Pin::new(&mut MyFuture).poll(&mut context)); assert_eq!(2, counter.wakes.load(atomic::Ordering::SeqCst)); } drop(waker); assert_eq!(1, Arc::strong_count(&counter)); } fn main() { test_waker(); } </del>

Discussion:
E.g. in and cc
I'd like to work on this :smile:
You've got it :)
Change:
<ins> error[E0577]: expected module, found unresolved item `crate::r#mod` --> $DIR/issue-61732.rs:3:8 | LL | pub(in crate::r#mod) fn main() {} |        ^^^^^^^^^^^^ not a module error: Compilation failed, aborting rustdoc error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0577`. </ins>

Discussion:
Rust version affected Both stable and nightly: How to reproduce Run on this code: Stacktrace Potentially related issue: , although here it happens only with not
Can confirm on .
MCVE: Bisected to find regression is in nightly , from: to the above ICE. As far as I can tell only rustdoc triggers it, but I don't know enough to say that for certain.
Cannot reproduce the ICE with the above MCVE on latest nightly ()
After too much time bisecting, it has worked since , more specifically commit which is this rollup: . My guess is that this is another bug fixed by .
I can confirm that probably fixed this. I've submitted the MCVE as a regression test:
Change:
EncodedMetadata, ForeignModule}; use rustc::hir::def::CtorKind; use rustc::hir::def_id::{CrateNum, CRATE_DEF_INDEX, DefIndex, DefId, LocalDefId, LOCAL_CRATE}; <del> use rustc::hir::GenericParamKind; </del> <ins> use rustc::hir::{GenericParamKind, AnonConst}; </ins> use rustc::hir::map::definitions::DefPathTable; use rustc_data_structures::fingerprint::Fingerprint; use rustc_index::vec::IndexVec;

Discussion:
In a folder , I have a blank library crate with the following : In a folder , I have a blank binary crate with the follow : 's uses crate with the following line: Running or in will produce the following ICE:
triage: P-high. Assigning to self for initial investigation. Removing I-nominated label. assigning as well, as someone who will likely resolve this faster than it will take me to build
Oh, given that this is using const generics (an unstable feature), it probably should be P-medium rather than P-high. I won't change the label yet, but if triage on thursday rolls around and I haven't seen a good reason to keep it P-high, I'll change the label then.
If downstream crates could ICE because they're using a type alias with const generics, even if they don't enable themselves, it seems like slightly more of an issue. (Sorry, I don't have time to look into this issue at the moment.)
It's not just type aliases, but also other constellations of cross-crate usage that are giving this ICE:
I continue to have the impression that if you use stable Rust, it will be used on all of your crates, and therefore you won't hit this bug. (don't get me wrong; I've commented elsewhere, rust-call bug in particular, where I do worry about impact on downstream crates from upstream crates using certain features that have bugs) But I still think this only warrants P-medium. Reclassifying as such.
Encountered this issue and documented it . The associated code is .
I just hit this issue as well in my project. Unfortunately I cannot share the code I'm hitting this with. A repro would look very similar to est31's example , but in my case the affected type isn't even exposed to the bin application. It's only. <details<summaryClick for stack</summary<p</p</details
Also when the type is wrapped privately (i.e., ) and exported like that, it seems to be triggered.
Change:
EncodedMetadata, ForeignModule}; use rustc::hir::def::CtorKind; use rustc::hir::def_id::{CrateNum, CRATE_DEF_INDEX, DefIndex, DefId, LocalDefId, LOCAL_CRATE}; <del> use rustc::hir::GenericParamKind; </del> <ins> use rustc::hir::{GenericParamKind, AnonConst}; </ins> use rustc::hir::map::definitions::DefPathTable; use rustc_data_structures::fingerprint::Fingerprint; use rustc_index::vec::IndexVec;

Discussion:
Hey everybody :) I was trying to test matrix*vector in aljabar crate by running "cargo test" on: and got this: Not sure if it's a known issue or not but if there's anything else you need from me please let me know :)
version:
verbose trace:
It would help if you can reduce the problem to a minimal reproducer without the crate. (Also note that ICEs are common for .)
Not sure if i can manage that. Could be over my head.
there is a minimal example here:
Change:
<del> //@ known-bug: #121613 fn main() { // destructure through a qualified path let <Foo as A>::Assoc { br } = StructStruct { br: 2 }; //~^ ERROR usage of qualified paths in this context is experimental let _ = <Foo as A>::Assoc { br: 2 }; //~^ ERROR usage of qualified paths in this context is experimental let <E>::V(..) = E::V(|a, b| a.cmp(b)); //~^ ERROR usage of qualified paths in this context is experimental } struct StructStruct { br: i8, } struct Foo; trait A { type Assoc; } impl A for Foo { type Assoc = StructStruct; } enum E { V(u8) } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'', 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in nightly-2022-06-04 commit[0] 2022-06-02: Auto merge of - nnethercote:lazify-SourceFile-lines, r=Mark-Simulacrum commit[1] 2022-06-02: Auto merge of - spastorino:simplify-universal-impl-trait-lowering, r=cjgillot commit[2] 2022-06-03: Auto merge of - matthiaskrgr:rollup-5cfxc85, r=matthiaskrgr commit[3] 2022-06-03: Auto merge of - c410-f3r:z-errors, r=petrochenkov commit[4] 2022-06-03: Auto merge of - cjgillot:remove-label-lt-shadow, r=petrochenkov commit[5] 2022-06-03: Auto merge of - Dylan-DPC:rollup-nswmgmx, r=Dylan-DPC commit[6] 2022-06-03: Auto merge of - lcnr:path-generics-diagnostics, r=estebank commit[7] 2022-06-03: Auto merge of - Dylan-DPC:rollup-2yxo7ce, r=Dylan-DPC commit[8] 2022-06-03: Auto merge of - bjorn3:serde_json, r=wesleywiser commit[9] 2022-06-03: Auto merge of - notriddle:notriddle/human-readable-signals, r=yaahc ERROR: no CI builds available between and within last 167 days
It appears I'm hitting this one as well. Tacking this on for good measure. <details</details
Looks like it was originally introduced by (and was renamed later to without any change in functionality). I'd PR a fix but I'm not entirely sure how it's supposed to work. Is this masking a deeper bug or can one simply do something like: Derp, missed there was a PR. indeed fixes this on my end. Thanks for the quick fix on this!