jiebi/CodeConvo huggingface dataset:
Change:
configs.extend(configure_lldb(&config)); } } else { <del> configs.push(config); </del> <ins> configs.push(config.clone()); </ins> }; let mut tests = Vec::new();

Discussion:
When compiletest fails, it prints an error summary like this at the end: However, there is one very important bit of information that I cannot gleam from this information: what are the host and target architectures that were tested! Figuring this out requires scrolling up quite a bit to where this test beings (and carefully not scrolling up too far because then one might look at the wrong test). See for an example where this confused people. I have also been confused by this multiple times in the past, e.g. using the name of the CI runner to incorrectly deduce what the architecture(s) are (and not realizing that some of our runners run tests for quite a few different targets). So I think in case of a failure, that summary at the end should repeat the important information that is printed at the top of the test run:
Cc
And also it would be nice if when it ignored a test because it was the wrong platform, it showed some indication of that, because otherwise it looks like it ran the test and it passed. Perhaps show a question mark ()? (We already use for tests that were ignored because they were already run and passed.)
AFAIK should already be used for all kinds of "ignored", including directives.
Turns out these messages are printed by bootstrap, not compiletest: However, detecting failures and exiting is done a few layers deeper: In case of failure, never returns or unwinds (except if fail-fast is off). I am not sure how to best adjust this to print an error before exiting (or to always print an error after the process finished, whether it succeeded or failed). any advice? If we just want this to happen when fail-fast is off, that would be easy, but I am not sure if that ever applies.
Change:
.into_inner() .map_in_place(|mbc| codemap::MultiByteChar { <del> pos: mbc.pos + start_pos, </del> <ins> pos: mbc.pos - start_pos, </ins> bytes: mbc.bytes });

Discussion:
I’m getting an ICE when compiling using
I was able to trace down the bug. It is due to me using a unicode character in the documentation of a function this somehow triggers the compiler bug. A minimal example is:
I believe Servo is also currently hitting this in the script crate during our current rust upgrade.
Yes, at least the failing assertion is the same. Removing non-ASCII characters from doc comments didn’t seem to help, though.
cc might this be another overflow error?
recommended on IRC to build with , but log output seems to be disabled in Nightly. So I built Rust with debugging enabled and tried again. (This took forever because of .) There was a lot of output, here is just the end of it:
This is lines / 299MB of output.
my current hypothesis is that this is the problem; it is at the very least very suspicious considering that five lines up in the previous statement we are normalizing the position to zero by subtracting the , not adding it.
(other good news: I have figured out how to make a regression test for this that will integrate into the rust test suite.)
Change:
} fn main() { <del> assert_eq!(8, std::mem::size_of_val(&single())); assert_eq!(12, std::mem::size_of_val(&single_with_noop())); assert_eq!(3084, std::mem::size_of_val(&joined())); assert_eq!(3084, std::mem::size_of_val(&joined_with_noop())); assert_eq!(3080, std::mem::size_of_val(&join_retval())); </del> <ins> assert_eq!(2, std::mem::size_of_val(&single())); assert_eq!(3, std::mem::size_of_val(&single_with_noop())); assert_eq!(3078, std::mem::size_of_val(&joined())); assert_eq!(3078, std::mem::size_of_val(&joined_with_noop())); assert_eq!(3074, std::mem::size_of_val(&join_retval())); </ins> }

Discussion:
Currently they use a hardcoded discriminant, which is quite a lot of room considering that generators don't typically have billions of states. They should be able to use the smallest unsigned integer type that fits all states instead (so in the vast majority of cases).
The discriminant is also never marked with a valid range, meaning that it never provides any niches that could be used to store other values. Not sure if doing that has any drawbacks, but it seems like a somewhat easy size optimization on first glance.
Fixing this was way easier than I expected, but I'd appreciate help with benchmarking the runtime impact of the fix in . So if anyone knows any async/await benchmarks that are not I/O heavy (so that they mostly test CPU overhead of async/await), I'd be happy to run them.
Change:
<del> // Copyright 2015 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. // no-prefer-dynamic // ignore-windows no jemalloc on windows // ignore-bitrig no jemalloc on bitrig // ignore-openbsd no jemalloc on openbsd // ignore-emscripten no jemalloc on emscripten #![feature(alloc_jemalloc)] extern crate alloc_jemalloc; fn main() { println!("{:?}", Box::new(3)); } </del>

Discussion:
As of the time of this writing, we are running jemalloc at the revision which I believe is the 4.0.4 release of jemalloc. Previously we were running which I believe is somewhere in the 3.6 series. We attempted to upgrade jemalloc many times between these two commits eventually that the previous behavior of on Windows is fundamentally racy in jemalloc right now unfortunately. This led to a to where we are today. Unfortunately, however, there is a so we are attempting to downgrade back to 3.6. There were no known problems other than some Windows issues with jemalloc 3.6, so we believe it'll be fine for awhile. In this downgrade, however, it appears that the implementation of is somewhat broken as well, causing the to fail to land. As a result, the downgrade attempt will disable jemalloc on Windows entirely. This issue will track re-enabling it on Windows as well as re-upgrading once the deadlock bug is fixed. As far as I know the only reason to not enable Windows is that lots of locking support was improved in 4.0.*, and the only reason to not upgrade immediately is the deadlock bugs we've encountered.
FWIW one of my Rust projects with CI-every-night has started deadlocking recently, and after some investigation it turned up the exact same stack trace as rustdoc itself, so that's at least another data point for the deadlock in jemalloc.
Change:
<ins> struct A; struct B; fn f(b1: B, b2: B, a2: C) {} //~ ERROR E0412 fn main() { f(A, A, B, C); //~ ERROR E0425 //~^ ERROR E0061 } </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. --You need rustc built with debug assertions in order to reproduce this! <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
let base_datum = unpack_datum!(bcx, trans_to_lvalue(bcx, &*base.expr, "base")); for &(i, t) in base.fields.iter() { let datum = base_datum.get_element( <del> t, |srcval| adt::trans_field_ptr(bcx, repr, srcval, discr, i)); let dest = adt::trans_field_ptr(bcx, repr, addr, discr, i); </del> <ins> t, |srcval| adt::trans_field_ptr(bcx, &*repr, srcval, discr, i)); let dest = adt::trans_field_ptr(bcx, &*repr, addr, discr, i); </ins> bcx = datum.store_to(bcx, dest); } },

Discussion:
The current translation for struct update in the case of ignore looks incorrect. It should only move those fields that are not specified manually. This can mean the difference between moving the base as a whole and not. Probably the easiest thing to do is to create an alloca, use the same code as the normal path, and just drop the alloca afterwards.
See FIXME.
visiting for triage. nominating for production ready.
Accepted for production-ready
visting for triage, still relevant. FYI, the module in question is
Change:
let value = if type_is_sized(cx.tcx(), t) { adt::MaybeSizedValue::sized(av) } else { <ins> // FIXME(#36457) -- we should pass unsized values as two arguments </ins> let data = Load(cx, get_dataptr(cx, av)); let info = Load(cx, get_meta(cx, av)); adt::MaybeSizedValue::unsized_(data, info)

Discussion:
The following successfully typechecks on , but generates an LLVM assertion failure: Error: Note that replacing with (and making mutable) allows compilation to succeed.
First occurs in nightly-2016-08-03 which turns on mir by default, does not occur on nightly-2016-08-03 with -Z orbit=off.
Using this was introduced between and ().
Problem seems to be that we call the with a fat pointer as 2 arguments, but it expects a pointer to a tuple.
I have a fix for this, running the full locally now to see if I broke anything else on the way.
Change:
pub quiet_tests: bool, // Fallback musl-root for all targets pub musl_root: Option<PathBuf>, <del> pub prefix: Option<String>, pub docdir: Option<String>, pub libdir: Option<String>, pub mandir: Option<String>, </del> <ins> pub prefix: Option<PathBuf>, pub docdir: Option<PathBuf>, pub libdir: Option<PathBuf>, pub mandir: Option<PathBuf>, </ins> pub codegen_tests: bool, pub nodejs: Option<PathBuf>, pub gdb: Option<PathBuf>,

Discussion:
No destdir is passed to in
That causes fail in Gentoo build
As far as I understand, we need to to pass to function and add value of to prefix here
Change:
<ins> #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // This test is a minimized reproduction for #79518 where // during error handling for the type mismatch we would try // to evaluate std::mem::size_of::<Self::Assoc> causing an ICE trait Foo { type Assoc: PartialEq; const AssocInstance: Self::Assoc; fn foo() where [(); std::mem::size_of::<Self::Assoc>()]: , { Self::AssocInstance == [(); std::mem::size_of::<Self::Assoc>()]; //~^ Error: mismatched types } } 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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It doesn't fixed in rustc 1.52.0-nightly ( 2021-02-14) link to playground : <details<summary<strongBacktrace</strong</summary<p</p</details
i dont think the fix was merged by then. it works in 1.52.0-nightly 2021-02-16 :)

<!-- 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</detailsI think I'm an ICE magnet; this is my fourth one.
I'd like to note that it only ICEs with the wrong return type. The following does not ICE
Change:
<del> // build-pass </del> <ins> // ignore-test // FIXME(const_generics): This test causes an ICE after reverting #76030. </ins> #![allow(incomplete_features)] #![feature(const_generics)]

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Hello! I'm observing a compilation regression coming from 1.47 to 1.48. Just an with only a dependency segfaults when building it with: System logs: GDB backtrace: Versions and also have this issue. Without these RUSTFLAGS it builds fine, it also builds fine when I build in debug mode. No problems at all when building that project on version 1.47.0. My system info:
This looks like it might be a duplicate of but it's great to have a smaller testcase than rustc itself!
The backtrace looks really similar indeed!
Steps: Result: How to make it not segfault, do any of the below: replace step 4 with don't use use or (preview doesn't work for me in github: so if it looks bad I'll try to edit)
Looks like a side-effect of , which exposed an existing bug in loop vectorize
This
Can confirm that is gone after applying (but without the test case fix which doesn't yet exist in rust 1.48.0 on gentoo)

When bootstrapping rustc, I can observe a crash inside llvm when building . In I could see this: I did a bisect and found out that the crash happens since cc my cpu is a The timing of the crash makes me think that this might happen somewhere during LTOing of the rustcmiddle crate, rustc did not show a backtrace for the crash though, since it happens inside llvm. I already did purge my rustc build cache and the sccache before I saw the segfault happens inside llvm (it didn't help anyway). :sweat_smile: rustc @
cc
Was a coredump generated? If so, should be able to generate a backtrace by running , followed by the command.
does this help?
via
There is no segfault if I build without
Marking this as P-high based on the
What setup are you using to pass ?
I had in my initially. reproduces the segfault as well.
was hitting segfaults with LLD with target-cpu=native, but that was on MSVC:
Hmm, I think i also have my linker set to lld, but I'm on linux...
Still crashes after llvm update in
I got the same SIGSEGV with at stage 0 Can't reproduce it with bootstrap from 1.47 to 1.47
some users hit it in gentoo with 1.48.0 downstream bug removing or helps as described here.
This
I ran into the same problem: OS: Ubuntu20.04 rustc exited with signal: 9 error: could not compile Caused by:
Change:
probe_need CFG_GIT     git fi <ins> # Use `md5sum` on GNU platforms, or `md5 -q` on BSD probe CFG_MD5              md5 probe CFG_MD5SUM           md5sum if [ -n "$CFG_MD5" ] then CFG_HASH_COMMAND="$CFG_MD5 -q | head -c 8" elif [ -n "$CFG_MD5SUM" ] then CFG_HASH_COMMAND="$CFG_MD5SUM | head -c 8" else err 'could not find one of: md5 md5sum' fi putvar CFG_HASH_COMMAND </ins> probe CFG_CLANG            clang++ probe CFG_CCACHE           ccache probe CFG_GCC              gcc

Discussion:
This value has not changed in a long time, but to support sxs installation in a single dir it needs to. It should just be hashed from the value of .
So should we pipe the value through e.g. md5sum? That could be awkward on BSDs, where the hash programs have a . I think we can patch over the differences by adding a check to the configure script. Something like this: then in the Makefile we have: But if there's a simpler way then I'm all ears.
Change:
pub fn new(nodes: &[DepNode], edges: &[(DepNode, DepNode)]) -> DepGraphQuery { <del> let mut graph = Graph::new(); </del> <ins> let mut graph = Graph::with_capacity(nodes.len(), edges.len()); </ins> let mut indices = FxHashMap(); for node in nodes { <del> indices.insert(node.clone(), graph.next_node_index()); graph.add_node(node.clone()); </del> <ins> indices.insert(node.clone(), graph.add_node(node.clone())); </ins> } for &(ref source, ref target) in edges {

Discussion:
This is an 8% regression with incremental enabled, 1% without it.
Interestingly if you you'll see: An 8% regression due to A 4% improvement due to A 7% improvement due to A 7% regression due to May be worth looking into as well?
Specifically before/after , -- I've only included the peak snapshot in the output there.
Looks like basically all of the memory , aka we have a bigger dep graph. Turns out adding more queries makes a bigger dep graph :)
I cashed in some easy savings in , but it doesn't actually fix the "regression", but we likely shouldn't call it a regression as it also fixed a number of would-be bugs!
Looks like we've and this particular peak may also , so closing.
Change:
item.tcx, item.body, item.def_id, <del> &[], </del> <ins> &item.tcx.get_attrs(item.def_id), </ins> &dead_unwinds, old_dataflow::IndirectlyMutableLocals::new(item.tcx, item.body, item.param_env), |_, local| old_dataflow::DebugFormatted::new(&local),

Discussion:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.
Change:
let spans_suggs: Vec<_> = formatters .into_iter() .zip(spans_with_counts.iter()) <del> .filter_map(|(fmt, (span, _))| { if let Some(formatter) = fmt { Some((formatter, span)) } else { None } </del> <ins> .filter_map(|(formatter, (span, _))| { if let Some(formatter) = formatter { Some((*span, formatter(name))) } else { None } </ins> }) <del> .map(|(formatter, span)| (*span, formatter(name))) </del> .collect(); if spans_suggs.is_empty() { // If all the spans come from macros, we cannot extract snippets and then

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 (which works correctly with rustc 1.57.0 stable): But with , I get: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also consider the following code, which creates an error message that could be more precise. I wouldn't call the following example a bug, but maybe these two issues are related: () Error output:
I think this is due to cc: let me see if I can fix this real quick.
claim
label +regression-from-stable-to-nightly +A-diagnostics
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
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. #![crate_type = "lib"] pub struct TreeBuilder<H>; impl<H> TreeBuilder<H> { pub fn process_token(&mut self) { match self { _ => for _y in *self {} } } } impl<H> Iterator<H> for TreeBuilder<H> { fn next(&mut self) -> Option<H> { None } } </ins>

Discussion:
Extracted from an issue I encountered upgrading to Rust master. : : It seems like more or less every part of this code is necessary to hit the bug. Here's the result: (This has my modifications to give a marginally more useful error message.) The failure happens when when handling the case. What I actually get building is a failure of the preceding assertion regarding crate IDs. I didn't find a small reproducer for that assertion failure, but this bug is likely to be related.
cc me
(Slightly) simpler example: This appears to be related to AST being inlined cross-crate, and the internals (cc since desugaring it to the equivalent doesn't ICE. It also requires that is a method, a freestanding function stops the ICE.
Cool, for now I'll go with the workaround of desugaring the loop myself.
Change:
source: *source, }; visitor.scope_tree.yield_in_scope.insert(scope, data); <ins> if visitor.pessimistic_yield { debug!("resolve_expr in pessimistic_yield - marking scope {:?} for fixup", scope); visitor.fixup_scopes.push(scope); } </ins> // Keep traversing up while we can. match visitor.scope_tree.parent_map.get(&scope) {

Discussion:
The code below causes an internal compiler error. I've provided some more details as comments. rustc 1.37.0-nightly ( 2019-05-31) binary: rustc commit-hash: commit-date: 2019-05-31 host: x86_64-unknown-linux-gnu release: 1.37.0-nightly LLVM version: 8.0 Backtrace:
Does this issue still occur? I couldn't reproduce it from given code on playground.
I just checked with nightly 2019-06-03, and it's still there. It requires the line to occur.
minimized:
Marking as blocking -- not entirely clear how general this is but it looks like something people might run across fairly easily.
cc -- maybe you have some idea what the problem is here?
My guess is that implicitly borrows during the type checking phase, so we don't record as being part of the generator.
This seems to be related to the field calculated . When , a computed count of gets compared against a exprcount of , resulting in being set to . However,I'm seeing this line earlier in the logs: which has a count of , as expected. This would seem to suggest that the count is somehow getting overwritten later on.
On further inspection, the count doesn't appear to be getting overwritten. and are both computing it in the same way, but it seems inconsistent with the MIR that ultimately gets generated. I think that due to the way the HIR post-order traversal works, the overall assignment expression is computed to be 'after' the inner , which is interpreted to mean that it isn't live over the yield point. However, consider the MIR for a similar function: The relevant MIR is; Here, the mutable borrow adjustment occurs before the body of the block. When the block includes a , the is clearly live across the yield point.