jiebi/CodeConvo huggingface dataset:
Change:
DepthFirstTraversal::with_start_node(self, start, direction) } <ins> pub fn nodes_in_postorder<'a>(&'a self, direction: Direction, entry_node: NodeIndex) -> Vec<NodeIndex> { let mut visited = BitVector::new(self.len_nodes()); let mut stack = vec![]; let mut result = Vec::with_capacity(self.len_nodes()); let mut push_node = |stack: &mut Vec<_>, node: NodeIndex| { if visited.insert(node.0) { stack.push((node, self.adjacent_edges(node, direction))); } }; for node in Some(entry_node).into_iter() .chain(self.enumerated_nodes().map(|(node, _)| node)) { push_node(&mut stack, node); while let Some((node, mut iter)) = stack.pop() { if let Some((_, child)) = iter.next() { let target = child.source_or_target(direction); // the current node needs more processing, so // add it back to the stack stack.push((node, iter)); // and then push the new node push_node(&mut stack, target); } else { result.push(node); } } } assert_eq!(result.len(), self.len_nodes()); result } </ins> /// Whether or not a node can be reached from itself. pub fn is_node_cyclic(&self, starting_node_index: NodeIndex) -> bool { // This is similar to depth traversal below, but we

Discussion:
See . Here is a chart giving time output from with of the lines of the form uncommented. n -------- With this gist I've tried to create a fairly minimal example. It's not as minimal as maybe it could be because it's a little tricky to figure out what's causing the slow compiles and I've spent as much time as I can on this right now. It's very sensitive to seemingly irrelevant changes in the code. If I remove the unused variable, compile times dramatically improve. If I remove the empty loop, compile times dramatically improve. On my actual project, I am getting compile times in excess of 20 minutes. To compile a few thousand lines of code.
cc
Umm this is not an expansion problem but rather a borrowck problem - dataflow somehow takes O(n) iterations to converge.
Change:
// FIXME: #13996: mark the `allocate` and `reallocate` return value as `noalias` //                and `nonnull` <del> use core::ptr::RawPtr; </del> #[cfg(not(test))] use core::raw; #[cfg(stage0, not(test))] use util;

Discussion:
I this to get DST landed. For types I use a fat pointer. If the vector is empy I use null for the pointer, so when this deallocates via drop glue jemalloc segfaults. It should be fairly easy to do a zero sized allocation or something and use that value and then we can remove the null check. That also allows us to use the Option to non-null pointer optimisation. For now I just want to get this branch landed though. cc
FWIW, as the sentinel value for this sort of situation (to ensure that still works, since that uses the "non-null" pointer as the discriminant).
It seems that landed the non-null pointer optimization for slices so this shouldn't be required anymore. Can it be closed?
This ended up landing as part of the initial implementation, but I don't think it is actually accomplishing anything.
Change:
return None; } <del> let idx_opt = { // work around borrowck limitations let pred = &mut self.pred; self.v.iter().position(|x| (*pred)(x)) }; match idx_opt { </del> <ins> match self.v.iter().position(|x| (self.pred)(x)) { </ins> None => self.finish(), Some(idx) => { <del> let tmp = mem::replace(&mut self.v, &mut []); let (head, tail) = tmp.split_at_mut(idx); self.v = &mut tail[1..]; Some(head) </del> <ins> let tmp = mem::take(&mut self.v); // idx is the index of the element we are splitting on. We want to set self to the // region after idx, and return the subslice before and not including idx. // So first we split after idx let (head, tail) = tmp.split_at_mut(idx + 1); self.v = tail; // Then return the subslice up to but not including the found element Some(&mut head[..idx]) </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. --As part of an ongoing effort to eliminate all panics from one of my projects, I discovered that does not elide bounds checks in release mode, whereas does. This issue also affects . The following examples illustrate this issue: The generated asm for elides all bounds checks: Unfortunately, the bounds check is reintroduced when is used instead: It seems that the following code in the iterator is responsible for introducing the bounds check (specifically the array index on line 640): <!-- 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 tested on from the Rust playground. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Nice catch. Oh, I'm doing the same (but in regular std code). stdsort is full of bound tests (issue ). I'm dreaming of having red squiggles under divisions/mods/rems and array/slice accesses where a bound test hasn't being removed. And built-in annotations like . And more :)
label +A-codegen +A-slice +T-libs +T-compiler
claim
Awesome, thanks for looking into this
Change:
pub fn open<P: AsRef<Path>>(&self, path: P) -> io::Result<File> { let path = path.as_ref(); let inner = try!(fs_imp::File::open(path, &self.0)); <del> Ok(File { path: Some(path.to_path_buf()), inner: inner }) </del> <ins> Ok(File { inner: inner }) </ins> } }

Discussion:
takes a object as reference, although it only clones it afterwards. It's also impossible to re-use the allocation for the file path, because it's only dropped at the end.
It is pretty hard to not involve allocations because Rust-native strings will have to be converted into null terminated one to pass into the native API at some point anyway.
That's true.. Maybe we can avoid the double-allocation?
The path is cloned only so that it can later be used in error messages, which is a somewhat debatable use case. We could resolve this in the future by taking an bound (if we had a trait like that). cc
In that case it would probably be better to just take a PathBuf. But does it really justify an extra allocation just to provide error messages?
That would be a lot less ergonomic -- I want to be able to feed in a string literal with no extra steps. Probably not, hence why I said it was a "somewhat debatable use case." :)
What about a variable-length stack allocation?
allocating on stack comes with its own downsides. Also, it doesn’t guarantee a trailing null byte either, AFAIK?
If you had a stack allocation, you could just append a null byte.
As tbu- said. And the downsides of are nothing compared to linking in 195kB of jemalloc (the absolute minimum jemalloc size on OS X x86_64 with LTO).
Change:
fn with_query_cache<'tcx>( tcx: TyCtxt<'tcx>, iter: impl IntoIterator<Item = Ty<'tcx>>, <del> only_significant: bool, </del> ) -> NeedsDropResult<Vec<Ty<'tcx>>> { iter.into_iter().try_fold(Vec::new(), |mut vec, subty| { match subty.kind() { ty::Adt(adt_id, subst) => { <del> for subty in if only_significant { tcx.adt_significant_drop_tys(adt_id.did)? } else { tcx.adt_drop_tys(adt_id.did)? } { </del> <ins> for subty in tcx.adt_drop_tys(adt_id.did)? { </ins> vec.push(subty.subst(tcx, subst)); } }

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. --Error <codeerror[E0391] cycle detected when computing when has a significant destructor</codeoccurs when warn/deny lint on rust beta and nightly with a certain code snippet. On rust stable, it compiles without any issues. Looks like an issue of rustc (). I tried this code: It compiles successfully on stable or with : But with this lint warned (or denied) it does not compile on rust beta and on rust nightly with error: : <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisects to , CC Although this is a regression from stable to beta, there's not enough time for it to get fixed before release.
Oops. Yeah, i read the error message and immediately knew what was going on. I can hopefully get a patch up for this tomorrow. claim
label regression-from-stable-to-stable, -regression-from-stable-to-beta
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
/// /// (Note that this example artificially demonstrates a use of this method, /// but `let slice = NonNull::from(&x[..]);` would be a better way to write code like this.) <del> #[unstable(feature = "nonnull_slice_from_raw_parts", issue = "71941")] #[rustc_const_unstable(feature = "const_nonnull_slice_from_raw_parts", issue = "71941")] </del> <ins> #[stable(feature = "nonnull_slice_from_raw_parts", since = "CURRENT_RUSTC_VERSION")] #[rustc_const_unstable(feature = "const_slice_from_raw_parts_mut", issue = "67456")] </ins> #[must_use] #[inline] pub const fn slice_from_raw_parts(data: NonNull<T>, len: usize) -> Self {

Discussion:
This is a tracking issue for the method proposed in PR The feature gates for the issue are , and for using as a . Docs: [x] Implementation: [x] FCP: [ ] Stabilization PR
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I'm willing to file the stabilization report for this if the library team is on board for stabilization.
I'd certainly appreciate one!
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Change:
<del> Subproject commit e5c3af6f516311cc4b1fc017c58d83b7442cbc34 </del> <ins> Subproject commit 35af23b6a94459da538ee1479e863c7699620f84 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
sure !

While trying to unpin nightly (2021-03-25) to latest nightly, I have hit an internal compiler error. It emerged between 2021-03-25 and today's build. All the details are in the build log. In particular, The error seems to emerge when compiling a transitive dependency, so it is not very easy to reproduce with a minimal example. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Regressed between nightly-2021-06-08 and nightly-2021-06-09, which is , which corresponds to (which includes that touches :thinking:).
found out that the issue boils down to Does it make any sense to put on a item...??
It doesn't -- it even generates a warning:
claim
Change:
pub fn expect(self, msg: &str) -> T { match self { Some(val) => val, <del> None => fail!(msg), </del> <ins> None => fail!("{}", msg), </ins> } }

Discussion:
These appear all the time and result in large code bloat. At least the file and line should be combined into a static.
Also, and result in inefficient codegen and code bloat because they call into the string formatter when they don't need to.
This seems to be done for . The macro in still uses the string formatter for all invocations, but I don't even know how to use those.
Change:
<del> //@ known-bug: rust-lang/rust#126376 mod a { pub mod b { pub mod c { pub trait D {} } } } use a::*; use e as b; use b::c::D as e; fn e() {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: inconsistent resolution for an import', 'error: internal compiler error: inconsistent resolution for an import' 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: [resolverforlowering_raw] getting the resolver for lowering --
Isn't this example identical to EDIT: oh I see, the PR that closes doesn't actually have this test, so it's possible this is a different ICE.
This one has an additional which indeed causes the ICE to trigger again :laughing:
Regression in nightly-2020-11-09 commit[0] 2020-11-07: Auto merge of - Mark-Simulacrum:debug-asserts, r=pietroalbini commit[1] 2020-11-07: Auto merge of - Mark-Simulacrum:revert-, r=petrochenkov commit[2] 2020-11-08: Auto merge of - petrochenkov:mergetarg, r=Mark-Simulacrum commit[3] 2020-11-08: Auto merge of - lcnr:revert75443, r=nikomatsakis commit[4] 2020-11-08: Auto merge of - m-ou-se:rollup-3jp1ijj, r=m-ou-se commit[5] 2020-11-08: Auto merge of - petrochenkov:visitok, r=Aaron1011

<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' 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: [resolverforloweringraw] getting the resolver for lowering --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc as this looks 99% like and you fixed that one recently ^^
claim. I will investigate it in my spare time.
Change:
fn parse_item_trait(&mut self, attrs: &mut AttrVec, lo: Span) -> PResult<'a, ItemInfo> { let unsafety = self.parse_unsafety(Case::Sensitive); // Parse optional `auto` prefix. <del> let is_auto = if self.eat_keyword(kw::Auto) { IsAuto::Yes } else { IsAuto::No }; </del> <ins> let is_auto = if self.eat_keyword(kw::Auto) { self.sess.gated_spans.gate(sym::auto_traits, self.prev_token.span); IsAuto::Yes } else { IsAuto::No }; </ins> self.expect_keyword(kw::Trait)?; let ident = self.parse_ident()?;

Discussion:
The following code builds on stable without even a warning: That is surprising since there was some effort recently to start ensuring that unstable syntax does not "leak" into stable Rust, so I expected at least a future-compatibility warning. (See e.g. ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
from the code I'd expect a warning:
ah no, auto traits don't use that gating: When parsing an auto trait in the parser, we need to gate it's span and then in the feature gating pass gate it too. This will look similar to, for example, traitalias.
was just for syntax which was previously attempted to reverse stabilization and had the gating code there but disabled. Now that the plumbing exists, using that as a template to add this syntax to the warning should be fairly straightforward. It might make sense to go ahead and crater immediately making this a hard feature gate, though.
I can already tell you of one large regression, the . We should do the feature gating normally as a warning and worry about making it an error later. Once it's a warning, people adding uses get warnings and we should be fine.
A bit unrelated, but I think it would be useful to have docs somewhere that show how to resolve this issue if you have the feature behind a cfg, the easiest solution being a macro_rules macro. But that doesn't have to be fixed here.
Change:
<ins> error[E0308]: match arms have incompatible types --> $DIR/issue-67273-assignment-match-prior-arm-bool-expected-unit.rs:22:14 | LL | /     match i { LL | |         // Add `bool` to the overall `coercion`. LL | |         0 => true, | |              ---- this is found to be of type `bool` LL | | LL | |         // Necessary to cause the ICE: LL | |         1 => true, | |              ---- this is found to be of type `bool` ...  | LL | |         2 => i = 1, | |              ^^^^^ expected `bool`, found `()` ...  | LL | |         _ => (), LL | |     } | |_____- `match` arms have incompatible types error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Code: <details<summaryBacktrace</summary</details
modify labels: I-ICE C-Bug T-compiler A-mir Regression from 1.34 to 1.35
Additionally, this one ICEs with different error message: () <details<summaryBacktrace</summary</details
This code should not get all the way to codegen without an error
Another, different ICE? <details<summaryBacktrace</summary</summary
Regression somewhere between ...
looks suspicious, cc In particular, maybe is falsly returning here since the expected type is due to the other match arms?
Change:
kind: hir::ExprKind::Closure(hir::Closure { kind, .. }), .. }) = node { <ins> // See `ClosureArgsParts`, `CoroutineArgsParts`, and `CoroutineClosureArgsParts` // for info on the usage of each of these fields. </ins> let dummy_args = match kind { ClosureKind::Closure => &["<closure_kind>", "<closure_signature>", "<upvars>"][..], <del> ClosureKind::Coroutine(_) => { &["<resume_ty>", "<yield_ty>", "<return_ty>", "<witness>", "<upvars>"][..] } </del> <ins> ClosureKind::Coroutine(_) => &[ "<coroutine_kind>", "<resume_ty>", "<yield_ty>", "<return_ty>", "<witness>", "<upvars>", ][..], </ins> ClosureKind::CoroutineClosure(_) => &[ "<closure_kind>", "<closure_signature_parts>",

Discussion:
<!-- [31mICE[0m: Rustc '-Zprint-mono-items=eager -Zpolymorphize=on --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: coroutine constructed with incorrect number of substitutions'', 'thread 'rustc' panicked at 'assertion failed: coroutine constructed with incorrect number of substitutions'' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [collectandpartitionmonoitems] collectandpartitionmonoitems [exported_symbols] collecting exported symbols for crate --
without debug assertions: &lt;!-- [31mICE[0m: Rustc '-Zprint-mono-items=eager -Zpolymorphize=on --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: [collectandpartitionmonoitems] collectandpartitionmonoitems [exported_symbols] collecting exported symbols for crate --
Regression in nightly-2024-02-07 cc
Change:
pub type TraitObligation<'tcx> = Obligation<'tcx, ty::PolyTraitPredicate<'tcx>>; /// Why did we incur this obligation? Used for error reporting. <del> #[derive(Clone)] </del> <ins> #[derive(Clone, PartialEq, Eq)] </ins> pub struct ObligationCause<'tcx> { pub span: Span,

Discussion:
That's a mouthful! To exemplify: This doesn't compile with , even though it does without it. Note that the only difference between the two configurations is that the function on is a free function instead of a default method. With , this fails with: Tested on
cc me
I've been running into very similar errors all day while updating my libs to the latest nightly. Here's an example of a method that works fine along with one that does not (simplest example I could come up with).
This example works now. I think this was a dup of
I just updated to master and I'm still running into the same error - perhaps my error is a separate issue?
Edwardw's PR does seem to fix my issue however, perhaps it addresses something extra?
The original issue is still present if the example on the first post is compiled with . I tested on , which contains Edit: just compiled . Still reproducible
Change:
} } <ins> pub fn require_owned_box(&self) -> Result<ast::DefId, String> { self.require(OwnedBoxLangItem) } </ins> pub fn from_builtin_kind(&self, bound: ty::BuiltinBound) -> Result<ast::DefId, String> {

Discussion:
Hi, first time contributor here. This might be a bug. I think every factor mentioned in the title is required to trigger this. (I'm trying to do horrible things to the runtime, but I don't think this is significant here.) Source: Backtrace (rustc 0.13.0-nightly ( 2015-01-04 00:50:59 +0000) installed via rustup on Ubuntu LTS):
This happened to me as well, with an almost identical program. More info:
Following the backtrace, it looks like assumes that the 'ownedbox' lang item is always defined and calls unwrap(), triggering the panic.
Triage: still ICEs:
Change:
<ins> error[E0283]: type annotations needed --> $DIR/issue-71732.rs:18:10 | LL |         .get(&"key".into()) |          ^^^  ------------ this method call resolves to `T` |          | |          cannot infer type for type parameter `Q` declared on the associated function `get` | = note: cannot satisfy `String: Borrow<_>` error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. </ins>

Discussion:
This is either a regression of or it was closed prematurely. Fairly minimal reproducer: - I'm still not entirely sure what is actually wrong here - is it the lifetime as in ? Anyhow - the message doesn't refer to any T that needs to be specified, and the named explicit type is not sufficient to fix the issue even when given. Happens with nightly too.
Right, so the triggering problem here is the call - with that fixed it all falls into place, but the error message is still poor.
I got hit by this bug too and in my case the fix isn't obvious (it's a mix of an iterator and ). What did you mean by "fixing the get() call"?
It has a parameter type that is a bit bonkers given the type of the Hash, which causes the type inference of the to go off into the weeds I think; doesn't change that there is a bug - this is about the diagnostics after all. is a fixed version of the broken code.
The error message should have been fixed by , marking as .