jiebi/CodeConvo huggingface dataset:
Change:
<ins> warning: non-local `impl` definition, they should be avoided as they go against expectation --> $DIR/trait-solver-overflow-123573.rs:12:5 | LL |     impl Test for &Local {} |     ^^^^^^^^^^^^^^^^^^^^^^^ | = help: move this `impl` block outside the of the current function `main` = note: an `impl` definition is non-local if it is nested inside an item and may impact type checking outside of that item. This can be the case if neither the trait or the self type are at the same nesting level as the `impl` = note: one exception to the rule are anon-const (`const _: () = { ... }`) at top-level module and anon-const at the same nesting as the trait or type = note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363> = note: `#[warn(non_local_definitions)]` on by default warning: 1 warning emitted </ins>

Discussion:
Sorry, I don't have simple code to reproduce the issue, because the project is large. The repro is this: Contents of the mentioned file is: I tried increasing , did not help. Also works on stable. This may be duplicate of because timing.
This is also affecting :
Using the starlark-rust repro, this bisects to
overflow is fatal in the old trait solver, so by proving additional goals, especially if they have inference variables, we can end up with new sources of overflow causing an error. the most straightforward fix is to use the new solver for this lint given that the lint uses an empty environment it uses pretty much the same parts of the solver as coherence so it should already be ready for that
WG-prioritization assigning priority (). label -I-prioritize +P-high
I have a somewhat minimal repro, it has a lot of deps (via bevy) but not much code: Where is not something (I think) that can be decomposed into a tuple.
Change:
} } <ins> /// Returns `true` if `other` is earlier in the control flow graph than `self`. pub fn is_predecessor_of<'tcx>(&self, other: Location, mir: &Mir<'tcx>) -> bool { // If we are in the same block as the other location and are an earlier statement // then we are a predecessor of `other`. if self.block == other.block && self.statement_index < other.statement_index { return true; } // If we're in another block, then we want to check that block is a predecessor of `other`. let mut queue: Vec<BasicBlock> = mir.predecessors_for(other.block).clone(); let mut visited = FxHashSet::default(); while let Some(block) = queue.pop() { // If we haven't visited this block before, then make sure we visit it's predecessors. if visited.insert(block) { queue.append(&mut mir.predecessors_for(block).clone()); } else { continue; } // If we found the block that `self` is in, then we are a predecessor of `other` (since // we found that block by looking at the predecessors of `other`). if self.block == block { return true; } } false } </ins> pub fn dominates(&self, other: Location, dominators: &Dominators<BasicBlock>) -> bool { if self.block == other.block { self.statement_index <= other.statement_index

Discussion:
review comments:
triage: P-medium. (We should look into this, but even if its wrong, I'm not going to push to a backport its hypothetical bug fix.)

review comments: For the record, here's the relevant part of the test in question ():
This should be NLL-complete, not NLL-sound, right?
Yeah, it should. My bad.
triage: P-high, not not Release milestone. This issue is bad enough for fix quickly, but there's no reason to beta-backport (as I explained on the PR itself here )
Change:
<ins> error: higher-ranked subtype error --> $DIR/issue-59311.rs:17:9 | LL |     v.t(|| {}); |         ^^^^^ error: aborting due to previous error </ins>

Discussion:
ICEes when trying to compile the following code. As far as I can tell, the issue is due to the HRTB. All other issues I found mentioning where either using unstable features and/or related to which seems to be unrelated to this issue. On the playground, I am able to reproduce the ICE on stable (1.33), beta, and nightly. Locally I have the following setup: : Backtrace:
Triage: Reproduces as of 2020-03-10.
Triage: This ICE has been fixed in the latest nightly, I assume it's fixed by . Marking as .
Change:
<ins> // edition:2018 mod core { use core; //~ ERROR `core` is ambiguous use crate::*; } fn main() {} </ins>

Discussion:
On stable and the code compiles successfully. On the code fails to compile with: At first I thought this was part of but now I think it is different because it started happening on whereas that issue is from November. This is currently causing ggez to fail to compile on nightly:
With uniform paths, which will be in 1.32, this compiles, so this should resolve itself I think. cc
So, this is indeed a regression from Looks like you missed the part, I'm still able to reproduce the error with .
It's not obvious to me right away what behavior is right here, pre- or post-. I'll look in more detail.
The ambiguity is reported correctly. I.e. it's obvious that there's an ambiguity (the error message says what exactly), but before the ambiguity wasn't detected due to "self-confirming" import "standing in the way". It's great that the fix got into 1.32 stable, so the time for which the issue existed on stable was minimized. Minimized reproduction:
Test in
Change:
// shunted into "everything else" match state { PartitionState::Attrs => { <del> state = if trimline.starts_with("#![") || trimline.chars().all(|c| c.is_whitespace()) </del> <ins> state = if trimline.starts_with("#![") { if !check_if_attr_is_complete(line, edition) { mod_attr_pending = line.to_owned(); } else { mod_attr_pending.clear(); } PartitionState::Attrs } else if trimline.chars().all(|c| c.is_whitespace()) </ins> || (trimline.starts_with("//") && !trimline.starts_with("///")) { PartitionState::Attrs

Discussion:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:
Change:
RegionsDoesNotOutlive(&'tcx Region, &'tcx Region), RegionsNotSame(&'tcx Region, &'tcx Region), RegionsNoOverlap(&'tcx Region, &'tcx Region), <del> RegionsInsufficientlyPolymorphic(BoundRegion, &'tcx Region), RegionsOverlyPolymorphic(BoundRegion, &'tcx Region), </del> <ins> RegionsInsufficientlyPolymorphic(BoundRegion, &'tcx Region, Option<Box<ty::Issue32330>>), RegionsOverlyPolymorphic(BoundRegion, &'tcx Region, Option<Box<ty::Issue32330>>), </ins> Sorts(ExpectedFound<Ty<'tcx>>), IntMismatch(ExpectedFound<ty::IntVarValue>), FloatMismatch(ExpectedFound<ast::FloatTy>),

Discussion:
This code: Produces this internal compiler error: Interestingly, changing to or causes the code compile fine (modulo unused variable warnings). : Backtrace:
This is a regression in 1.17.0-beta. Earlier versions give:
Duplicate of .

Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.
Change:
<ins> error[E0425]: cannot find value `msg` in this scope --> $DIR/trivial-diagnostics.rs:4:21 | LL |     struct_span_err(msg).emit(); |                     ^^^ not found in this scope error[E0425]: cannot find function `struct_span_err` in this scope --> $DIR/trivial-diagnostics.rs:4:5 | LL |     struct_span_err(msg).emit(); |     ^^^^^^^^^^^^^^^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </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 --
I've seen this on a few ICE reports, but I'd recommend putting the first ICE in the title instead of any other subsequent ICE messages, since this: really is the root cause of this issue, and the second one (mentioning ) is just a side-effect of panicking during certain queries :smilecat:
searched toolchains nightly-2023-04-21 through nightly-2023-05-06 Regression in nightly-2023-04-27 Regression in Regression in cc
Oops claim
Change:
<ins> // run-rustfix fn main() { let x = "com.example.app"; let y: Option<&str> = None; let _s = y.unwrap_or_else(|| x.split('.').nth(1).unwrap()); //~^ ERROR: mismatched types [E0308] } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --should suggest if the argument is a closure instead of suggesting to call the closure Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.
Change:
//! # Representation //! //! Rust's string type, `str`, is a sequence of Unicode scalar values encoded as a <del> //! stream of UTF-8 bytes. All strings are guaranteed to be validly encoded UTF-8 //! sequences. Additionally, strings are not null-terminated and can thus contain //! null bytes. </del> <ins> //! stream of UTF-8 bytes. All [strings](../../reference.html#literals) are //! guaranteed to be validly encoded UTF-8 sequences. Additionally, strings are //! not null-terminated and can thus contain null bytes. </ins> //! //! The actual representation of strings have direct mappings to slices: `&str` //! is the same as `&[u8]`.

Discussion:
The doesn't document what escape sequences are valid if any. For example, documentation doesn't state whether this will match a newline as would be expected: It also doesn't specify what format these strings are supposed to be written in. Much of the documentation including many escape sequences are documented in the but it is difficult (slow) to parse as it is. I think it would be good to have it in or at least to make the reference more clear. More escape documentation is in (though it's not exactly related). For what it's worth, doesn't seem to document it either (at least, I couldn't find it). Below is my first shot at what it could look like. followed by any number (including zero) of 's followed by and closed in the reverse: A single ASCII character: A sequence of ASCII characters: Note: I'm not really familiar with all the string formats. I'm just to collect them together so they're more obvious. Does it make sense to collect them onto the  page? If so, I can probably submit a PR making something like this but I'm not sure where it should go.
Python , but in the language reference rather than the standard library documentation. Perhaps Rust’s escape sequences should be documented in the reference, where most other language-documenting features go.
Horizontal Tab, AKA t, ASCII/Unicode 9. See .
Oh, I completely misread this as 6 escapes (but it's 3 with their definitions). The .
I'm quite surprised to find that Rust doesn't have (i.e: 'backspace') built in to the language. Is there a particular reason for this?
asking on is a better place than on a three and a half year old issue.
Change:
<ins> // 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. mod A { pub mod B { use super::*; pub struct S; } pub mod C { use super::*; use super::B::S; pub struct T; } pub use self::C::T; } use A::*; fn main() {} </ins>

Discussion:
This code compiles: However, splitting the code into files causes compilation to fail: I am not sure whether or use is correct; regardless, replacing the latter with the former in produces a similar error:
cc
This appears to work now.
Change:
match b.kind() { ty::ConstKind::Infer(InferConst::Var(_)) if D::forbid_inference_vars() => { // Forbid inference variables in the RHS. <del> bug!("unexpected inference var {:?}", b) </del> <ins> self.infcx.tcx.sess.delay_span_bug( self.delegate.span(), format!("unexpected inference var {:?}", b,), ); Ok(a) </ins> } // FIXME(invariance): see the related FIXME above. _ => self.infcx.super_combine_consts(self, a, b),

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. --
Removing seems to fix it.
Reduced, with no nightly features (): Output on stable and beta: label regression-from-stable-to-nightly
bisection cc: searched nightlies: from nightly-2022-01-01 to nightly-2022-06-20 regressed nightly: nightly-2022-06-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Another snippet from
Change:
executing...", ); diag.note("...therefore, they cannot allow references to captured variables to escape"); <ins> self.suggest_move_on_borrowing_closure(&mut diag); </ins> diag }

Discussion:
Given the following code: The current output is: The actually needed fix here is the following, which should ideally be recommended <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
slightly more minimal:
claim
I came up with a solution of printing an extra line of to give user a recommendation of fixing the error by adding 'move' keyword before the closure parameter of map(). The following is the output for the first testing code. Is this good enough? This is the output from the second testing code ():
Refined the fix with a verbose suggestion of where to add keyword. The output of the first test case is: The output of the second test case is: In addition, the fix will also add the suggestion for nested closure block like this test case: The output of the above test case is:
Change:
<ins> // run-pass #![feature(adt_const_params, generic_const_exprs)] #![allow(incomplete_features)] pub trait Foo { const ASSOC_C: usize; fn foo() where [(); Self::ASSOC_C]:; } struct Bar<const N: &'static ()>; impl<const N: &'static ()> Foo for Bar<N> { const ASSOC_C: usize = 3; fn foo() where [u8; Self::ASSOC_C]: { let _: [u8; Self::ASSOC_C] = loop {}; } } fn main() {} </ins>

Discussion:
: <details<summaryerror output</summary</details
Rust playground:
Have you been able to reproduce this ICE with the latest nightly?
Playground link is not failing, I guess it's a good sign.
No longer ICEs since

The code below will trigger an ICE on the latest nightly build This is as small as i could make it while still triggering the error <!-- 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
Also occurs on stable! Regression from 1.50 to 1.51 modify labels: -requires-nightly +regression-from-stable-to-stable
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-04-29 regressed nightly: nightly-2021-01-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed PR is , cc
See and
just because something is gated doesn't mean it can't crash on stable ;) Use the above code and try to build it on the playground or compile it with a stable compiler, it will ICE.
We briefly discussed this on . I'd revert some labels here because we think this is a nightly-only issue due to the unstable feature. The fact that it compiles and reproduces on stable is kind of misleading because it's the that allows that. Makes sense? modify labels: +requires-nightly -regression-from-stable-to-stable +P-medium
sure enough ;) but just to be clear, even without this results in an ICE on stable
Okay so this is a bit complicated. Because while this does has , is still ICEs on stable. That said, not including the feature gate doesn't ICE. Given that, I think the current labels are appropriate, except maybe . It is technically a stable to stable regression, but it requires a feature to ICE, and I'm not sure that's the spirit of what that label is intended to track.
agreed on the labels, I've got the context partially wrong here. modify labels: -requires-nightly
With this also doesn't ICE
No longer ICEs since as far as I could tell with various combinations of the new feature gates
Change:
= note: for more information, see issue #62411 <https://github.com/rust-lang/rust/issues/70861> error: function pointers and raw pointers not derived from integers in patterns behave unpredictably and should not be relied upon. See https://github.com/rust-lang/rust/issues/70861 for details. <del> --> $DIR/issue-34784-match-on-non-int-raw-ptr.rs:28:9 </del> <ins> --> $DIR/issue-34784-match-on-non-int-raw-ptr.rs:30:9 </ins> | LL |         D => {} |         ^

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Got a scalar pair where a scalar was expected', 'error: internal compiler error: Got a scalar pair where a scalar was expected' File: --code: 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
Regression in nightly-2023-11-09 ping
Good catch, thanks! should fix this.
Change:
// - It is correct to do so -- only hashing a subset of `self` is still //   with an `Eq` implementation that considers the entire value, as //   ours does. <del> (self.t as u64).hash(state); </del> <ins> self.t.1.hash(state); </ins> } }

Discussion:
On Apple Silicon (unlike x8664) is 16-bytes aligned. So it takes extra space with little or no benefit. I looked at generated code, it is the same: (Note just using won't work because it will pass by reference not by value) Additionally the issue with current is that is has different alignment on different platforms. Rust does not provide guarantees about the alignment, but if this was the same everywhere, it'd make life easier. (Practically we encountered this issue when our CI worked fine on Apple x8664 macs, but the program didn't work on Apple Silicon.) rustc 1.74.0-nightly ( 2023-09-05) macOS, Apple Silicon
Note that doesn't have the same alignment on all platforms either. It will be 4-aligned on (some) 32bit platforms.
I might be wrong here, but seems to work, so I believe is . So can't said problem be eliminated by implementing on as well?
already implements . Also does not affect alignment.
If that's the case, how about
That would make hashing and probably equality slower.
on 32 bit system would not be slower
Change:
} let filename = format!("rustfmt-{version}-{build}.tar.xz", build = host.triple); <del> // cfg(bootstrap): will need to be changed from `rustfmt-preview` to `rustfmt` the next time you run `bump-stage0`. // See <https://github.com/rust-lang/rust/pull/103648> </del> self.download_component(DownloadSource::Dist, filename, "rustfmt-preview", &date, "stage0"); self.fix_bin_or_dylib(&bin_root.join("bin").join("rustfmt"));

Discussion:
It should not be possible that clippy component is missing since we are gating on it in CI..? cc
I think this is a rustup bug somehow, it's looking specifically for : I can back this out to give rustup time to fix it in a new release, this wasn't an urgent fix. I want to spend another few minutes investigating first though.
I don't think rustup's rename system is designed to allow changing the name of a component. contains more information about how and why this was done.
says I need at a minimum to keep the key for clippy-preview. I will try to test that out today but I don't have permissions for a dist-static build and it might take me a bit so I'll put up a revert in the meantime.
I'm happy to run dev-static builds as needed, but I agree that a revert is appropriate for the time being. Please feel free to poke on Zulip if you need a quick review, etc. I'm a little surprised our testing in didn't catch this -- let's make sure we understand how to test it in the future.
what went wrong in is that worked before and after, but running before and after did not. I'll make sure to test that in any future PR.
Change:
# $(3) is host # $(4) tag define DEF_PREPARE_HOST_TOOL <ins> prepare-host-tool-$(1)-$(2)-$(3)-$(4):  PREPARE_SOURCE_BIN_DIR=$$(HBIN$(2)_H_$(3)) </ins> prepare-host-tool-$(1)-$(2)-$(3)-$(4): prepare-maybe-clean-$(4)  $$(foreach dep,$$(TOOL_DEPS_$(1)),prepare-host-lib-$$(dep)-$(2)-$(3)-$(4))  $$(HBIN$(2)_H_$(3))/$(1)$$(X_$(3)) 

Discussion:
There are no Windows nightlies currently being published: They appear to have been broken since at least Nov. 1. This prevents Servo from updating Rust. CC:
was looking into this earlier.