jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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. --This is new, introduced between (older) and (newer) src/tools/miri/tests/pass- <!-- 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
prioritize
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Discussion:
ident_name: Symbol, } <ins> // FIXME: This really should be taking scoping, etc into account. </ins> impl<'v> Visitor<'v> for LetVisitor<'v> { fn visit_stmt(&mut self, ex: &'v hir::Stmt<'v>) { <del> if let hir::StmtKind::Local(hir::Local { pat, init, .. }) = &ex.kind { if let Binding(_, _, ident, ..) = pat.kind && ident.name == self.ident_name { self.result = *init; } </del> <ins> if let hir::StmtKind::Local(hir::Local { pat, init, .. }) = &ex.kind && let Binding(_, _, ident, ..) = pat.kind && ident.name == self.ident_name { self.result = *init; } else { hir::intravisit::walk_stmt(self, ex); </ins> } <del> hir::intravisit::walk_stmt(self, ex); </del> } }

visitor.visit_body(&body); let parent = self.tcx.hir().get_parent_node(seg1.hir_id); <del> if let Some(Node::Expr(call_expr)) = self.tcx.hir().find(parent) && let Some(expr) = visitor.result { let self_ty = self.node_ty(expr.hir_id); </del> <ins> if let Some(Node::Expr(call_expr)) = self.tcx.hir().find(parent) && let Some(expr) = visitor.result && let Some(self_ty) = self.node_ty_opt(expr.hir_id) { </ins> let probe = self.lookup_probe( seg2.ident, self_ty,

sm.span_extend_while(seg1.ident.span.shrink_to_hi(), |c| c == ':').unwrap(), "you may have meant to call an instance method", ".".to_string(), <del> Applicability::MaybeIncorrect </del> <ins> Applicability::MaybeIncorrect, </ins> ); } }

<ins> fn main() { let page_size = page_size::get(); //~^ ERROR failed to resolve: use of undeclared crate or module `page_size` } </ins>

<ins> error[E0433]: failed to resolve: use of undeclared crate or module `page_size` --> $DIR/path-to-method-sugg-unresolved-expr.rs:2:21 | LL |     let page_size = page_size::get(); |                     ^^^^^^^^^ use of undeclared crate or module `page_size` error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label +requires-debug-assertions
Reduced from 205 lines to 56 lines: Error output with :

Discussion:
let result = if let Some(trait_def_id) = tcx.trait_of_item(def.did) { debug!(" => associated item, attempting to find impl in param_env {:#?}", param_env); <del> resolve_associated_item(tcx, def.did, param_env, trait_def_id, substs) </del> <ins> resolve_associated_item( tcx, def.did, param_env, trait_def_id, tcx.normalize_erasing_regions(param_env, substs), ) </ins> } else { let ty = tcx.type_of(def.def_id_for_type_of()); let item_type = tcx.subst_and_normalize_erasing_regions(substs, param_env, ty);

<ins> // check-pass // compile-flags: -C debug_assertions=yes -Zunstable-options #[allow(dead_code)] fn problematic_function<Space>() where DefaultAlloc: FinAllok<R1, Space>, { let e = Edge2dElement; let _ = Into::<Point>::into(e.map_reference_coords()); } impl<N> Allocator<N, R0> for DefaultAlloc { type Buffer = MStorage; } impl<N> Allocator<N, R1> for DefaultAlloc { type Buffer = MStorage; } impl<N, D> From<VectorN<N, D>> for Point where DefaultAlloc: Allocator<N, D>, { fn from(_: VectorN<N, D>) -> Self { unimplemented!() } } impl<GeometryDim, NodalDim> FinAllok<GeometryDim, NodalDim> for DefaultAlloc where DefaultAlloc: Allocator<Ure, GeometryDim>, DefaultAlloc: Allocator<Ure, NodalDim> { } impl FiniteElement<R1> for Edge2dElement { fn map_reference_coords(&self) -> VectorN<Ure, R1> { unimplemented!() } } type VectorN<N, R> = (N, R, <DefaultAlloc as Allocator<N, R>>::Buffer); struct DefaultAlloc; struct R0; struct R1; struct MStorage; struct Point; struct Edge2dElement; struct Ure; trait Allocator<N, R> { type Buffer; } trait FinAllok<GeometryDim, NodalDim>: Allocator<Ure, GeometryDim> + Allocator<Ure, NodalDim> + { } trait FiniteElement<Rau> where DefaultAlloc: FinAllok<Rau, Rau>, { fn map_reference_coords(&self) -> VectorN<Ure, Rau>; } fn main() {} </ins>
Change:
<!-- 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: <!-- Please provide a link to --The current output is: is a valid expression (a  literal), so this error is misleading. It should at a minimum have a suggestion to replace with the valid version , and probably should just work. It also imho ideally shouldn't be a hard parser error blocking semantic passes; the parse of is fairly unambiguously intended, even if we decide we should still require the parenthesis. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm interested! Where should I look first? (I have no experience in rustc, some general experience in compilers tho)
The is a good place to start. If you have some compiler development experience already, that should get you going quickly enough. One specifically relevant section is is likely to be where you'll need to change. Also, ; you can to assign yourself to the issue to track that you're working on it.
For extra context, is accepted in expression position at least for both , , and obviously , so I have absolutely no idea what makes different that it causes a parser error in this case.
claim

Discussion:
} } <ins> pub fn is_range_separator(&self) -> bool { [DotDot, DotDotDot, DotDotEq].contains(&self.kind) } </ins> pub fn is_op(&self) -> bool { match self.kind { Eq | Lt | Le | EqEq | Ne | Ge | Gt | AndAnd | OrOr | Not | Tilde | BinOp(_)

LhsExpr::AttributesParsed(attrs) => Some(attrs), _ => None, }; <del> if [token::DotDot, token::DotDotDot, token::DotDotEq].contains(&self.token.kind) { </del> <ins> if self.token.is_range_separator() { </ins> return self.parse_prefix_range_expr(attrs); } else { self.parse_prefix_expr(attrs)?

} debug_assert!( <del> [token::DotDot, token::DotDotDot, token::DotDotEq].contains(&self.token.kind), </del> <ins> self.token.is_range_separator(), </ins> "parse_prefix_range_expr: token {:?} is not DotDot/DotDotEq", self.token );

let has_lifetime = self.token.is_lifetime() && self.look_ahead(1, |t| t != &token::Colon); let lifetime = has_lifetime.then(|| self.expect_lifetime()); // For recovery, see below. let (borrow_kind, mutbl) = self.parse_borrow_modifiers(lo); <del> let expr = self.parse_prefix_expr(None); </del> <ins> let expr = if self.token.is_range_separator() { self.parse_prefix_range_expr(None) } else { self.parse_prefix_expr(None) }; </ins> let (hi, expr) = self.interpolated_or_expr_span(expr)?; let span = lo.to(hi); if let Some(lt) = lifetime {

<ins> // check-pass fn main() { let _a = ..; let _b = ..=10; let _c = &..; let _d = &..=10; } </ins>
Change:
e.g. is currently valid, but shouldn't be. (Note that is, and should remain, a valid lifetime.)
Note that this will only be possible after a snapshot, since the snapshot compiler currently requires lifetimes called . (Tagged easy although asking for some guidance in IRC may be useful since the parser isn't exactly easy to navigate.)
Why do we need to disallow this?
Consistency, maybe? ( suggested it.)
motivation was both consistency and to allow for possible future special uses. In particular I think could possibly be put to better use in the future.

Discussion:
bump(rdr); } return with_str_from(rdr, start, |lifetime_name| { <del> token::LIFETIME(str_to_ident(lifetime_name)) </del> <ins> let ident = str_to_ident(lifetime_name); let tok = &token::IDENT(ident, false); if token::is_any_keyword(tok) && !token::is_keyword(token::keywords::Static, tok) && !token::is_keyword(token::keywords::Self, tok) { fatal_span(rdr, start, rdr.last_pos, ~"invalid lifetime name"); } token::LIFETIME(ident) </ins> }) }

<ins> // Copyright 2013 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. fn foo(a: &'let int) { } //~ ERROR invalid lifetime name fn bar(a: &'static int) { } fn baz<'self>(a: &'self int) { } fn main() { } </ins>
Change:
<!-- 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 --
Can you add the to the code example instead to make it more easily runnable in the future?
claim

Discussion:
GenericArgKind::Const(ct) => { match ct.kind() { ty::ConstKind::Unevaluated(uv) => { <del> let obligations = self.nominal_obligations(uv.def.did, uv.substs); self.out.extend(obligations); let predicate = ty::Binder::dummy(ty::PredicateKind::ConstEvaluatable(ct)); let cause = self.cause(traits::WellFormed(None)); self.out.push(traits::Obligation::with_depth( self.tcx(), cause, self.recursion_depth, self.param_env, predicate, )); </del> <ins> if !ct.has_escaping_bound_vars() { let obligations = self.nominal_obligations(uv.def.did, uv.substs); self.out.extend(obligations); let predicate = ty::Binder::dummy(ty::PredicateKind::ConstEvaluatable(ct)); let cause = self.cause(traits::WellFormed(None)); self.out.push(traits::Obligation::with_depth( self.tcx(), cause, self.recursion_depth, self.param_env, predicate, )); } </ins> } ty::ConstKind::Infer(_) => { let cause = self.cause(traits::WellFormed(None));

<ins> // check-pass // edition:2021 #![feature(generic_const_exprs)] #![allow(incomplete_features)] #[allow(unused)] async fn foo<'a>() { let _data = &mut [0u8; { 1 + 4 }]; bar().await } async fn bar() {} fn main() {} </ins>
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-03-25 <details<summaryCommits in range</summary</details<details<summaryBisection method</summaryI used: With : On x86_64-apple-darwin </details
So this is not the same root cause as ..? Fascinating :smile:
Triage: Fixed on the latest nightly, labels: +E-needs-test

Discussion:
<ins> // check-pass #![feature(generic_const_exprs)] #![feature(inline_const)] #![allow(incomplete_features)] pub struct ConstDefaultUnstable<const N: usize = { const { 3 } }>; pub fn main() {} </ins>
Change:
The 1.66.0 release broke something around the flag to . If I download and extract , and then run, say it errors out with The same thing happens when other components are named in . The install completes successfully when isn't used. It appears the problem is with the new component, because the install is successful with
I think given the workaround this is P-low.
Note that the workaround doesn't work when combined with , so:
also appears to be broken:
Oh: probably not yet:
I think you should reprioritize this issue as this workaround doesn't work when other components are mentioned in argument as mentioned by This issue affects building our internal rust Docker image.
is a potential fix, we'll see if we can get it reviewed. I believe, based on looking at the code, the workaround of passing full names (e.g., rust-analyzer-preview rather than rust-analyzer) or similar should work. makes that required for any effect at all. I'm not quite sure what changed with the addition of rust-docs-json-preview, it might be mostly coincidence that this actually had an effect on your particular invocations.
Should that PR be tagged relnotes? Feels like it may be useful to call out for anyone using
Tagged!
As Rust 1.66.1 still broken, workaround: Other components can be just after the , eg:
We'll aim to backport the PR for 1.67, but we didn't include it in 1.66.1, so that's not surprising that nothing changed.

Discussion:
<del> Subproject commit 300b5ec61ef38855a07e6bb4955a37aa1c414c00 </del> <ins> Subproject commit 5b2eee7eed72b4894909c5eecbf014ea0b5ad995 </ins>
Change:
rustc 1.66.0 requires an executable stack, which is frowned upon for security reasons and for example generally forbidden by SELinux. System: Debian sid (amd64) Execstack allowed: Execstack forbidden: Maybe this is related to PGO or BOLT being enabled? Stack trace:
Can you bisect this using
Clearing the executable stack flag: execstack -c libLLVM-15-rust-1.66.0- seems to work (at least is working correctly as before for the project I'm working on...)
Ran into this today on OpenSuse MicroOS. that workaround works, though I don't understand the ramifications of it.
Probably the library was build on a non-GNU platform (Windows?), so the linker did not add a GNU_STACK program header. (The absence of that header is treated the same as explicitly specifying an executable stack.)
Unfortunately, applying the same workaround on didn't do the trick... The entry in looks like this: Curiously, this works: EDIT: Never mind, I forgot to do a ... :rofl:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
There is no need for reproducing, one can analyze the shared library: should return
The presence of tells the loader to not_ set the stack as executable on legacy systems, so this is an indication of the absence of this bug.
Still seeing this on gentoo/SELinux And no, I don't want to switch off SELinux or enable executable stack system wide. Any ideas? This is a regression as things used to work just fine with older versions of the package...
Since you're on such a system, are you able to use cargo-bisect-rustc to bisect the change? That would be hugely valuable and help actually figuring out what's going on.
Unfortunately no as the system is too resource constraint and I don't have enough RAM to build LLVM from source, hence I'm using the package, and I've tried all currently available versions of it starting from 1.66.1-stable breaks...
You don't need to build anything from source if you have access to rustup. downloads CI artifacts (so it does need internet access). If you can't use it, then it would at least be nice if you could bisect nightlies instead of stables, which are a lot more coarse.
Fedora reproducer: Procedure: Result: Probably cause: Maybe in should include .
cc for that last comment
I don't think that this is caused by missing LLVM linker flags, rather it is caused by BOLT. I used on a BOLT optimized library. When I used the option when optimizing the binary with BOLT, the state of the binary changed from (doesn't require executable stack) to (unknown whether it requires executable stack). Maybe the GNUSTACK attribute confuses SELinux somehow? Perhaps counterintuitively, when is used, the GNUSTACK attribute disappears from the executable.

Discussion:
.arg("-split-all-cold") // Move jump tables to a separate section .arg("-jump-tables=move") <del> // Use GNU_STACK program header for new segment (workaround for issues with strip/objcopy) .arg("-use-gnu-stack") </del> // Fold functions with identical code .arg("-icf=1") // Update DWARF debug info in the final binary
Change:
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.

Discussion:
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
Change:
I'm back. This time I tried concatenating non-literal s. Why? Excellent question, next please. <!-- 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 got another instance of this here: (sorry for the large producer) And this is the error:
Shorter variant that avoids and hits the same ICE: Regression in nightly-2021-12-06. In earlier versions, the compiler reported "error: overly complex generic constant". <details<summaryCommits in range</summary</details
Just to clarify, the issue is almost certainly just in . I have functioning (compiling, at least) code that does array concatenation, extension, etc. using the same pattern as in the first post for array concatenation when the arrays are function arguments instead of const generic parameters.
Update: the issue is somewhere in the use of . I rewrote it without using any and this actually compiles and works: This was as part of trying to confirm the issue was not in . However, as soon as I put the method of joining arrays back in, e.g. and then I get the exact same issue as in what was initially reported.
No longer ICEs since

Discussion:
<ins> // check-pass #![allow(incomplete_features)] #![feature(adt_const_params, const_ptr_read, generic_const_exprs)] #![allow(dead_code)] const fn catone<const M: usize>(_a: &[u8; M]) -> [u8; M + 1] where [(); M + 1]:, { unimplemented!() } struct Catter<const A: &'static [u8]>; impl<const A: &'static [u8]> Catter<A> where [(); A.len() + 1]:, { const ZEROS: &'static [u8; A.len()] = &[0_u8; A.len()]; const R: &'static [u8] = &catone(Self::ZEROS); } fn main() {} </ins>
Change:
rustc --edition: rustc --edition=help: --editionhelprustc --help The default is not mentioned anywhere. I assume it is 2015? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The default is indeed 2015. It should probably not only mention the default (2015) but also the latest stable edition (2021).
Mentoring instructions: modify to include and somewhere.
claim
What is the best way to insert the values for and into the string? only takes 's and I don't see an easy way to create one while inlining those variables. Neither nor works - former only accepts literals rather than the static variable, and the latter would create a &str, but then drop a temporary variable. I don't believe it would be a good idea to simply write the value of these variables into the string, so I'm wondering what other options I have. However, if that's the way forward, I can do so.
Where does that requirement come from? Seems fine to loosen it.
ah I see, the string ends up stored in RustcOptGroup. Honestly, given that this is only used once and the string is tiny, using seems fine.

Discussion:
use std::iter; use std::path::{Path, PathBuf}; use std::str::{self, FromStr}; <ins> use std::sync::LazyLock; </ins> pub mod sigpipe;

unstable(longer(a, b), move |opts| opts.optmulti(a, b, c, d)) } } <ins> static EDITION_STRING: LazyLock<String> = LazyLock::new(|| { format!( "Specify which edition of the compiler to use when compiling code.  The default is {DEFAULT_EDITION} and the latest stable edition is {LATEST_STABLE_EDITION}." ) }); </ins> /// Returns the "short" subset of the rustc command line options, /// including metadata for each option, such as whether the option is /// part of the stable long-term interface for rustc.

opt::opt_s( "", "edition", <del> "Specify which edition of the compiler to use when compiling code.", </del> <ins> &*EDITION_STRING, </ins> EDITION_NAME_LIST, ), opt::multi_s(