jiebi/CodeConvo huggingface dataset:
Code change:
} } <ins> /// Suggest using `while let` for call `next` on an iterator in a for loop. /// /// For example: /// ```ignore (illustrative) /// /// for x in iter { ///     ... ///     iter.next() /// } /// ``` pub(crate) fn explain_iterator_advancement_in_for_loop_if_applicable( &self, err: &mut Diagnostic, span: Span, issued_spans: &UseSpans<'tcx>, ) { let issue_span = issued_spans.args_or_use(); let tcx = self.infcx.tcx; let hir = tcx.hir(); let Some(body_id) = hir.get(self.mir_hir_id()).body_id() else { return }; let typeck_results = tcx.typeck(self.mir_def_id()); struct ExprFinder<'hir> { issue_span: Span, expr_span: Span, body_expr: Option<&'hir hir::Expr<'hir>>, loop_bind: Option<Symbol>, } impl<'hir> Visitor<'hir> for ExprFinder<'hir> { fn visit_expr(&mut self, ex: &'hir hir::Expr<'hir>) { if let hir::ExprKind::Loop(hir::Block{ stmts: [stmt, ..], ..}, _, hir::LoopSource::ForLoop, _) = ex.kind && let hir::StmtKind::Expr(hir::Expr{ kind: hir::ExprKind::Match(call, [_, bind, ..], _), ..}) = stmt.kind && let hir::ExprKind::Call(path, _args) = call.kind && let hir::ExprKind::Path(hir::QPath::LangItem(LangItem::IteratorNext, _, _, )) = path.kind && let hir::PatKind::Struct(path, [field, ..], _) = bind.pat.kind && let hir::QPath::LangItem(LangItem::OptionSome, _, _) = path && let PatField { pat: hir::Pat{ kind: hir::PatKind::Binding(_, _, ident, ..), .. }, ..} = field && self.issue_span.source_equal(call.span) { self.loop_bind = Some(ident.name); } if let hir::ExprKind::MethodCall(body_call, _recv, ..) = ex.kind && body_call.ident.name == sym::next && ex.span.source_equal(self.expr_span) { self.body_expr = Some(ex); } hir::intravisit::walk_expr(self, ex); } } let mut finder = ExprFinder { expr_span: span, issue_span, loop_bind: None, body_expr: None }; finder.visit_expr(hir.body(body_id).value); if let Some(loop_bind) = finder.loop_bind && let Some(body_expr) = finder.body_expr && let Some(def_id) = typeck_results.type_dependent_def_id(body_expr.hir_id) && let Some(trait_did) = tcx.trait_of_item(def_id) && tcx.is_diagnostic_item(sym::Iterator, trait_did) { err.note(format!( "a for loop advances the iterator for you, the result is stored in `{}`.", loop_bind )); err.help("if you want to call `next` on a iterator within the loop, consider using `while let`."); } } </ins> /// Suggest using closure argument instead of capture. /// /// For example:

Related discussion:
text: In this case, turns out there's only one: And there we see that there is already some conditional suggestion being made; it calls . And it seems there's a family of those . So I think it would make sense to try to write your own or something like that. You'll need to figure out how to sort of "back track" from the MIR back to the HIR or the AST so you can figure out whether you're inside a loop. I would study the code in to try to figure out how to do that. And don't forget to write a handful of regression tests in somewhere, maybe in : https://rustc-dev- It might also be possible to perform this check at a higher level, say, in . If you can figure out that you're in a for loop, and that the user is trying to call on the iterator, then you could raise the error then.
Code change:
_ => false, } } <ins> fn is_local(&self) -> bool { self.normal_ancestor_id.is_some() } </ins> } impl<'a> fmt::Debug for ModuleS<'a> {

Related discussion:
text: When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .
Code change:
[dependencies] core = { path = "../core" } <del> compiler_builtins = { version = "0.1.114", features = ['rustc-dep-of-std'] } [target.'cfg(not(any(target_arch = "aarch64", target_arch = "x86", target_arch = "x86_64")))'.dependencies] compiler_builtins = { version = "0.1.114", features = ["no-f16-f128"] } </del> <ins> compiler_builtins = { version = "0.1.117", features = ['rustc-dep-of-std'] } </ins> [dev-dependencies] rand = { version = "0.8.5", default-features = false, features = ["alloc"] }

Related discussion:
text: I do not have minimised code. This was a sudden CI build failure on nightly for aarch64-unknown-linux-musl () Note that this is a cross compile using cross-rs. It fails on rust version 1.82.0-nightly ( 2024-07-29) but works on 1.82.0-nightly ( 2024-07-28). Needless to say it also works perfectly fine on stable. The error is reproducible on rebuild and locally with cross-rs. It is not reproducible with cargo-zigbuild interestingly enough. I also checked that the version of cross-rs didn't change between the successful and failing builds (no new releases of that project since february). The only change between the successful and failing CI runs were a typo fix to an unrelated CI pipeline (the release one, so it didn't even run yet). As such I'm forced to conclude that the blame lies with Rustc. Steps to reproduce: I expected to see this happen: Compilation successful (as it is with stable for same target, or with -gnu and nightly) Instead, this happened () It most recently worked on: 1.82.0-nightly ( 2024-07-28) (or stable 1.80.0 or beta 1.81.0, take your pick for triaging) :
cc (of cross-rs fame) in case he has any insight on this regression
I have hit the same issue in a similar situation. Cross compiling to aarch64-unknown-linux-musl from x86_64 linux in a Github CI pipeline using cross-rs. Link to pipeline failing logs:
Seems rune isn't needed based on the comment by Updated the title.
This is probably
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah that's probably it. We used to build the C version of those symbols but switched to Rust versions with the compiler builtins update. Unfortunately we can't enable them on all platforms because LLVM has crashes, and the logic that would allow optional configuration is apparently not working.
Code change:
[dependencies] core = { path = "../core" } <del> compiler_builtins = { version = "0.1.114", features = ['rustc-dep-of-std'] } [target.'cfg(not(any(target_arch = "aarch64", target_arch = "x86", target_arch = "x86_64")))'.dependencies] compiler_builtins = { version = "0.1.114", features = ["no-f16-f128"] } </del> <ins> compiler_builtins = { version = "0.1.117", features = ['rustc-dep-of-std'] } </ins> [dev-dependencies] rand = { version = "0.8.5", default-features = false, features = ["alloc"] }

Related discussion:
text: After that part is fixed, we will need to enable the symbols on all platforms where is f128 (which includes aarch64), since these errors probably come from here I think anyone who needs a quick workaround can add to their dependencies to get the symbols directly, as described near the top of Note that this requires nightly.
Is it possible to add a dependency conditionally based on if it is nightly? (In a specific range of dates even?) I cannot and will not depend on nightly, but I do test my code on nightly in CI (in order to find breakages like this early). For now I just disabled that nightly build on aarch64 musl.
Same for me. Not using cross-rs though. Logs are here:
Same for me, both using as host toolchain and cross compiling.
Looks like it is happening now too for x86_64.
Not for my projects, so you should probably provide a reproducer on x86-64 GNU if possible, since that is a tier 1 platform (unlike Aarch64 on Musl). Or is this about some other x8664 variation that is also tier 2?
Woops, sorry, the x86_64 build failed too, but then i looked at the aarch64 build logs :) which still fail.
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub trait AbstractRenderer {} fn _create_render(_: &()) -> AbstractRenderer //~^ ERROR: the trait `core::kinds::Sized` is not implemented { match 0u { _ => unimplemented!() } } fn main() { } </ins>

Related discussion:
text: The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.
Code change:
<del> Subproject commit a416c5e0f7c4c9473069a58410d3ec3e86b1ac0d </del> <ins> Subproject commit fc24fce73f878e641094b1802df1e748c5fe233a </ins>

Related discussion:
text: use std; import std::vec; fn main() { let vec[int] a = [0]; auto i = 20; while (i 0) { a += a; i -= 1; } } I suspect, but haven't confirmed, the following: If a vector that is in the process of self-appending (v += v) grows, we can realloc the existing vector pointer and invalidate the memory that is being copied.
I'm the last person who touched the vec append glue. I'll look into it.
Yeah, you were exactly right. Fixed by .
Code change:
<del> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </del>

Related discussion:
text: Reproduction branch: When applying the change from the last commit I get a panic in my code during the call to . <details<summaryBacktrace</summary</details
Cannot reproduce on my linux. Can you provide a small ? Is that possible? Maybe without all the externals :/
I can reproduce a very similar problem (appears to involve the same origin and failing assertion of ) compiling rust-lang/regex with and compiler flags: For me, setting to 2 or greater is required to present this failure. <details<summarybacktrace</summary<code<preRUSTBACKTRACE=1 cargo build Compiling regex v1.1.2 (/home/kent/rust/regex) thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanic 7: syntax::sourcemap::SourceMap::bytepostofilecharpos 8: syntax::sourcemap::SourceMap::lookupcharpos 9: <rustccodegenssa::mir::FunctionCx<'a, 'tcx, Bx::scopemetadataforloc 10: <rustccodegenssa::mir::FunctionCx<'a, 'tcx,
Code change:
<del> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </del>

Related discussion:
text: Bx::debugloc 11: rustccodegenssa::mir::codegenmir 12: rustccodegenssa::base::codegeninstance 13: rustccodegenssa::monoitem::MonoItemExt::define 14: rustccodegenllvm::base::compilecodegenunit::modulecodegen 15: rustc::depgraph::graph::DepGraph::withtask 16: rustccodegenllvm::base::compilecodegenunit 17: rustccodegenssa::base::codegencrate 18: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 19: rustc::util::common::time 20: rustcdriver::driver::phase4codegen 21: rustcdriver::driver::compileinput::{{closure}} 22: <std::thread::local::LocalKey<T::with 23: rustc::ty::context::TyCtxt::createandenter 24: rustcdriver::driver::compileinput 25: rustcdriver::runcompilerwithpool 26: <scopedtls::ScopedKey<T::set 27: rustcdriver::runcompiler 28: syntax::withglobals 29: rustmaybecatchpanic at 30: <F as alloc::boxed::FnBox<A::callbox 31: std::sys::unix::thread::Thread::new::threadstart at at at 32: <unknown33: clone query stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-26) running on x86_64-unknown-linux-gnu note: compiler flags: -Z mir-opt-level=2 -C debuginfo=2 -C incremental --crate-type lib </pre</code</details
With the help of , I've found a tiny test that reproduces this crash on Linux and Mac:
Got another one: <details</detailsHappens when compiling regex tests with and calling on every span found in the mir of the functions needing codegen.
According to glaicer, the ICE from this example has been gone.
can you confirm that your example does not crash on nightly anymore?
Code change:
<del> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </del>

Related discussion:
text: Has been fixed in
is likely the part of the rollup fixing it.
Shouldn't a testcase be instead of closing this?
A similar crash that still happens:
Code change:
<del> error[E0308]: mismatched types --> $DIR/issue-30904.rs:20:45 | LL |     let _: for<'a> fn(&'a str) -> Str<'a> = Str; |                                             ^^^ expected concrete lifetime, found bound lifetime parameter 'a | = note: expected type `for<'a> fn(&'a str) -> Str<'a>` found type `fn(&str) -> Str<'_> {Str::<'_>}` error[E0631]: type mismatch in function arguments --> $DIR/issue-30904.rs:26:10 | LL | fn test<F: for<'x> FnOnce<(&'x str,)>>(_: F) {} |    ----    -------------------------- required by this bound in `test` ... LL | struct Str<'a>(&'a str); | ------------------------ found signature of `fn(&str) -> _` ... LL |     test(Str); |          ^^^ expected signature of `for<'x> fn(&'x str) -> _` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </del>

Related discussion:
text: I realize it's kinda nonsensical, but here:
Why didn't WF catch this?
That's because only checks statics/constants.
Still reproducible with .
This ought to be a mostly easy fix. The problem is that the well formedness check, which ought to be rejected this code, is ignoring things in an : They fall through to this `` case: We would need to add support for the HIR item: which in turn has a number of items: which are defined here: presumably we want the to check that the types of are well-formed, roughly analogous to how we current check normal static items: (We probably want similar checks on foreign item fns, though?) One tricky part might be compatibility, we may need to turn this into a compatibility lint in case there is lots of broken code in the wild.
I am trying to fix this bug, and need help moving forward. function is modified to accept a and a , yet it doesn't report any additional errors and the ICE prevails. Test file: Commit: Should I create a pull request or is it too early?
Looks like suggestions are incomplete ( does not require ). Also, I left a comment on your commit about how you can avoid adding . I suspect the only reason regular s are required to be is they have an initializer (and that, not the type, requires ), i.e. for we have these errors:
Oddly, the PR that were previously posted to fix this (PR , following on PR ) was subsequently closed as inactive ... but the bug itself seems like it may have been resolved in the meantime?
I'm going to assume this was fixed. Tagging as E-needstest, but if someone wants to take the time, it'd be even better to bisect to where this was fixed, and see if a regression test for this was at that time.
Compiler no longer panics, tested with
Code change:
<ins> // aux-build:issue-99221-aux.rs // build-aux-docs // ignore-cross-compile #![crate_name = "foo"] #[macro_use] extern crate issue_99221_aux; pub use issue_99221_aux::*; // @count foo/index.html '//a[@class="macro"]' 1 #[macro_export] macro_rules! print { () => () } </ins>

Related discussion:
text: I tried to create a minimum example from an issue we've seen in our project (). I tried running: On the following crate: : I expected to see this happen: The command should succeed. Instead, this happened: It crashed with an 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
This issue may be related to , however I can only reproduce it on the nightly build. On the stable channel, rustdoc succeeds.
cc
does this reproduce on beta?
I know I'm not celinval, but I've been able to reduce this to a test case, and yeah, it reproduces on beta.
That was quick. Thank you!
Reopening to track beta breakage.
I was silly and nominated even though the PR has already been nominated, and that's really the thing that's supposed to be. Please ignore, and sorry for the noise.
Code change:
}) } <del> pub fn predicate_for_default_trait_impl<'tcx>( </del> <ins> pub fn predicate_for_trait_def<'tcx>( </ins> tcx: &ty::ctxt<'tcx>, cause: ObligationCause<'tcx>, trait_def_id: ast::DefId,

Related discussion:
text: For example, this code does not compile: cc
I think this may be another instance of
Trusting analysis, closing in favor of but adding test case there as well.
(it of course would be good to confirm that this actually is an instance of -- my initial reaction when I saw it was "they might be related ... but wait, wasn't part of the opt-in-builtin-bounds work to be able to move the special case handling of / out into library code...?"; I've only done some rough skimming that makes me think the hypothesis remains plausible.)
Ah either way is fine by me, I personally like fewer issues :). We can reopen once is addressed one way or another if necessary (or if you'd like to reopen now that's also fine by me!)
oh that was really just a note to myself as much as anything else, not a comment on your choice to close this ticket. :)
I don't think this code uses type-contents. If it does, that is itself a bug! Either way, we should keep this open for the time being.
cc
Code change:
}) } <del> pub fn predicate_for_default_trait_impl<'tcx>( </del> <ins> pub fn predicate_for_trait_def<'tcx>( </ins> tcx: &ty::ctxt<'tcx>, cause: ObligationCause<'tcx>, trait_def_id: ast::DefId,

Related discussion:
text: The following doesn't compile, but I believe it should: Error: Even though , and . In fact, this compiles:
should be , because the old definition that didn't use assoc types was . Probably the code that detects builtin bounds wasn't updated to handle associated types. cc
This breaks us in hyper. For now, I'll have to manually , knowing that it's safe.,,
Code change:
|                   ^ expected identifier, found reserved identifier error: associated constant in `impl` without body <del> --> $DIR/typeck_type_placeholder_item.rs:203:5 </del> <ins> --> $DIR/typeck_type_placeholder_item.rs:205:5 </ins> | LL |     const C: _; |     ^^^^^^^^^^-

Related discussion:
text: First time filing a bug report, apologies if i missed anything or if this is a duplicate. Encountered this bug while writing some non-sensical associated function types. Searched around for any similar issues and the closest i found was , seems closely related? Minimal example: Playground link: The ICE happens on all channels it seems
Yes, I think so too. The snippet is rejected as expected on 1.42 but ICE occurs instead since 1.43.
Assigning as and removing .
Code change:
install_sh(builder, "clippy", self.compiler.stage, Some(self.target), &tarball); }; Miri, alias = "miri", Self::should_build(_config), only_hosts: true, { <del> let tarball = builder .ensure(dist::Miri { compiler: self.compiler, target: self.target }) .expect("missing miri"); install_sh(builder, "miri", self.compiler.stage, Some(self.target), &tarball); </del> <ins> if let Some(tarball) = builder.ensure(dist::Miri { compiler: self.compiler, target: self.target }) { install_sh(builder, "miri", self.compiler.stage, Some(self.target), &tarball); } else { // Miri is only available on nightly builder.info( &format!("skipping Install miri stage{} ({})", self.compiler.stage, self.target), ); } </ins> }; LlvmTools, alias = "llvm-tools", Self::should_build(_config), only_hosts: true, { let tarball = builder

Related discussion:
text: On Solaris 11 x86_64, from scratch builds of 1.66.0 from git fails with: A build of the same tag completes successfully, as do and builds of 1.65.0.
Was there an earlier (nonfatal) error? If miri failed to build there should hopefully be a reason mentioned. We turned miri on unconditionally, so builds require it to build successfully. Maybe we should disable that requirement for stable builds,but even so, stable builds should work just like nightly builds for miri
It doesn't even try to build , instead panics soon after its start: Dunno about Solaris build but MSYS2 hack quite a lot patches that theoretically could cause problems.
Found the culprit: Should be easy enough to fix by making install not unwrap anymore. Looks like I was too eager
Glad to see that this is indeed a real issue. Was tearing my hair out for hours wondering WHY x.py install kept failing with missing miri when is set with channel = "stable"
We are still seeing this with 1.66.1. […] Compiling thiserror v1.0.33 Finished release [optimized] target(s) in 38.48s warning: x.py has made several changes recently you may want to look at help: consider looking at the changes in note: to silence this warning, add at the top of note: this message was printed twice to make it more likely to be seen Build completed successfully in 0:28:41 python3 install Building rustbuild Finished dev [unoptimized] target(s) in 0.66s warning: x.py has made several changes recently you may want to look at help: consider looking at the changes in note: to silence this warning, add at the top of thread 'main' panicked at 'missing miri', note: run with environment variable to display a backtrace Build completed unsuccessfully in 0:00:01
The fix has been merged for the future 1.68 release.