jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: character literal may only contain one codepoint --> $DIR/whitespace-character-literal.rs:5:30 | LL |     let _hair_space_around = ' x​'; |                              ^--^ |                               | |                               help: consider removing the non-printing characters: `x` | note: there are non-printing characters, the full sequence is `u{200a}xu{200b}` --> $DIR/whitespace-character-literal.rs:5:31 | LL |     let _hair_space_around = ' x​'; |                               ^^ error: aborting due to previous error </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to -- (which has a zero width space between the and its ending ) The current output is: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --If there are any non-printing characters, show where they are (debug unicode representation on the whole string, maybe?), and if there's only one printing character, make a suggestion to remove everything but the printing character. <!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> pub struct Data([u8]); fn main(){ const _: *const Data = &[] as *const Data; //~^ ERROR: casting `&[_; 0]` as `*const Data` is invalid } </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. --: On playgrounds it seemed to affect and for , and . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like it also happens without the re-borrow, but with a different error. <details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2021-11-14 found 7 bors merge commits in the specified range commit[0] 2021-11-12: Auto merge of - matthiaskrgr:rollup-ou6yrlw, r=matthiaskrgr commit[1] 2021-11-13: Auto merge of - workingjubilee:use-simd, r=MarkSimulacrum commit[2] 2021-11-13: Auto merge of - jfrimmel:rtcopychecks, r=Mark-Simulacrum commit[3] 2021-11-13: Auto merge of - mystor:expandliteral, r=petrochenkov commit[4] 2021-11-13: Auto merge of - the8472:privatize-the-means-of-rawvec-production, r=joshtriplett commit[5] 2021-11-13: Auto merge of - jhpratt:stabilize-constrawptrderef, r=oli-obk commit[6] 2021-11-13: Auto merge of - mfrw:mfrw/librustdoc, r=GuillaumeGomez ERROR: no CI builds available between and within last 167 days
Regression in nightly-2019-06-17 found 7 bors merge commits in the specified range commit[0] 2019-06-15: Auto merge of - RalfJung:cfg-if,

r=alexcrichton commit[1] 2019-06-16: Auto merge of - Centril:rollup-3p3m2fu, r=Centril commit[2] 2019-06-16: Auto merge of - matthewjasper:optimize-false-edges, r=pnkfelix commit[3] 2019-06-16: Auto merge of - chansuke:separate-unit-tests, r=petrochenkov commit[4] 2019-06-16: Auto merge of - nikomatsakis:trait-caching-perf-3, r=pnkfelix commit[5] 2019-06-16: Auto merge of - glaubitz:sparc64-ffi-abi, r=petrochenkov commit[6] 2019-06-16: Auto merge of - Centril:stabilize-underscoreconstnames, r=petrochenkov ERROR: no CI builds available between and within last 167 days
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This also returns ICE, but ICE message varies between rustc version.
Change:
return self.tcx.ty_error(); } <del> // Now that we know the types can be unified we find the unified type // and use it to type the entire expression. let common_type = self.resolve_vars_if_possible(lhs_ty.or(rhs_ty).unwrap_or(expected)); </del> <ins> // Unify each side with `expected`. </ins> // Subtyping doesn't matter here, as the value is some kind of scalar. <del> let demand_eqtype = |x, y| { if let Some((_, x_ty, x_span)) = x { </del> <ins> let demand_eqtype = |x: &mut _, y| { if let Some((ref mut fail, x_ty, x_span)) = *x { </ins> if let Some(mut err) = self.demand_eqtype_pat_diag(x_span, expected, x_ty, ti) { if let Some((_, y_ty, y_span)) = y { self.endpoint_has_type(&mut err, y_span, y_ty); } err.emit(); <ins> *fail = true; </ins> }; } }; <del> demand_eqtype(lhs, rhs); demand_eqtype(rhs, lhs); </del> <ins> demand_eqtype(&mut lhs, rhs); demand_eqtype(&mut rhs, lhs); if let (Some((true, ..)), _) | (_, Some((true, ..))) = (lhs, rhs) { return self.tcx.ty_error(); } </ins> <del> common_type </del> <ins> // Find the unified type and check if it's of numeric or char type again. // This check is needed if both sides are inference variables. // We require types to be resolved here so that we emit inference failure // rather than "_ is not a char or numeric". let ty = self.structurally_resolved_type(span, expected); if !(ty.is_numeric() || ty.is_char() || ty.references_error()) { if let Some((ref mut fail, _, _)) = lhs { *fail = true; } if let Some((ref mut fail, _, _)) = rhs { *fail = true; } self.emit_err_pat_range(span, lhs, rhs); return self.tcx.ty_error(); } ty </ins> } fn endpoint_has_type(&self, err: &mut DiagnosticBuilder<'_>, span: Span, ty: Ty<'_>) {

Discussion:
currently throws E0029: while it should infer the constant to be . modify labels: +T-compiler +A-inference claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think this is incorrect. doesn't refer to a specific constant, it's just an abstract associated constant. works fine.
Hmm, does work, though. But does not. It does seem inconsistent that works and doesn't.
is just , so type inference should kick in here. In fact you can write and inference works just fine. The issue only happens when used in range patterns. I am prototyping a fix right now and it seems that the issue is just that E0029 check happens a little bit early (before unification is performed).
Change:
self.bump(); } if self.scan_digits(10, 10) == 0 { <del> self.err_span_(self.pos, self.next_pos, "expected at least one digit in exponent") </del> <ins> let mut err = self.struct_span_fatal( self.pos, self.next_pos, "expected at least one digit in exponent" ); if let Some(ch) = self.ch { // check for e.g. Unicode minus '−' (Issue #49746) if unicode_chars::check_for_substitution(self, ch, &mut err) { self.bump(); self.scan_digits(10, 10); } } err.emit(); </ins> } } }

Discussion:
This code: () Looks pretty identical to this code: But the first one doesn't compile because I accidentally used a unicode minus sign (−) instead of a dash (-). This happened to me when I pasted a constant from Wikipedia. We already produce an error about things like this in other cases. For example with an en space: We produce the following: Maybe we could do the same for the minus sign since it is a pretty confusing error to receive?
The unicode minus sign is already on the list of similar characters: However it looks like it doesn't work in this context.
Change:
<ins> error[E0521]: borrowed data escapes outside of closure --> $DIR/issue-78262.rs:12:26 | LL |     let f = |x: &dyn TT| x.func(); |              -           ^^^^^^^^ `x` escapes the closure body here |              | |              `x` is a reference that is only valid in the closure body error: aborting due to previous error </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. --: This bug also exists at . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Output on 1.46: Changing the closure argument type to compiles successfully on both verions. modify labels: +A-diagnostics +A-lifetimes +regression-from-stable-to-stable
With instead of it compiles successfully too. <details<summaryCode</summary</details
We probably have to check for closures in here.
Assigning as and removing I-prioritize.
Change:
<ins> error[E0282]: type annotations needed for `Value<Rc<_>>` --> $DIR/deref-ambiguity-becomes-nonambiguous.rs:31:9 | LL |     let var_fn = Value::wrap(); |         ^^^^^^ ... LL |     let _ = var_fn.clone(); |                    ----- type must be known at this point | help: consider giving `var_fn` an explicit type, where the placeholders `_` are specified | LL |     let var_fn: Value<Rc<_>> = Value::wrap(); |               ++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </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. --It seems this is a particularly tricky interaction of , coercion and these two ; take away any one, and the compiler spits out a type annotation error as seen below. The compiler is also happy if is annotated as but I don't quite understand why this needs to be specified, given the inner casts on both branches. <!-- 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
reduced a bit
Regression in nightly-2020-06-24
This is minimized in the sense that spurious errors are avoided: The problem here is that the autoderef of a method is interacting strangely with the obligation registered by the line. This actually guides inference in such a way that an assertion in the compiler is not upheld -- that assertion is kinda nonsense though, so I'm just gonna rework it.
I've tried bisecting to a narrower point but didn't get far: commit[0] 2020-06-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[1] 2020-06-22: Auto merge of - Aaron1011:revert/move-fn-self-msg, r=Manishearth commit[2] 2020-06-23: Auto merge of - yoshuawuyts:socketaddr-from-string-u16, r=sfackler commit[3] 2020-06-23: Auto merge of - Dylan-DPC:rollup-b4wbp42, r=Dylan-DPC commit[4] 2020-06-23: Auto merge of - Manishearth:rollup-68dr8fz, r=Manishearth commit[5] 2020-06-23: Auto merge of - ollie27:rustdocaliasfilter, r=GuillaumeGomez So I guess one , or WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
.emit(); } EscapeError::MoreThanOneChar => { <del> let (prefix, msg) = if mode.is_bytes() { ("b", "if you meant to write a byte string literal, use double quotes") } else { ("", "if you meant to write a `str` literal, use double quotes") }; </del> <ins> use unicode_normalization::{char::is_combining_mark, UnicodeNormalization}; </ins> <del> handler .struct_span_err( span_with_quotes, "character literal may only contain one codepoint", ) .span_suggestion( </del> <ins> let mut has_help = false; let mut handler = handler.struct_span_err( span_with_quotes, "character literal may only contain one codepoint", ); if lit.chars().skip(1).all(|c| is_combining_mark(c)) { let escaped_marks = lit.chars().skip(1).map(|c| c.escape_default().to_string()).collect::<Vec<_>>(); handler.span_note( span, &format!( "this `{}` is followed by the combining mark{} `{}`", lit.chars().next().unwrap(), pluralize!(escaped_marks.len()), escaped_marks.join(""), ), ); let normalized = lit.nfc().to_string(); if normalized.chars().count() == 1 { has_help = true; handler.span_suggestion( span, &format!( "consider using the normalized form `{}` of this character", normalized.chars().next().unwrap().escape_default() ), normalized, Applicability::MachineApplicable, ); } } if !has_help { let (prefix, msg) = if mode.is_bytes() { ("b", "if you meant to write a byte string literal, use double quotes") } else { ("", "if you meant to write a `str` literal, use double quotes") }; handler.span_suggestion( </ins> span_with_quotes, msg, format!("{}"{}"", prefix, lit), Applicability::MachineApplicable, <del> ) .emit(); </del> <ins> ); } handler.emit(); </ins> } EscapeError::EscapeOnlyChar => { let (c, char_span) = last_char();

Discussion:
I tried to compile the following code (): For the avoidance of doubt, is . I expected the code to compile—but instead, the literal is rejected: Notably, it is accepted if unicode-escaped: :
The spade "character" in your code is not just a single U+2660, it also has a unicode variation selector U+FE0F: On my machine at least, this makes a visible difference in appearance (which github tries to eliminate by adding a U+FE0F unless I "escape" with a code block):
D'oh! Good spot, thanks Perhaps some improved diagnostics could have helped here?
We have similar diagnostics in other cases of misleading Unicode so that seems like a good idea.
Change:
if place.local == ty::CAPTURE_STRUCT_LOCAL && let Some((&mir::ProjectionElem::Field(idx, _), projection)) = place.projection.split_first() <del> && let Some(&(remapped_idx, remapped_ty, needs_deref, bridging_projections)) = </del> <ins> && let Some(&(remapped_idx, remapped_ty, peel_deref, ref bridging_projections)) = </ins> self.field_remapping.get(&idx) { // As noted before, if the parent closure captures a field by value, and // the child captures a field by ref, then for the by-move body we're // generating, we also are taking that field by value. Peel off a deref, // since a layer of ref'ing has now become redundant. <del> let final_projections = if needs_deref { </del> <ins> let final_projections = if peel_deref { </ins> let Some((mir::ProjectionElem::Deref, projection)) = projection.split_first() else { bug!(

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir --edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'', 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-async_closure
nightly-2024-05-23 =
With this full minimization: The real blame commit is:
Change:
let base_intern_mode = match intern_kind { InternKind::Static(mutbl) => InternMode::Static(mutbl), // FIXME: what about array lengths, array initializers? <del> InternKind::Constant | InternKind::ConstProp | InternKind::Promoted => { InternMode::ConstBase } </del> <ins> InternKind::Constant | InternKind::Promoted => InternMode::ConstBase, </ins> }; // Type based interning.

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from ./src/test/ui/consts/constconstructor/const-construct- <!-- 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. --rustc @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Might be caused by That should have reduced the number of ICEs, not increased it, but who knows.^^

<!-- 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. --core reduced from <!-- 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. --: repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This does not reproduce with though, so it's a very recent regression.
` produces the same error it seems.
Change:
<ins> error: `start` is not allowed to be `#[track_caller]` --> $DIR/error-with-start.rs:4:1 | LL |   #[track_caller] |   ^^^^^^^^^^^^^^^ LL | / fn start(_argc: isize, _argv: *const *const u8) -> isize { LL | |     panic!("{}: oh no", std::panic::Location::caller()); LL | | } | |_- `start` is not allowed to be `#[track_caller]` error: aborting due to previous error </ins>

Discussion:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .
Change:
<ins> error[E0507]: cannot move out of static item `settings_dir` --> $DIR/issue-64453.rs:15:37 | LL |     let settings_data = from_string(settings_dir); |                                     ^^^^^^^^^^^^ move occurs because `settings_dir` has type `std::string::String`, which does not implement the `Copy` trait error[E0019]: static contains unimplemented expression type --> $DIR/issue-64453.rs:4:31 | LL | static settings_dir: String = format!(""); |                               ^^^^^^^^^^^ | = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) error[E0015]: calls in statics are limited to constant functions, tuple structs and tuple variants --> $DIR/issue-64453.rs:4:31 | LL | static settings_dir: String = format!(""); |                               ^^^^^^^^^^^ | = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) error[E0015]: calls in statics are limited to constant functions, tuple structs and tuple variants --> $DIR/issue-64453.rs:4:31 | LL | static settings_dir: String = format!(""); |                               ^^^^^^^^^^^ | = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) error: aborting due to 4 previous errors Some errors have detailed explanations: E0015, E0019, E0507. For more information about an error, try `rustc --explain E0015`. </ins>

Discussion:
err : code i was compiling : rest code lives at
Can you please check the beta & nightly compilers to see if you can reproduce? Also, if you can reproduce it, can you provide a backtrace (instructions in the ICE) and try to minimize the reproducer (start by adding instead of method bodies one by one and binary search your way by removing code)?
cc
after rebooting my issue seem to be gone , but i believe i should leave issue open for investigation , and beta channel test i could not test that as issue was resolved after my laptop rebooted due to system update , i apologize of being unhelpful ! , i will keep on testing and update you if i encounter any issue
maybe it wasn't the reboot, but did you execute in between? Then it may be a incremental compilation issue.
its the first time i am seeing that cargo has clean command
I ran , and still got the same compiler error. This is the code code:
Both code used file I/O library. In my case, my code worked before I applied writing files. Maybe borrowing check makes an error in writing files in current rust nightly compiler. My compiler environment is :
Minimized it:
It has been introduced <strikesomewhere between ...</strikein It has been fixed <strikesomewhere between ...</strikein
triage: stable-to-stable regression. Fixed in beta. Once release happens (scheduled for next week), it will be fixed.
(only remaining question I have is whether to add the reduced example as a regression test or not. The looks different enough from that I think a regression test may be warranted.)
Change:
#[doc = "Goodbye!"] /// Hello again! pub struct S2; <ins> // @has 'foo/struct.S3.html' // @snapshot S3_top-doc - '//details[@class="rustdoc-toggle top-doc"]/div[@class="docblock"]' /** Par 1 */ /// /// Par 2 pub struct S3; </ins>

Discussion:
See the test in . This code: renders as: rather than the expected: Meanwhile, changing some s to s and vice versa causes it to render as expected. cc
This is the expected behaviour actually: it converts the into a directly. So if you don't put empty doc comments between, it's as expected.
But why are the newlines in the stripped?
Oh, I didn't see that. I think it's because we use to remove whistespaces which also removes backlines. We should instead merge all doc comments before doing anything.
Change:
did) } Some(..) | None => { <del> let c = foreign::llvm_calling_convention(ccx, fn_ty.abi); let cconv = c.unwrap_or(lib::llvm::CCallConv); let llty = type_of_fn_from_ty(ccx, t); get_extern_fn(&mut *ccx.externs.borrow_mut(), ccx.llmod, name.as_slice(), cconv, llty, fn_ty.sig.output) </del> <ins> foreign::register_foreign_item_fn(ccx, fn_ty.abi, t, name.as_slice(), None) </ins> } } }

Discussion:
Spidermonkey's type is a union of size 64 bits. We represent this as in Rust. This works great on 64bit platforms. On 32bit platforms, the values get mangled when passed to the C library functions. This seems to be an ABI issue. We've encountered this before with which was about 32bit ARM. This gist contains sample programs and the generated IR for minimal test programs using rust-mozjs: Note that you will need my 32bit branch of rust-mozjs: You can put debugging printfs in in to see the value on the C side. The only notable thing I see in the IR is that the clang IR has when passing the . This seems like a Rust bug, but I'd also be interested if there is a workaround that will work on all platforms.
cc
cc me