jiebi/CodeConvo huggingface dataset:
Change:
/// ``` #[lang = "index_mut"] #[rustc_on_unimplemented( <ins> on( _Self="&str", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), on( _Self="str", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), on( _Self="std::string::String", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), </ins> message="the type `{Self}` cannot be mutably indexed by `{Idx}`", label="`{Self}` cannot be mutably indexed by `{Idx}`", )]

Discussion:
The following buggy code: produces the error: This is usefully documented in TRPL (ch08-02-strings), but that is not easily discoverable from the error. Meanwhile, the error itself is a natural one that programmers from many languages (C, C++, etc) might run into. Speaking as someone who spent some time assuming that the issue was related to slices/references/usize (i.e. various new, Rust-specific concepts), not strings and UTF-8 encoding, I wonder whether a special case might be produced, replacing error E0277, when the types involved are specifically strings/strs and integers. :
We should add a pointing to in the following code of E0277 errors. The example has a similar case to this one, but the additional code should be something along the lines of This will cause an extra to be displayed for this case. Beyond changing the code, you will also need to add a new test case with the repro case above and (running and possibly updating the test comments for any remaining failing tests).
I would like to work on this.
do not hesitate to reach out either here or on if you need help!
Possible proposed output from :
Change:
/// This method is idempotent, but it not typically not invoked /// except during the writeback phase. pub fn fully_resolve<T: TypeFoldable<TyCtxt<'tcx>>>(&self, value: T) -> FixupResult<'tcx, T> { <del> let value = resolve::fully_resolve(self, value); assert!( value.as_ref().map_or(true, |value| !value.has_infer()), "`{value:?}` is not fully resolved" ); value </del> <ins> match resolve::fully_resolve(self, value) { Ok(value) => { if value.has_non_region_infer() { bug!("`{value:?}` is not fully resolved"); } if value.has_infer_regions() { let guar = self .tcx .sess .delay_span_bug(DUMMY_SP, format!("`{value:?}` is not fully resolved")); Ok(self.tcx.fold_regions(value, |re, _| { if re.is_var() { ty::Region::new_error(self.tcx, guar) } else { re } })) } else { Ok(value) } } Err(e) => Err(e), } </ins> } // Instantiates the bound variables in a given binder with fresh inference

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
label +E-needs-mcve
Minimized to:
might be similar to , cc who self-assigned and probably knows more about this stuff ^^
in case we need more code snippets, here are 60 of them that that can trigger the ice in some way or another :upsidedownface:
I'm pretty sure all (or at least most) of these examples are not related. This issue is specifically the case where the code used to emit: and now ICEs. is unrelated except for the ICE message.
Ah so this () is a new one? Need to put some though into automatic ice distinction (perhaps based on query stack?)
Yeah, there's a class of ICEs that have the same name and often very different root causes (i.e. ICEs in snapshot-vec) and this is one of them.
Change:
warn_if_doc(cx, arm_span, "match arms", &arm.attrs); } <ins> fn check_pat(&mut self, cx: &EarlyContext<'_>, pat: &ast::Pat) { if let ast::PatKind::Struct(_, _, fields, _) = &pat.kind { for field in fields { warn_if_doc(cx, field.span, "pattern fields", &field.attrs); } } } </ins> fn check_expr(&mut self, cx: &EarlyContext<'_>, expr: &ast::Expr) { warn_if_doc(cx, expr.span, "expressions", &expr.attrs); <ins> if let ExprKind::Struct(s) = &expr.kind { for field in &s.fields { warn_if_doc(cx, field.span, "expression fields", &field.attrs); } } </ins> } fn check_generic_param(&mut self, cx: &EarlyContext<'_>, param: &ast::GenericParam) {

Discussion:
The same warning is produced at other places like statements, expressions, functions etc. For completeness and consistency it should be produced for pattern and expression fields too. No response rustc 1.74.0-nightly ( 2023-09-01) binary: rustc commit-hash: commit-date: 2023-09-01 host: x8664-pc-windows-msvc release: 1.74.0-nightly LLVM version: 17.0.0 rustc version older than 1.74.0 may ICE on this code. The ICE was fixed in 1.74.0 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reason these warnings are not produced is because the lint infrastructure currently exposes no hooks for and , i.e. there are no and methods on (or for that matter). To fix the issue, these methods may have to be here: and then invoked from here: and here: Alternatively, we can emit the warning from the already existing and methods of and not bother with the above changes at all.
Yeah, I would expect this is the best way of doing it.
claim
label -needs-triage
Change:
} #[derive(Diagnostic)] <ins> #[diag(passes_linkage)] pub struct Linkage { #[primary_span] pub attr_span: Span, #[label] pub span: Span, } #[derive(Diagnostic)] </ins> #[diag(passes_empty_confusables)] pub(crate) struct EmptyConfusables { #[primary_span]

Discussion:
I tried this code: I expected to see this happen: compilation failure because of attribute on an item where it makes no sense Instead, this happened: compiled successfully : cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
/// intent. pub LET_UNDERSCORE_DROP, Allow, <del> "non-binding let on a type that implements `Drop`" </del> <ins> "non-binding let on a type that has a destructor" </ins> } declare_lint! {

Discussion:
I tried this code: I got this warning: However, there is no impl on the type, so the error message is misleading. It is true however that there is a destructor, as defined here: That being said, it's insiginificant for all underlying types (only destructor of and type in the ), so ideally the warning still wouldn't even show. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Well, even if the parameter of is , it still has a side-effect (deallocates memory). I don't think we need this special-casing. I do think the diagnostic is a bit misleading and should just say "has a destructor" or "has side-effects when dropped". Is there a more practical code example for why you'd want to suppress this error? The example you gave is a bit artificial, so it's a hard to motivate why we'd want to suppress this code since it really could be rewritten to be clearer.
claim
Change:
use common::{CodegenCx, val_ty}; use declare; use monomorphize::Instance; <ins> use syntax_pos::Span; use syntax_pos::symbol::LocalInternedString; </ins> use type_::Type; use type_of::LayoutLlvmExt; <del> use rustc::ty; </del> <ins> use rustc::ty::{self, Ty}; </ins> use rustc::ty::layout::{Align, LayoutOf}; <del> use rustc::hir::{self, CodegenFnAttrFlags}; </del> <ins> use rustc::hir::{self, CodegenFnAttrs, CodegenFnAttrFlags}; </ins> use std::ffi::{CStr, CString};

Discussion:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by
Change:
<ins> error: argument to `panic!()` in a const context must have type `&str` --> $DIR/issue-85907.rs:2:5 | LL |     panic!(123); |     ^^^^^^^^^^^ | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>

Discussion:
Playground: <details<summaryOutput</summary</detailscc
Ah, yes, array lengths... this is like
Cc
This ICEs on stable: I thought we have an issue for this somewhere? Basically, array lengths (and patterns) side-step all prior checks, including stability checks, and try to evaluate this constant anyway.
Hmm
No longer ICEs since
Change:
use rustc_data_structures::fx::FxHashMap; use rustc_index::vec::IndexVec; use rustc::ty::layout::{ <del> LayoutOf, TyLayout, LayoutError, HasTyCtxt, TargetDataLayout, HasDataLayout, </del> <ins> LayoutOf, TyLayout, LayoutError, HasTyCtxt, TargetDataLayout, HasDataLayout, Size, </ins> }; use crate::rustc::ty::subst::Subst;

Discussion:
The following ICEs on beta and nightly: () <details<summarygdb backtrace </summary</details
triage: P-high.

A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.
Change:
// // This can be conveniently accessed by methods on `tcx.hir()`. // Avoid calling this query directly. <del> query hir_owner_nodes(key: LocalDefId) -> &'tcx crate::hir::OwnerNodes<'tcx> { </del> <ins> query hir_owner_nodes(key: LocalDefId) -> Option<&'tcx crate::hir::OwnerNodes<'tcx>> { </ins> eval_always desc { |tcx| "HIR owner items in `{}`", tcx.def_path_str(key.to_def_id()) } }

Discussion:
As of rustc 1.43.0-nightly ( 2020-03-15) the Travis CI builds of are failing due to rustc crashing. The crash happens when building the crate, which is a dependency of one of quiche's subcrates. Unfortunately I wasn't able to reproduce this locally, so I can't try the latest master or try to prepare a minimal reproducer, but I can reproduce this realiably on Travis CI, see e.g. https://travis- https://travis- https://travis- https://travis- Could this have something to do with Travis CI specifically? As per above, I don't have specific code that reproduces this. I can only reproduce when building the crate as part of quiche on Travis CI. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FTR, the docopt crate was last updated almost a year ago, so this is not due to some new code there
Let's see if we can shrink the input to something suitable for a regression test. ping cleanup Also cc
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
This seems to be an issue with It could be we're calling with something that isn't an HIR owner, in which case it should be changed to return instead of panicking. It's odd that it can't be reproduced though.
I can reproduce it by on
I just realized I wasn't actually using rust nightly when I tried to reproduce locally :man_facepalming: so that explains that...
Minimized:
assign
Change:
MACOSX_STD_DEPLOYMENT_TARGET=10.7 os: osx osx_image: xcode8.2 <del> install: > travis_retry curl -o /usr/local/bin/sccache https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-03-16-sccache-x86_64-apple-darwin && chmod +x /usr/local/bin/sccache </del> <ins> install: *osx_install_sccache </ins> - env: > RUST_CHECK_TARGET=dist RUST_CONFIGURE_ARGS="--target=aarch64-apple-ios,armv7-apple-ios,armv7s-apple-ios,i386-apple-ios,x86_64-apple-ios --enable-extended"

Discussion:
Often when debugging travis logs it's difficult to see how long everything is taking as we only time some steps, not all. Additionally there's not a lot of information to see how long it takes between steps. It'd be awesome if we had a tool where we basically wrapped the entire build () in a process that simply prepended all stdout/stderr messages with a relative timestamp. AppVeyor does this by default (has a timestamp for each log line message) but unfortunately Travis doesn't. Apparently which ends up looking like https://travis- which is basically exactly what we'd want.
You probably just want to use from moreutils for this. (This is what Julia does.)
Change:
<ins> error[E0433]: failed to resolve: `clippy` is a tool module, not a module --> $DIR/tool-import.rs:3:5 | LL | use clippy::time::Instant; |     ^^^^^^ `clippy` is a tool module, not a module error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </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
works with any tool attr also compiles but it probably... shouldn't.
label +S-bug-has-mcve
Triaged with . Steps performed: Reproduced: Formatted: No change, already formatted Reduced: Bisected: Regression in nightly-2022-04-17 couldn't nail down the particular commit: <details<summaryDetails</summary<prustc version: Icemelter version: v0.2.0 Icemelter command line: Do you have feedback about this report? Please ! </p</details
another one `
Change:
<ins> error: expected one of `async`, `extern`, `fn`, or `unsafe`, found keyword `pub` --> $DIR/issue-86895.rs:1:7 | LL | const pub () {} |       ^^^ expected one of `async`, `extern`, `fn`, or `unsafe` error: aborting due to previous error </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2021-02-10 to nightly-2021-05-01 regressed nightly: nightly-2021-03-19 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: </detailsIt looks like is when this error started happening. cc
I'm going to take a look at this. claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Change:
<ins> use clippy::a; //~ ERROR unresolved import `clippy` use clippy::a::b; //~ ERROR failed to resolve: maybe a missing crate `clippy`? use rustdoc::a; //~ ERROR unresolved import `rustdoc` use rustdoc::a::b; //~ ERROR failed to resolve: maybe a missing crate `rustdoc`? fn main() {} </ins>

Discussion:
Happens on stable and nightly. Compiler crash <details<summary<strongBacktrace</strong</summary<p</p</details
This regression looks to be really old. Could not pinpoint a specific commit while bisecting
I don't think this is a regression, the flag just didn't exist before 1.31 (the panic doesn't occur without ).
Assigning and removing as in the prioritization working group. label: +P-low -I-prioritize
Change:
let start_of_next_point = sp.hi().0; let width = self.find_width_of_character_at_span(sp, true); <del> if width == 0 { return Span::new(sp.hi(), sp.hi(), sp.ctxt(), None); } </del> // If the width is 1, then the next span should only contain the next char besides current ending. // However, in the case of a multibyte character, where the width != 1, the next span should // span multiple bytes to include the whole character.

Discussion:
This malformed code () hangs the compiler: Found by fuzzing with a . must be defined as a named-field struct (not a tuple struct or unit struct), although it can have 0 fields. must be the last token to produce the hang: No opening brace (note that braces are required for literals of named-field structs) No closing delimiters Not even a comment If I understand correctly, the hang occurs in LateResolutionVisitor, with never finishing (while calling various functions such as and ) This also hangs. I'm guessing it's the same bug. : with: <details</summary<p</p</detailsregressed nightly: nightly-2022-10-21 regressed commit: (PR ) label +regression-from-stable-to-nightly +I-hang <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I can not reproduce it with latest code, did I missed anything?
Great cactch Confirmed the error is only triggered by commit: The root cause is I changed the edge corner case in : We think won't return a span which outside of source file, so is a valid one, then will always return a valid span, and we get from when reaching the end of source. So, there is a loop in previous , which will run infinitely loop: Lucky, my another PR merged at last day, this PR refactored this function:
Verif, I no longer get a hang after rollup Do you want to add one or two of these as tests?
Yes, we'd better add a testcase for it. I'm thinking whether we sould in when reaching to the end of source, so that may get an error.
This testcase seems not easy to be : If so, the trigger point will do not exist,
label -I-prioritize
There's an alternative kind of annotation for patterns that should work for this case:
Change:
bug!("Only valid to do a DynStar cast into a DynStar type") }; let vtable = get_vtable(bx.cx(), source.ty(self.mir, bx.tcx()), trait_ref); <ins> let vtable = bx.pointercast(vtable, bx.cx().type_ptr_to(bx.cx().type_isize())); // FIXME(dyn-star): this is probably not the best way to check if this is // a pointer, and really we should ensure that the value is a suitable // pointer earlier in the compilation process. let data = match operand.layout.pointee_info_at(bx.cx(), Size::ZERO) { Some(_) => bx.ptrtoint(data, bx.cx().type_isize()), None => data, }; </ins> OperandValue::Pair(data, vtable) } mir::CastKind::Pointer(

Discussion:
Example: This fails in LLVM:
label +C-bug +A-LLVM +requires-nightly
Change:
} /// in various error cases, we just set ty_err and return an obligation <del> /// that, when fulfilled, will lead to an error </del> <ins> /// that, when fulfilled, will lead to an error. /// /// FIXME: the ty_err created here can enter the obligation we create, /// leading to error messages involving ty_err. </ins> fn normalize_to_error<'a,'tcx>(selcx: &mut SelectionContext<'a,'tcx>, projection_ty: ty::ProjectionTy<'tcx>, cause: ObligationCause<'tcx>,

Discussion:
Hello folks, I'm dutifully reporting this as the compiler told me to so. The bug is the same reported already by and , although it appeared on a different circumstance. I have this simple program (I'm a Rust newbie so It's very likely I'm doing things terribly wrong): Expected outcome: The compile to tell me how wrong I am Actual outcome: Meta Shows up with latest beta as well:
cc me
Minified: We do write tyerr to node 11 (). Apparently we somehow don't report an error.
triage: P-medium
Whoops. There is indeed an error, which is indeed gets to reportselectionerror, but when we do (), we get an error, and think this one was a duplicate.
no_std version:
You don't even need the trait:
Change:
ast::ExprUnary(ast::UnNot, ref inner) => { match try!(eval_const_expr_partial(tcx, &**inner, ety)) { const_int(i) => const_int(!i), <del> const_uint(i) => const_uint(!i), </del> <ins> const_uint(i) => const_uint_not(i, expr_uint_type), </ins> const_bool(b) => const_bool(!b), const_str(_) => signal!(e, NotOnString), const_float(_) => signal!(e, NotOnFloat),

Discussion:
This affects the test suites for the and crates.
triage: I-wrong, P-high (1.0)
triage: P-high (1.0)
I ended up adding the 1.0 milestone by hand; isn't the above note with supposed to do it?
cc
the log above says that highfive did add this to the 1.0 milestone - it might just have been that your local view of the webpage needed refreshing?
yeah I guess so, I don't know what happened anymore. Maybe I should have given highfive a little more time to react.
Change:
use unstable::run_in_bare_thread; use super::*; use rt::task::Task; <del> use rt::local_ptr; </del> #[test] fn thread_local_task_smoke_test() {

Discussion:
Former-XXXes say "is this right?"
Clearing milestone because it's not obviously blocking anything. -- what test case(s) would answer the question you asked in a comment ("is this right?")?
Visiting for triage; FIXMEs are still there.

We should add some sort of special comment like . Here is the hashcode of the current snapshot. The build system can then issue warnings if such a comment exists and is not still the current snapshot.
do you still feel that this would be useful?
Still seems useful to me.
Still very useful.
(bug triage) This would be nice, but is not a blocker.
Change:
<ins> -include ../tools.mk # This test verifies that rustdoc doesn't ICE when it encounters an IO error # while generating files. Ideally this would be a rustdoc-ui test, so we could # verify the error message as well. OUTPUT_DIR := "$(TMPDIR)/rustdoc-io-error" # Ignore Windows: the test uses `chmod`. ifndef IS_WINDOWS # This test operates by creating a temporary directory and modifying its # permissions so that it is not writable. We have to take special care to set # the permissions back to normal so that it's able to be deleted later. all: mkdir -p $(OUTPUT_DIR) chmod u-w $(OUTPUT_DIR) -$(shell $(RUSTDOC) -o $(OUTPUT_DIR) foo.rs) chmod u+w $(OUTPUT_DIR) exit $($(.SHELLSTATUS) -eq 1) else all: endif </ins>

Discussion:
When running cargo doc, rustc panics if disk is full. Not a huge issue, just an invalid call of and since the message says it's a bug, I'm filling a report. Error message (with removed file path): Might be related to somehow?
This also happened with me today. The compiler starts panicing if you try to, Generate Documentation, Run, Compile or run . Maybe It should print a clear message and exit instead of panicing like that. Rust Version: