jiebi/CodeConvo huggingface dataset:
Change:
let llfn = base::get_extern_fn(&mut *ccx.externs.borrow_mut(), ccx.llmod, <del> lname.get(), </del> <ins> name, </ins> cc, llfn_ty, tys.fn_sig.output);

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
Change:
fn fold_mod[ENV](&ENV e, ast_fold[ENV] fld, &ast._mod m) -> ast._mod { <ins> let vec[@view_item] view_items = vec(); </ins> let vec[@item] items = vec(); <ins> auto index = m.index; </ins> for (@item i in m.items) { append[@item](items, fold_item[ENV](e, fld, i)); } <del> ret fld.fold_mod(e, rec(items=items with m)); </del> <ins> for (@view_item vi in m.view_items) { append[@view_item](view_items, fold_view_item[ENV](e, fld, vi)); } ret fld.fold_mod(e, rec(view_items=view_items, items=items, index=index)); </ins> } fn fold_crate[ENV](&ENV env, ast_fold[ENV] fld, @ast.crate c) -> @ast.crate {

Discussion:
I was trying to build the stdlibs for the target like this: However, the build fails with the following error: Here is the full build log: I'm using Xubuntu 15.10. At the time of building, the Rust master was at .
Unfortunately is a which means that we don't guarantee that it builds in-tree right now. Patches are certainly welcome to fix this, however! We tend to not keep issues tracking build support for all Tier 3 platforms, however, so I'm going to close this. If you're interested in promoting this to at least tier 2 you could also help modify out to be able to support this target!
Change:
ClearCrossCrate::Clear => None, } } <ins> /// The instance this source scope was inlined from, if any. #[inline] pub fn inlined_instance<'tcx>( self, source_scopes: &IndexVec<SourceScope, SourceScopeData<'tcx>>, ) -> Option<ty::Instance<'tcx>> { let scope_data = &source_scopes[self]; if let Some((inlined_instance, _)) = scope_data.inlined { Some(inlined_instance) } else if let Some(inlined_scope) = scope_data.inlined_parent_scope { Some(source_scopes[inlined_scope].inlined.unwrap().0) } else { None } } </ins> } #[derive(Clone, Debug, TyEncodable, TyDecodable, HashStable, TypeFoldable, TypeVisitable)]

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
"-lgcc".to_string(), "-lgcc_eh".to_string(), "-lpthread".to_string(), <ins> // libpthread depends on libmsvcrt, so we need to link it *again*. "-lmsvcrt".to_string(), </ins> "-lkernel32".to_string(), ], );

Discussion:
Using . No environment changes other than installing Rust itself.
Has it started with latest nightly? It'd be good to rule out AppVeyor change by installing previously working nightly.
The compiler-builtins CI now fails with the same error. The latest working nightly is 2020-03-14. Looks like it is related to changes from which included in link args.
modify labels: +E-needs-mcve cc FWIW depend on two libraries:
Ugh, mingw has a stupid amount of circular dependencies in its libraries... What I am more concerned about is why Rust CI didn't catch this. Maybe it's because it is using an older mingw version. We should considering upgrading it.
I'd love to upgrade MinGW on the CI as it would help me with a few thing but there is a problem. Upstream no longer provides prebuilt GCC and latest version available had issue where it ran out of memory on the CI: I can help with building GCC or providing builds but I don't really know how to start.
I managed to reproduce this locally. It only happens if you don't have MSYS installed, in which case rustc will use the gcc and libraries from the component. This is a bit worrying, since it means that isn't being properly tested in CI.
Change:
ty::TyAdt(adt_def, substs) if adt_def.is_enum() => { match cv.val { ConstVal::Value(val) => { <del> let discr = const_discr( </del> <ins> let discr_val = const_discr( </ins> self.tcx, self.param_env, instance, val, cv.ty <del> ).unwrap(); let variant_index = adt_def .discriminants(self.tcx) .position(|var| var.val == discr) .unwrap(); </del> <ins> ).expect("const_discr failed"); let layout = self .tcx .layout_of(self.param_env.and(cv.ty)) .expect("layout of enum not available"); let variant_index = match layout.variants { ty::layout::Variants::Single { index } => index, ty::layout::Variants::Tagged { ref discr, .. } => { // raw discriminants for enums are isize or bigger during // their computation, but later shrunk to the smallest possible // representation let size = discr.value.size(self.tcx).bits(); let amt = 128 - size; adt_def .discriminants(self.tcx) .position(|var| ((var.val << amt) >> amt) == discr_val) .unwrap_or_else(|| { bug!("discriminant {} not found in {:#?}", discr_val, adt_def .discriminants(self.tcx) .collect::<Vec<_>>(), ); }) } ty::layout::Variants::NicheFilling { .. } => { assert_eq!(discr_val as usize as u128, discr_val); discr_val as usize }, }; </ins> let subpatterns = adt_subpatterns( adt_def.variants[variant_index].fields.len(), Some(variant_index),

Discussion:
I was trying to build which pulls in pango 0.1.3 as dependency . While building pango, rustc segfaults  meta: Crash happens in So apparently const eval produces a discriminant that doesn't match any variant's discriminant. more concretely, it happens during a match on which is the only discriminant with as its value.
weird, I am still getting the panic with todays nightly :(
Same backtrace? We do have a regression test for this exact issue
Yeah, backtrace is identical except for the rustc version string in the ICE notes. :/
Fix confirmed, thanks!
Change:
DlSym(String), LocatorCombined(Box<CombinedLocatorError>), NonDylibPlugin(Symbol), <ins> NotFound(Symbol), </ins> } enum MetadataError<'a> {

Discussion:
I decided to try address sanitizer on WSL Ubuntu today, but ran into 2 errors. These errors are only present when using the sanitizer, so my crate compiles normally. To give context there are 2 crates: and . On there is a procedural macro called , which is named the same as my crate which I am re-exporting it to. I don't really know if this a bug or a problem on my end, but I thought I'd mention it just in case. : I included the full error output in a file below
If you use sanitizers you need to pass the flag, but I guess you missed it. See also :
Oh I did miss it and that fixed it. The documentation made it sound optional though, so I didn't realize that was the issue. Thanks for the quick reply!
Re-opening because the error is very confusing. See also
On the error is: which isn't great, but at least suggests some issue related to asan. On the error is: Which is very confusing. was merged between those two versions and changes in which cases E0519 is emitted. ping who wrote that PR.
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. struct Foo { x: int } extern { fn foo(1: ()); //~^ ERROR: patterns aren't allowed in foreign function declarations fn bar((): int); //~^ ERROR: patterns aren't allowed in foreign function declarations fn baz(Foo { x }: int); //~^ ERROR: patterns aren't allowed in foreign function declarations fn qux((x,y): ()); //~^ ERROR: patterns aren't allowed in foreign function declarations fn this_is_actually_ok(a: uint); fn and_so_is_this(_: uint); } fn main() {} </ins>  No newline at end of file

Discussion:
The following compiles fine, but uncommenting any of the currently-commented functions makes the compiler ICE. For the ICE message is and the others are similar.
I'm inclined to say that the correct behavior is to deny all patterns other than (give a parser error perhaps).
Nominating.
I agree
Accepted for 1.0, P-backcompat-lang.
Good newbie bug.
Being a good newbie, I'll have a crack at this one. :)
Might have aimed a little too high by trying this issue.. but from what i understand, the type checking is working as people would like, but the message is incorrect and should be a actual syntax error and not an ICE... so the below is some thing like how it should work? Sorry if I've completely misunderstood, still pretty nubbins with Rust. :
my reading of is that all of your examples should fail; ideally only an identfier should pass.
They should all fail, the only thing that should pass is , nothing involving destructuring or pattern matching. One way to implement this would be to make it an actual syntax error. You can find a starting place for this change by grepping for in . (I personally would recommend implementing this by threading a argument through , to where you chose between the existing call and calling directly based on that boolean.)
Ahhh okay, that makes more sense. Thanks for that. I'll see what I can make happen.
Change:
interpret_alloc_index.reserve(new_n - n); for idx in n..new_n { let id = encoder.interpret_allocs[idx]; <del> let pos: u32 = encoder.position().try_into().unwrap(); </del> <ins> let pos: u64 = encoder.position().try_into().unwrap(); </ins> interpret_alloc_index.push(pos); interpret::specialized_encode_alloc_id(&mut encoder, tcx, 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. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:
Change:
!invalid }) .cloned() <del> .map(|mut substitution| { </del> <ins> .filter_map(|mut substitution| { </ins> // Assumption: all spans are in the same file, and all spans // are disjoint. Sort in ascending order. substitution.parts.sort_by_key(|part| part.span.lo()); // Find the bounding span. <del> let lo = substitution.parts.iter().map(|part| part.span.lo()).min().unwrap(); let hi = substitution.parts.iter().map(|part| part.span.hi()).max().unwrap(); </del> <ins> let lo = substitution.parts.iter().map(|part| part.span.lo()).min()?; let hi = substitution.parts.iter().map(|part| part.span.hi()).max()?; </ins> let bounding_span = Span::with_root_ctxt(lo, hi); <del> let lines = cm.span_to_lines(bounding_span).unwrap(); </del> <ins> // The different spans might belong to different contexts, if so ignore suggestion. let lines = cm.span_to_lines(bounding_span).ok()?; </ins> assert!(!lines.lines.is_empty()); // To build up the result, we do this for each span:

Discussion:
I was using the latest version of  and tried to store a reference without a lifetime annotated in a macro-generated error. This shouldn't (and doesn't) work, but rustc should at least throw an error instead of blowing up, right? Code sample: I expected an error of some sort about lifetimes or macros, but instead, the compiler ed: thread 'rustc' panicked at 'called on an value: DistinctSources(DistinctSources { begin: (Real(""), BytePos(0)), end: (Macros("::quickerror::quickerror"), BytePos()) })', This rustc was compiled on Gentoo from a recent . $ rustc --version --verbose rustc 1.42.0-dev ( 2020-01-21) binary: rustc commit-hash: commit-date: 2020-01-21 host: x8664-unknown-linux-gnu release: 1.42.0-dev LLVM version: 9.0 Minimal example: Backtrace:
rustc in playpen isn't the latest compiler. reopen
cc
Backtrace:
triage: P-high, assigning to . (It would be good to confirm it is indeed due to the CC'ed PR via bisection...)
Full backtrace: From a quick look it seems like might tackle this. Rebuilding a recent master to confirm.
Change:
} w.write_str(")"); } <del> w.write_str("</code></div>"); </del> <ins> w.write_str("</code>"); render_stability_since(w, variant, it, cx.tcx()); w.write_str("</div>"); </ins> document(w, cx, variant, Some(it)); document_non_exhaustive(w, variant);

Discussion:
Go to: It was but the rustdoc generates like: ! The problem is that the previous variant's version is placed at the same height. I think it's ideal to place the version of the item itself at the same height, like functions.
I am new here but it looks like something I could do. Can you point me in the right direction?
Sorry but I'm not familiar with rustdoc, could you help them?
I don't have time, sorry. may have suggestions.
I can help if needed. But first: how would you want it to look like?
As mentioned first, the version at the same height should be the variant's IMO.
Ah ok sorry, so it's a layout bug. I thought you wanted to improve the display (which would be welcome too!). The problematic line is . It should be set before the docblock (in the variant header if possible).
I will gladly take a look at it, so I can familiarize with the codebase.
Sure, go ahead! Do test locally: Like that you can then go to the page and check if the bug is fixed. ;)
Change:
// Use T as the sub pattern type of Box<T>. vec![substs.type_at(0)] } else { <del> adt.variants[ctor.variant_index_for_adt(cx, adt)].fields.iter().map(|field| { </del> <ins> let variant = &adt.variants[ctor.variant_index_for_adt(cx, adt)]; let is_non_exhaustive = variant.is_field_list_non_exhaustive() && !cx.is_local(ty); variant.fields.iter().map(|field| { </ins> let is_visible = adt.is_enum() || field.vis.is_accessible_from(cx.module, cx.tcx); <del> if is_visible { let ty = field.ty(cx.tcx, substs); match ty.kind { // If the field type returned is an array of an unknown // size return an TyErr. ty::Array(_, len) if len.try_eval_usize(cx.tcx, cx.param_env).is_none() => cx.tcx.types.err, _ => ty, } } else { // Treat all non-visible fields as TyErr. They // can't appear in any other pattern from // this match (because they are private), // so their type does not matter - but // we don't want to know they are // uninhabited. cx.tcx.types.err </del> <ins> let is_uninhabited = cx.is_uninhabited(field.ty(cx.tcx, substs)); match (is_visible, is_non_exhaustive, is_uninhabited) { // Treat all uninhabited types in non-exhaustive variants as `TyErr`. (_, true, true) => cx.tcx.types.err, // Treat all non-visible fields as `TyErr`. They can't appear in any // other pattern from this match (because they are private), so their // type does not matter - but we don't want to know they are uninhabited. (false, ..) => cx.tcx.types.err, (true, ..) => { let ty = field.ty(cx.tcx, substs); match ty.kind { // If the field type returned is an array of an unknown // size return an TyErr. ty::Array(_, len) if len.try_eval_usize(cx.tcx, cx.param_env).is_none() => cx.tcx.types.err, _ => ty, } }, </ins> } }).collect() }

Discussion:
Say I have the following enum in crate : And I match on it in crate : The second branch is not detected to be unreachable. This is on current nightly; .
The reason for this behaviour is straightforward: reports tuple variants with non-exhaustive fields as always useful. This line was introduced in commit . I'm not quite sure what the intended semantics are so I wouldn't know how to fix it.
Please wait for to be merged before fixing this; I'm dreading having to rebase on top of the fix
cc
Change:
<ins> // revisions: rpass1 cfail1 rpass3 // only-x86_64 // Regression test for issue #72386 // Checks that we don't ICE when switching to an invalid register // and back again #![feature(asm)] #[cfg(any(rpass1, rpass3))] fn main() { unsafe { asm!("nop") } } #[cfg(cfail1)] fn main() { unsafe { asm!("nop",out("invalid_reg")_) //[cfail1]~^ ERROR invalid register } } </ins>

Discussion:
Discovered when playing with new asm! macro with following code: asm! usage to building will result in error, because this is invalid register name ( this is 100% correct) back to (same code as in 1) build will result with ICE: disable incremental compilation : also fails on x86_64-pc-windows-gnu
cc
It looks like you're missing the modifier here:
That doesn't seem to work since isn't .
It looks like it's nececessary to declare in both and . The error is caused by the wrong trait being used (there are two - one for each crate that calls . Do you want to use your apporach, or should I open a PR with the arena changes?
I'm getting an ICE even after that looks like Is this caused by the same thing or do I submit a bug report?
It's the same issue.
Change:
if !errors.is_empty() { let message = errors.iter().fold(String::new(), |s1, s2| s1 + "n" + s2); <del> bug!("{}", message); </del> <ins> sess.delay_span_bug(rustc_span::DUMMY_SP, &message); </ins> } }

Discussion:
This code () produces ICE on current beta and nightly
Tagging as P-medium and "triaged" for async-await. Note that yield is unstable.
the feature is nightly but the ice doesn't require any feature gate to trigger.
searched nightlies: from nightly-2019-01-01 to nightly-2020-02-01 regressed nightly: nightly-2019-09-29 searched commits: from to regressed commit: source code: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
thanks for the bisection! Annoyingly, it regressed in a rollup PR, which means there are many candidates: (Docs: slice elements are equidistant) -- (Include message on tests that should panic but do not) -- (Remove stray references to the old global tcx) -- (Remove unused DepTrackingMap) -- (Account for tail expressions when pointing at return type) -- (hir: Disallow on constants) -- (Fix divduration() marked as stable by mistake) -- (update rtpSpawn's parameters type(It's prototype has been updated in libc)) -- (Thou shallt not ) -- (Stabilize mapgetkeyvalue feature) -- ( fix links to primitives in documentation) -- (Upgrade envlogger to 0.7) -- (Add mailmap entry for Dustin Bensing by request) -- (check_match: improve diagnostics for with ) --
If I had to guess, I would guess (cc triggered this regression, but or are possibilities. I would guess because it caused the compiler to keep compiling when it might've aborted, and maybe it would've aborted in these cases and hence never reached the code that causes an ICE. If indeed I am correct, then this could be fixed by adding a call at the point of the ICE (i.e., basically asserting that some error has occurred but otherwise just try to not crash).
Change:
<ins> // check-pass trait X { fn test(x: u32, ( //~^ WARN anonymous parameters are deprecated and will be removed in the next edition //~^^ WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018! )) {} } fn main() {} </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. --Rebase over , then run . I think this is the test. cc but I think this is an issue with rustcerrors, not clippy itself. <!-- 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
This is from a diagnostic constructed in a pre-expansion pass. Maybe this has something to do with the ICE
I'm able to reproduce this by running with the following contents: And it needs .
I thought this had been solved by a recent PR :(
No, I just avoided a malformed span that was hitting the same ICE The ICE itself will occur for any multi line span where the end is to the left of the start:
Change:
source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "a6a622008b6e321afc04970976f62ee297fdbaa6f95318ca343e3eebb9648441" dependencies = [ <del> "compiler_builtins", </del> "crc32fast", "flate2", "hashbrown", "indexmap", "memchr", <del> "rustc-std-workspace-alloc", "rustc-std-workspace-core", </del> "ruzstd 0.5.0", "wasmparser", ]

Discussion:
The relevant commit seem to be located at <details<summaryError</summary<p</p</details
Ah. cc
Ah, this was fixed in
Okay, it seems like this is just a misunderstanding. keywords cannot be searched ...
This won't be actually fixed in std until lands.
Change:
println!("Pre-expansion node count:  {}", count_nodes(&krate)); } <del> if let Some(ref s) = sess.opts.show_span { </del> <ins> if let Some(ref s) = sess.opts.debugging_opts.show_span { </ins> syntax::show_span::run(sess.diagnostic(), s, &krate); }

Discussion:
Not a breaking change since it is an unstable option.
Is it already an unstable option?
this issue is saying that should be changed to . It is already an unstable option.
So can accept as arguments. How would those be specified if were changed to a ?
Hopefully exactly the same way, not sure how possible that is. If it is not possible right now, then this probably isn't an easy issue to fix. I can look into it next week.
We've got kinda our own syntax for the flags so where today you pass it could instead be