jiebi/CodeConvo huggingface dataset:
Change:
let mut error_happened = false; <ins> if variant.fields.len() != remaining_fields.len() { // Some field is defined more than once. Make sure we don't try to // instantiate this struct in static/const context. let guar = self.dcx().span_delayed_bug(expr.span, "struct fields have non-unique names"); self.set_tainted_by_errors(guar); error_happened = true; } </ins> // Type-check each field. for (idx, field) in hir_fields.iter().enumerate() { let ident = tcx.adjust_ident(field.ident, variant.def_id);

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. --:
with debug assertions: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
without: --<details<summary<strongBacktrace</strong</summary<p</p</details

<!-- 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. --(reduced) <details<summary<strongOriginal Code</strong</summary<p</p</details<!-- 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- has the same ICE location, but this one doesn't require any feature to make ICE. ICE-loc: Original ICE-triggering code is mutated from test-file
bisects to searched nightlies: from nightly-2024-01-01 to nightly-2024-04-30 regressed nightly: nightly-2024-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The following already reproduces on 1.77 stable
Change:
#[inline] #[stable(feature = "rust1", since = "1.0.0")] pub fn swap_remove(&mut self, index: usize) -> T { <ins> #[cold] #[inline(never)] fn assert_failed(index: usize, len: usize) -> ! { panic!("swap_remove index (is {}) should be < len (is {})", index, len); } </ins> let len = self.len(); <del> assert!(index < len); </del> <ins> if !(index < len) { assert_failed(index, len); } </ins> unsafe { // We replace self[index] with the last element. Note that if the // bounds check above succeeds there must be a last element (which

Discussion:
I've spotted, that panic message could've provided details on what values led to this panic, instead of mentioning condition only. Generally speaking this and some other s in Vec could've been more detailed. If it's okay to step in, I'd like to offer my help. In case of I'd suggest calling this instead I find this more informative than Candidates for improval: aforementioned : : : :
Does triaging mean a green light for this suggestion?
No, I just apply the relevant labels. :)
Though this is a small change with little time required to fix, so I'd just make the PR if I were you. :)
Note: uses the same kind of assertion in (as the old check had aliasing issues). Depending on which PR lands first, we should make sure it gets the same panic message as the others.
I think it makes sense to follow the message, that is being currently printed, when trying to access element out of bounds via . Current message template is . I followed this idiom to keep it consistent.
Change:
.map(|ch| unicode_width::UnicodeWidthChar::width(ch).unwrap_or(1)) .sum(); <ins> let offset: isize = offsets .iter() .filter_map( |(start, v)| if span_start_pos <= *start { None } else { Some(v) }, ) .sum(); </ins> let underline_start = (span_start_pos + start) as isize + offset; let underline_end = (span_start_pos + start + sub_len) as isize + offset; <ins> assert!(underline_start >= 0 && underline_end >= 0); </ins> for p in underline_start..underline_end { buffer.putc( row_num, <del> max_line_num_len + 3 + p as usize, </del> <ins> ((max_line_num_len + 3) as isize + p) as usize, </ins> '^', Style::UnderlinePrimary, );

Discussion:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or .

There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:
Change:
<ins> // only-x86_64 // assembly-output: emit-asm // make sure the feature is not enabled at compile-time // compile-flags: -C opt-level=3 -C target-feature=-sse4.1 -C llvm-args=-x86-asm-syntax=intel #![feature(target_feature_11)] #![crate_type = "rlib"] use std::arch::x86_64::{__m128, _mm_blend_ps}; #[no_mangle] pub unsafe fn sse41_blend_nofeature(x: __m128, y: __m128) -> __m128 { let f = { // check that _mm_blend_ps is not being inlined into the closure // CHECK-LABEL: {{sse41_blend_nofeature.*closure.*:}} // CHECK-NOT: blendps // CHECK: {{call .*_mm_blend_ps.*}} // CHECK-NOT: blendps // CHECK: ret #[inline(never)] |x, y| _mm_blend_ps(x, y, 0b0101) }; f(x, y) } #[target_feature(enable = "sse4.1")] pub fn sse41_blend_noinline(x: __m128, y: __m128) -> __m128 { let f = { // check that _mm_blend_ps is being inlined into the closure // CHECK-LABEL: {{sse41_blend_noinline.*closure.*:}} // CHECK-NOT: _mm_blend_ps // CHECK: blendps // CHECK-NOT: _mm_blend_ps // CHECK: ret #[inline(never)] |x, y| unsafe { _mm_blend_ps(x, y, 0b0101) } }; f(x, y) } #[no_mangle] #[target_feature(enable = "sse4.1")] pub fn sse41_blend_doinline(x: __m128, y: __m128) -> __m128 { // check that the closure and _mm_blend_ps are being inlined into the function // CHECK-LABEL: sse41_blend_doinline: // CHECK-NOT: {{sse41_blend_doinline.*closure.*}} // CHECK-NOT: _mm_blend_ps // CHECK: blendps // CHECK-NOT: {{sse41_blend_doinline.*closure.*}} // CHECK-NOT: _mm_blend_ps // CHECK: ret let f = { #[inline] |x, y| unsafe { _mm_blend_ps(x, y, 0b0101) } }; f(x, y) } </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. --I tried this code: I expected to see this happen: all the avx512f functions get inlined into Instead, this happened: did not get inlined into codegen: here's a repro that mostly doesn't depend on std codegen: there seem to be quite a few moving parts here. if i remove the feature (or replace it with a feature that is implied by avx512f), or if i remove the inout parameter in the asm in , or if i remove the call to , or if i take the code outside the closure, the function gets inlined as expected, so i'm not sure which is the culprit 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 closure doesn't have any target features enabled, which isn't supposed to happen according to llvm ir before any llvm passes: link to original zulip discussion: https://rust-
This works correctly if you add . It looks like it was done .
Change:
<ins> // only-x86_64 // compile-flags: -Copt-level=3 #![crate_type = "lib"] #![feature(target_feature_11)] #[cfg(target_arch = "x86_64")] use std::arch::x86_64::*; // CHECK-LABEL: @with_avx #[no_mangle] #[cfg(target_arch = "x86_64")] #[target_feature(enable = "avx")] fn with_avx(x: __m256) -> __m256 { // CHECK: fadd let add = { #[inline(always)] |x, y| unsafe { _mm256_add_ps(x, y) } }; add(x, x) } // CHECK-LABEL: @without_avx #[no_mangle] #[cfg(target_arch = "x86_64")] unsafe fn without_avx(x: __m256) -> __m256 { // CHECK-NOT: fadd let add = { #[inline(always)] |x, y| unsafe { _mm256_add_ps(x, y) } }; add(x, x) } </ins>

Discussion:
The preceding code used to compile successfully. Since the stabilization of in the compilation fails with:
Hm, I think related to and
Based on , I'm guessing it would be fine to allow with on closures, at least from a language perspective, even if it still trips up LLVM?
Technically, is "just a hint" and thus one solution is and always was to accept the inline annotation and then simply ignore the request.
But yes, I believe this code actually should be fully acceptable. Note that in that if is enabled, the attributes do get applied to the closure and inlining is done normally by LLVM due to a full match. No hint required.
Assigning P-low because the regression has been contained to nightly versions due to an immediate revert, so this only blocks forward feature development.
label: -regression-from-stable-to-nightly +requires-nightly
Change:
error: expected token: `,` <del> --> $DIR/missing-comma.rs:15:19 </del> <ins> --> $DIR/missing-comma.rs:19:19 </ins> | LL |     println!("{}" a); |                   ^ error: no rules expected the token `b` <del> --> $DIR/missing-comma.rs:17:12 </del> <ins> --> $DIR/missing-comma.rs:21:12 </ins> | LL | macro_rules! foo { | ---------------- when calling this macro

Discussion:
I don't know what to make of this error. () Errors: On stable (1.34) the output is
I'm pretty sure this is fallout from the "missing comma here" suggestion for macros, that evaluates the macro again with the current arguments but adding a comma token in between the argument tokens in different combinations to see if it would be correct. My guess is that that is causing a parse error that doesn't happen for normal things than only have one token in them. We can disable the suggestion when fully qualified paths are involved.
Change:
QueryRegionConstraints { outlives, member_constraints: member_constraints.clone() } } <ins> struct QueryTypeRelatingDelegate<'a, 'tcx> { infcx: &'a InferCtxt<'a, 'tcx>, obligations: &'a mut Vec<PredicateObligation<'tcx>>, param_env: ty::ParamEnv<'tcx>, cause: &'a ObligationCause<'tcx>, } impl<'tcx> TypeRelatingDelegate<'tcx> for QueryTypeRelatingDelegate<'_, 'tcx> { fn create_next_universe(&mut self) -> ty::UniverseIndex { self.infcx.create_next_universe() } fn next_existential_region_var(&mut self, from_forall: bool) -> ty::Region<'tcx> { let origin = NLLRegionVariableOrigin::Existential { from_forall }; self.infcx.next_nll_region_var(origin) } fn next_placeholder_region(&mut self, placeholder: ty::PlaceholderRegion) -> ty::Region<'tcx> { self.infcx.tcx.mk_region(ty::RePlaceholder(placeholder)) } fn generalize_existential(&mut self, universe: ty::UniverseIndex) -> ty::Region<'tcx> { self.infcx.next_nll_region_var_in_universe( NLLRegionVariableOrigin::Existential { from_forall: false }, universe, ) } fn push_outlives(&mut self, sup: ty::Region<'tcx>, sub: ty::Region<'tcx>) { self.obligations.push(Obligation { cause: self.cause.clone(), param_env: self.param_env, predicate: ty::Predicate::RegionOutlives(ty::Binder::dummy(ty::OutlivesPredicate( sup, sub, ))), recursion_depth: 0, }); } fn push_domain_goal(&mut self, _: DomainGoal<'tcx>) { bug!("should never be invoked with eager normalization") } fn normalization() -> NormalizationStrategy { NormalizationStrategy::Eager } fn forbid_inference_vars() -> bool { true } } </ins>

Discussion:
mullvad-vpn build fails after jnix crate upgrade to v0.2.0 I tried this code: sudo pacman -Russnc mullvad-vpn sudo rm -rf /var/cache/mullvad-vpn/ sudo rm -rf /var/log/mullvad-vpn/ git clone cd mullvad-vpn makepkg -si I expected to see this happen: build completes without errors Instead, this happened: rustc panicks at 'assertion failed: data.isempty()', :
cc
ping icebreakers-cleanup-crew
Currently running
prints: searched nightlies: from nightly-2020-02-11 to nightly-2020-02-18 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: source code: modify labels: -E-needs-bisection
modify labels: -E-needs-mcve
triage: P-high. Removing nomination.
I'm also getting this error. : Backtrace:
Change:
let retval = Call(bcx, fn_ptr, llargs.as_slice(), None); match f.sig.output { ty::FnConverging(output_type) => { <del> if type_is_zero_size(ccx, output_type) || fcx.llretslotptr.get().is_some() { </del> <ins> if return_type_is_void(ccx, output_type) || fcx.llretslotptr.get().is_some() { </ins> RetVoid(bcx); } else { Ret(bcx, retval);

Discussion:
Out:
It seems to occur even without UFCS:
The problem seems to be with zero-sized types. Since this works fine:
Ok, yea the problem is when we coerce a bare fn that returns a zero sized type to a closure. I'll put up a PR once I've tested this fix a bit.
Change:
err.span_suggestion_verbose( *span, "use the type name directly", <del> self.tcx.value_path_str_with_args(*alias_to, e_args), </del> <ins> self.tcx.value_path_str_with_args(e_def.did(), e_args), </ins> Applicability::MaybeIncorrect, ); }

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. --Strangely enough, the following does not ICE: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also occured on nightly However, it appeared to not happen on rustc stable 1.75.0 <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I'm pretty sure this is from , cc
I would also like to add this also causes an ICE, so it's likely that it has to do with type constructors
Change:
self.last_path = path return path elif self.last_path is None: <del> raise RuntimeError('Tried to use the previous path in the first command') </del> <ins> raise InvalidCheck('Tried to use the previous path in the first command') </ins> else: return self.last_path def get_file(self, path): path = self.resolve_path(path) <del> try: </del> <ins> if path in self.files: </ins> return self.files[path] <del> except KeyError: try: with open(os.path.join(self.root, path)) as f: data = f.read() except Exception as e: raise RuntimeError('Cannot open file {!r}: {}'.format(path, e)) else: self.files[path] = data return data </del> <ins> abspath = os.path.join(self.root, path) if not(os.path.exists(abspath) and os.path.isfile(abspath)): raise FailedCheck('File does not exist {!r}'.format(path)) with open(abspath) as f: data = f.read() self.files[path] = data return data </ins> def get_tree(self, path): path = self.resolve_path(path) <del> try: </del> <ins> if path in self.trees: </ins> return self.trees[path] <del> except KeyError: try: f = open(os.path.join(self.root, path)) except Exception as e: raise RuntimeError('Cannot open file {!r}: {}'.format(path, e)) </del> <ins> abspath = os.path.join(self.root, path) if not(os.path.exists(abspath) and os.path.isfile(abspath)): raise FailedCheck('File does not exist {!r}'.format(path)) with open(abspath) as f: </ins> try: <del> with f: tree = ET.parse(f, CustomHTMLParser()) </del> <ins> tree = ET.parse(f, CustomHTMLParser()) </ins> except Exception as e: raise RuntimeError('Cannot parse an HTML file {!r}: {}'.format(path, e)) <del> else: self.trees[path] = tree return self.trees[path] </del> <ins> self.trees[path] = tree return self.trees[path] </ins> def check_string(data, pat, regexp):

Discussion:
When a doc test fails, the console output looks like this: A traceback should only be shown if there was an error in the python script itself - in this case it should only show the matches error, something like this:
cc me. I'm surely willing to fix that as soon as I get enough spare time.
did you ever get a chance to look at this? (Do you know if the situation has changed?)
No, also I'm not aware of any update. Looks like that I've forgotten this at that time (as flt2dec was being matured); I have virtually no energy to contribute nowadays, so I probably cannot work on this right now.
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. // Regression test for #13428 fn foo() -> ~str {  //~ ERROR not all control paths return a value format!("Hello {}", "world") // Put the trailing semicolon on its own line to test that the // note message gets the offending semicolon exactly ;   //~ NOTE consider removing this semicolon } fn bar() -> ~str {  //~ ERROR not all control paths return a value "foobar".to_owned() ;   //~ NOTE consider removing this semicolon } pub fn main() {} </ins>

Discussion:
Code: Compilation attempt: It should be pointing at the semi-colon on the next line, not the comma on this line.
The note message was introduced in . It doesn't seem to handle this situation properly.
Change:
<del> use crate::spec::{targets::wasm32_unknown_emscripten, LinkerFlavor, Target}; pub fn target() -> Target { let mut target = wasm32_unknown_emscripten::target(); target.add_post_link_args(LinkerFlavor::EmCc, &["-sWASM=0", "--memory-init-file", "0"]); target } </del>

Discussion:
(wrapped by hand to make the problem clear) The function pointer alignment is the same as our powerpc64-unknown-linux-gnu target, so the discrepancy must be in LLVM. While this is a tier 3 target, we are completely unable to generate code for it, so at some point this part of the target tier policy will become relevant (emphasis mine): If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (there are none, not even for the Tier 2 -gnu variant) (and potentially other people who have previously worked on the target), to check potential interest in improving the situation. I have trawled the issue tracker and I cannot find any evidence that this target is in use; all issues seem related to or the targets.
Does this also impact ppc64le? That's supported by Alpine, which uses musl. It looks like is the maintainer with musl. Not knowing anything about ppc, or very much about LLVM's data layouts, it looks like may be what broke this.
powerpc64le is not affected. Unfortunately looking at that diff I still can't figure out which of the targets is correct.
So I'm running into this in , the relevant code in LLVM is: () () We get rather than because of the musl-ness of the target. As far as I can tell, this would have been the case since , and the definition of hasn't changed . I think we just got this value wrong in .
Just as a side note – I am using it and I've hit this bug while building the current stable branch. Thank you for maintaining it.
Change:
let obligation = obligation.with(this.tcx(), predicate); result = cmp::max( nested_result, <del> this.evaluate_trait_predicate_recursively(stack.list(), obligation)?, </del> <ins> this.evaluate_trait_predicate_recursively(previous_stack, obligation)?, </ins> ); } }

Discussion:
I tried this code: I expected to see this happen: build failed, because this future doesn't implement Send, so this function shouldn't implement Instead, this happened: build 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<summaryBacktrace</summary<p</p</detailscargo-bisect-rustc show the Regression in this bug is introduced by this PR <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +T-types
I think it's a very serious bug, should we revert this change?
claim
minimized ah, figured out the issue how did you catch this bug?
I try to find the minimized example of there is a ICE with a unsend future in this issue
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Isn't this a stable-to-beta regression since nightly just branched?
Just to clarify since we're in the confusing week where stable & beta are discontinuous version numbers: