jiebi/CodeConvo huggingface dataset:
Change:
/// opaque type. opaque_types_vars: RefCell<FxHashMap<Ty<'tcx>, Ty<'tcx>>>, <del> /// Each type parameter has an implicit region bound that /// indicates it must outlive at least the function body (the user /// may specify stronger requirements). This field indicates the /// region of the callee. If it is `None`, then the parameter /// environment is for an item or something where the "callee" is /// not clear. implicit_region_bound: Option<ty::Region<'tcx>>, </del> body_id: Option<hir::BodyId>, }

Discussion:
I tried this code: I expected to see this happen: On Rust 1.44.0, this compiles. Instead, this happened: :
For reproduction, the following is used.
This is a regression from stable to nightly.
Let’s bisect this and try to find an MCVE. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
The code succeeds to compile on 1.44.1 and fails on 1.45, so this is actually a stable-to-stable regression.
Assigning as and removing .
So far I've reduced it to this, which depends only on (without the feature):
: searched nightlies: from nightly-2020-04-20 to nightly-2020-06-02 regressed nightly: nightly-2020-05-25 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsregressed in
The reproduction does not produce error in . However, I find this throws error on this nightly, as well as on 1.45.0. Here is an even shorter one: The line seems critical. Without this, there will be no reproduction with both snippets. This is also reproducible on the nightly .
cc
The PR that made my reduced code (without ) start successfully compiling again is , in case it helps show what's going on. <details<summaryFull bisect-rustc</summarysearched nightlies: from nightly-2020-05-25 to nightly-2020-07-17 regressed nightly: nightly-2020-06-24 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </summary
Single-crate repro:
I can volunteer myself for looking into the issue. I have a question about the region inference.

Is there a way to visualize, or trace the region inference? Guidance and mentoring instructions are very welcome. :smile:
Change:
// to something unusable as a pattern (e.g., constructor function), // but we still conservatively report an error, see // issues/33118#issuecomment-233962221 for one reason why. <ins> let binding = binding.expect("no binding for a ctor or static"); </ins> self.report_error( ident.span, <del> ResolutionError::BindingShadowsSomethingUnacceptable( pat_src.descr(), ident.name, binding.expect("no binding for a ctor or static"), ), </del> <ins> ResolutionError::BindingShadowsSomethingUnacceptable { shadowing_binding_descr: pat_src.descr(), name: ident.name, participle: if binding.is_import() { "imported" } else { "defined" }, article: binding.res().article(), shadowed_binding_descr: binding.res().descr(), shadowed_binding_span: binding.span, }, ); None } Res::Def(DefKind::ConstParam, def_id) => { // Same as for DefKind::Const above, but here, `binding` is `None`, so we // have to construct the error differently self.report_error( ident.span, ResolutionError::BindingShadowsSomethingUnacceptable { shadowing_binding_descr: pat_src.descr(), name: ident.name, participle: "defined", article: res.article(), shadowed_binding_descr: res.descr(), shadowed_binding_span: self.r.opt_span(def_id).expect("const parameter defined outside of local crate"), } </ins> ); None }

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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
let generator_option = this.generator_movability_for_fn(&decl, fn_decl_span, generator_kind, movability); this.current_item = prev; <del> hir::ExprKind::Closure(capture_clause, fn_decl, body_id, fn_decl_span, generator_option) }) </del> <ins> (body_id, generator_option) }); // Lower outside new scope to preserve `is_in_loop_condition`. let fn_decl = self.lower_fn_decl(decl, None, false, None); hir::ExprKind::Closure(capture_clause, fn_decl, body_id, fn_decl_span, generator_option) </ins> } fn generator_movability_for_fn(

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
Doesn't ICE on stable or beta label: regression-from-stable-to-nightly
searched nightlies: from nightly-2020-11-25 to nightly-2020-11-29 regressed nightly: nightly-2020-11-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsMaybe ?
Assigning and removing as in the prioritization working group.
- would you be up for fixing this bug or temporarily reverting PR presuming it is the cause?
Change:
return Res::Err; } } <del> Res::Def(DefKind::TyParam, _) | Res::SelfTyParam { .. } | Res::SelfTyAlias { .. } | Res::SelfCtor(_) => { </del> <ins> Res::Def(DefKind::TyParam, _) | Res::SelfTyParam { .. } | Res::SelfTyAlias { .. } => { </ins> for rib in ribs { let has_generic_params: HasGenericParams = match rib.kind { RibKind::Normal

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I made a blank cargo project (ran in an empty directory), and dependencies to my like so: Originally when I went to run , I was in nightly, and got a compile error (full error below). Then, when i switched to stable, there was no error and everything built fine! <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.69 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-nightly -regression-untriaged
searched nightlies: from nightly-2023-02-15 to nightly-2023-05-13 regressed nightly: nightly-2023-05-05 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsrollup it didn't want to bisect the perf builds for some reason but i guess or could be at fault? haven't looked into the actual issue in detail, since it's behind a macro you probably know something about this anyways even if it may not be your fault
its not that is genericconstexprs only code
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler
Change:
panic!(ExplicitBug); } pub fn delay_span_bug<S: Into<MultiSpan>>(&self, sp: S, msg: &str) { <ins> if self.treat_err_as_bug { self.span_bug(sp, msg); } </ins> let mut delayed = self.delayed_span_bug.borrow_mut(); *delayed = Some((sp.into(), msg.to_string())); }

Discussion:
hi, my code used to compile last week. I updated the compiler today and now it crashes note that you can get my code here ()
note: going back to nightly-2017-04-01; everything work again. 'nightly-2017-04-17 is not ok. so troubles started somewhere in between.
cc
not too sure what to do with this message. can I help you with something ? I can do a small dichotomy to figure out the last working nightly if this can help.
Minified:
there is a pending fix (), no action needed on your part
triage: P-high
Change:
pub span: Span, } <del> #[derive(Clone, RustcEncodable, RustcDecodable, Debug, Copy)] </del> <ins> // Clippy uses Hash and PartialEq #[derive(Clone, RustcEncodable, RustcDecodable, Debug, Copy, Hash, PartialEq)] </ins> pub enum LitIntType { Signed(IntTy), Unsigned(UintTy),

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
statement.source_info, ); } <ins> } else { trace!("can't propagate {:?} to {:?}", value, local); self.remove_const(local); </ins> } } }

Discussion:
The following code results in a const eval divide by zero error, when it cannot actually error at runtime:
Bisected to , which corresponds to . cc BTW, you need to actually use (e.g. by calling it in ) to trigger the error. Just adding won't do it.
Fun thing, it doesn't even depend on the conditions in the if clause: also ICEs
Thanks
Change:
/// Tests the build system itself. fn run(self, builder: &Builder<'_>) { <ins> let mut check_bootstrap = Command::new(&builder.python()); check_bootstrap.arg("bootstrap_test.py").current_dir(builder.src.join("src/bootstrap/")); try_run(builder, &mut check_bootstrap); </ins> let mut cmd = Command::new(&builder.initial_cargo); cmd.arg("test") .current_dir(builder.src.join("src/bootstrap"))

Discussion:
It's very confusing that this can't actually be run through x.py itself; it tripped me up in See for the existing code and for where it should be moved. label +A-rustbuild +E-easy +E-mentor +E-help-wanted +A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
if let ObligationCauseCode::WellFormed(Some(wf_loc)) = root_obligation.cause.code.peel_derives() { <del> if let Some(cause) = self.tcx.diagnostic_hir_wf_check((obligation.predicate, wf_loc.clone())) { </del> <ins> if let Some(cause) = self.tcx.diagnostic_hir_wf_check(( tcx.erase_regions(obligation.predicate), wf_loc.clone(), )) { </ins> obligation.cause = cause; span = obligation.cause.span; }

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. --When trying to compile this incorrect code using cargo, nightly rustc panics. When compiling using rustc directly without further arguments (or using the same command cargo calls with removed), it outputs an error message instead. I also noticed that changing to will also result in an error message instead of a panic. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I seem to have run into the same issue with this code: <details<summaryBacktrace</summary</details
I believe these ICEs trigger because of / are made visible by cc
I'm not able to repro this with rustc 1.56.0-nightly ( 2021-08-02): Could you verify that you see it with a recent nightly? There have been significant changes in this area recently. Edit: ah! with enabled I see it:
I am able to reproduce my issue and the other one on by simply running :
Change:
/// extract function takes three arguments: a string slice containing the source, an index in /// the slice for the beginning of the span and an index in the slice for the end of the span. fn span_to_source<F>(&self, sp: Span, extract_source: F) -> Result<String, SpanSnippetError> <del> where F: Fn(&str, usize, usize) -> String </del> <ins> where F: Fn(&str, usize, usize) -> Result<String, SpanSnippetError> </ins> { if sp.lo() > sp.hi() { return Err(SpanSnippetError::IllFormedSpan(sp));

Discussion:
When I used the character in comment, combined with some (invalid) code preceding it, the compiler panicked. I tried this code: I expected to see this happen: rustc compiles this code. Instead, this happened: rustc panicked with the following output : Backtrace:
Regressed in 1.34.0. Used to be:
cc
Miminized: Probably some span handcrafting?
Probably some span handcrafting? +1
I was idly curious, so I took a brief look at this. The diagnostic that triggers this was introduced in , but I don't think it is responsible for the error (it's just stepping through characters looking for a closing brace). There is some strange math in  (introduced in ). It oscillates between zero-length and 1+ length spans as it is stepping over characters. When it hits a multi-byte character, it returns an invalid span. Example: Starting with a span of (0,1), using would result in (1,1), then (1,2), then (2,2), then (2,4). That last one slices into the middle of the multi-byte character (because of , where width is 3), causing a panic. I'm not familiar enough with this stuff to say how it should behave. It seems like is being used for two different purposes (getting the next zero-length span, and getting the "next" character), and it's not clear to me what the behavior should be since it is used in a variety of places. I don't think it can be changed to always return zero-length spans, and it can't be changed to always return non-zero length spans. Perhaps there should be two different functions?
triage: P-medium, removing nomination; the ICE to me appears to include enough information for a user to identify the offending character and work-around the problem (namely by getting rid of the character). I do agree with that there should probably be two distinct functions corresponding to the two distinct purposes that they identified for the current callers of .
More test cases have been brought up in
I guess this is the same bug, but the examples I've seen here concern non-ASCII characters in comments. I'm getting a similar rustc panic from an erroneous code without comments: Compilation attempt:
Please file a new issue and reference this one.
I think it's fixed, try .
confirmed fixed by .
Change:
<del> use crate::NameBindingKind; use crate::Resolver; </del> <ins> use crate::{ImportKind, NameBindingKind, Resolver}; </ins> use rustc_ast::ast; use rustc_ast::visit; use rustc_ast::visit::Visitor;

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see no output from the compiler. Instead, this happened: searched nightlies: from nightly-2022-09-22 to nightly-2022-09-27 regressed nightly: nightly-2022-09-25 searched commit range: regressed commit: This is a roll-up, seems the most likely culprit. cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
WG-prioritization assigning priority, probably a P-high since the lint malfunction is blocking valid code (iiuc) label -I-prioritize P-high T-compiler
any ideas how to address this or should I start digging in to it
In HIR desugars into two items (import in type namespace and import in value namespace). One of them is externally reachable and another is not (before both of them were incorrectly marked as externally reachable). Code in should somehow account for this desugaring and not report the as unnecessary if at least one of the imports is reachable.
I have been unable to fix this or apply a revert. can you look at implementing this before the beta cutoff?
Reverted in
Change:
assert_eq!(target, compiler.host); } <del> if self.config.rust_optimize { </del> <ins> if self.config.rust_optimize.is_release() { </ins> // FIXME: cargo bench/install do not accept `--release` if cmd != "bench" && cmd != "install" { cargo.arg("--release");

Discussion:
It would be nice if we could speed up stage1 library builds by building it with less opts and no debuginfo. had the idea to control this with something like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i'm going to use as a separate more broad issue for - i'll repurpose this to just be for (which is a lot simpler to add)
mentoring instructions: add this option to the struct, then around , set
Can we confirm before we land this support that this is actually a significant win in practice? I recall historically having issues with optimize = false equivalents where the net effect is broken and slower tests - I would prefer to avoid landing support we don't want to actually support :)
this is especially useful in combination with - optimizing only rustc and not std should be a speedup even if we include the time taken for tests.
claim
Maybe we should just generalize the config value to a number/boolean, instead of adding a new attribute?
Change:
if self.eat(&token::Semi) { stmt_span = stmt_span.with_hi(self.prev_span.hi()); } <del> let sugg = pprust::to_string(|s| { use crate::print::pprust::INDENT_UNIT; s.ibox(INDENT_UNIT); s.bopen(); s.print_stmt(&stmt); s.bclose_maybe_open(stmt.span, false) }); e.span_suggestion( stmt_span, "try placing this code inside a block", sugg, // speculative, has been misleading in the past (closed Issue #46836) Applicability::MaybeIncorrect ); </del> <ins> if let Ok(snippet) = self.sess.source_map().span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // speculative, has been misleading in the past (#46836) Applicability::MaybeIncorrect, ); } </ins> } Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore);

Discussion:
I'm seeing the following error on the channel, but not on or : Found with the help of .
triage: P-medium. Leaving nominated so that team double-checks that priority assignment.
This is triggered here It should be possible to use the span snippet instead. I believe it was introduced in
Change:
/// _ #[doc = "```"] pub fn crazy_attrs() {} <ins> /// ```rust /// ``` pub fn empty_rust() {} /// ``` /// /// /// ``` pub fn empty_rust_with_whitespace() {} </ins>

Discussion:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.
Change:
use rustc_hir::def::{CtorKind, DefKind, Res}; use rustc_hir::def_id::DefId; use rustc_hir::intravisit::Visitor; <del> use rustc_hir::{ExprKind, QPath}; </del> <ins> use rustc_hir::{ExprKind, HirId, QPath}; </ins> use rustc_infer::infer; use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use rustc_infer::infer::InferOk;

Discussion:
Lets consider the following code () : Here, we try to access a property on an object of type . Up to the 1.50 version, the error message was the following : However, since Rust 1.51 and onward, the diagnostic message changed to this: While there is indead a property on the struct, this can't be accessed like that, applying the compiler suggestion implies making the property of public, which is not possible. The compiler should not look at non- properties when searching for properties with a matching name for diagnostic purposes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
Related issue:
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. #![feature(struct_variant)] mod a { pub enum Enum { EnumStructVariant { x: u8, y: u8, z: u8 } } pub fn get_enum_struct_variant() -> () { EnumStructVariant { x: 1, y: 2, z: 3 } //~^ ERROR mismatched types: expected `()`, found `a::Enum` (expected (), found enum a::Enum) } } mod b { mod test { use a; fn test_enum_struct_variant() { let enum_struct_variant = ::a::get_enum_struct_variant(); match enum_struct_variant { a::EnumStructVariant { x, y, z } => { //~^ ERROR error: mismatched types: expected `()`, found a structure pattern } } } } } fn main() {} </ins>

Discussion:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

(Doesn't happen with .)
Paging
Here's a truly minimal test case:
cc me
Variation: This gives a different error message:
Fixed in Can be closed.