jiebi/CodeConvo huggingface dataset:
Change:
/// Does this value have parameters/placeholders/inference variables which could be /// replaced later, in a way that would change the results of `impl` specialization? const STILL_FURTHER_SPECIALIZABLE = 1 << 18; <del> /// Flags representing the nominal content of a type, /// computed by FlagsComputation. If you add a new nominal /// flag, it should be added here too. const NOMINAL_FLAGS               = TypeFlags::HAS_TY_PARAM.bits | TypeFlags::HAS_RE_PARAM.bits | TypeFlags::HAS_CT_PARAM.bits | TypeFlags::HAS_TY_INFER.bits | TypeFlags::HAS_RE_INFER.bits | TypeFlags::HAS_CT_INFER.bits | TypeFlags::HAS_TY_".bits | TypeFlags::HAS_RE_".bits | TypeFlags::HAS_CT_".bits | TypeFlags::HAS_FREE_LOCAL_REGIONS.bits | TypeFlags::HAS_TY_PROJECTION.bits | TypeFlags::HAS_TY_OPAQUE.bits | TypeFlags::HAS_CT_PROJECTION.bits | TypeFlags::KEEP_IN_LOCAL_TCX.bits | TypeFlags::HAS_TY_ERR.bits | TypeFlags::HAS_FREE_REGIONS.bits | TypeFlags::HAS_RE_LATE_BOUND.bits | TypeFlags::HAS_RE_ERASED.bits | TypeFlags::STILL_FURTHER_SPECIALIZABLE.bits; </del> } }

Discussion:
This seems to contain all the flags in . If I'm guessing right, the flags that used to not be in here, all turned into queries? So they're now cached as queries, instead of by mutating itself? cc
If it contains all the flags, then it seems to have no purpose. I'm honestly not sure what the name "nominal" is even meant to refer to here exactly -- I'm sure I gave it that name, but it's not very clear. I guess the point is "flags that should be inherited by containing types; ie., if the type has some flag , and is "nominal", then should also have ". Are there any flags that don't meet that definition anymore?
I think there were "nominal flags" and "cached properties" (using interior mutability), but now the latter is completely gone.
that sounds right. I'd be in favor of removing then.
I would love to help with this one. A quick search shows that is only used once in the entire code base, here: Looks like this could just be changed to Is that all it will take?
Sounds correct, yeah.
Cool great
Oops, I'm still learning git. Sorry for the spam there. Only is relevant.
Change:
* The _backslash escape_ is the character `U+005C` (``) which must be escaped in order to denote its ASCII encoding `0x5C`. <ins> ##### Raw byte string literals </ins> Raw byte string literals do not process any escapes. They start with the character `U+0062` (`b`), followed by `U+0072` (`r`), followed by zero or more of the character `U+0023` (`#`), and a `U+0022` (double-quote) character. The

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> error: invalid suffix `u` for number literal --> $DIR/bad-literal.rs:6:5 | LL |     1u; |     ^^ invalid suffix `u` | = help: the suffix must be one of the numeric types (`u32`, `isize`, `f32`, etc.) error: aborting due to previous error </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
Reduced: `
Regression in
The assert was in I MENT (sorry, I should no do this on the phone... :roll_eyes: ) cc
Change:
<ins> // Copyright 2018 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. pub trait Foo<'a> { type Bar; fn foo(&'a self) -> Self::Bar; } impl<'a, 'b, T: 'a> Foo<'a> for &'b T { type Bar = &'a T; fn foo(&'a self) -> &'a T { self } } pub fn uncallable<T, F>(x: T, f: F) where T: for<'a> Foo<'a>, F: for<'a> Fn(<T as Foo<'a>>::Bar) { f(x.foo()); } pub fn catalyst(x: &i32) { broken(x, |_| {}) } pub fn broken<F: Fn(&i32)>(x: &i32, f: F) { uncallable(x, |y| f(y)); } fn main() { } </ins>

Discussion:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.
Change:
#![feature(slice_group_by)] #![feature(vec_extend_from_within)] #![feature(vec_spare_capacity)] <ins> #![feature(string_remove_matches)] </ins> use std::collections::hash_map::DefaultHasher; use std::hash::{Hash, Hasher};

Discussion:
Like , but doesn't result in any allocations. I started implementing this in but got stuck, mainly because of limitations in the APIs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
assert_eq!(stringify_vis!(pub(crate)), "pub(crate) "); assert_eq!(stringify_vis!(pub(self)), "pub(self) "); assert_eq!(stringify_vis!(pub(super)), "pub(super) "); <del> assert_eq!(stringify_vis!(pub(in self)), "pub(self) "); assert_eq!(stringify_vis!(pub(in super)), "pub(super) "); </del> <ins> assert_eq!(stringify_vis!(pub(in crate)), "pub(in crate) "); assert_eq!(stringify_vis!(pub(in self)), "pub(in self) "); assert_eq!(stringify_vis!(pub(in super)), "pub(in super) "); </ins> assert_eq!(stringify_vis!(pub(in path::to)), "pub(in path::to) "); assert_eq!(stringify_vis!(pub(in ::path::to)), "pub(in ::path::to) "); assert_eq!(stringify_vis!(pub(in self::path::to)), "pub(in self::path::to) ");

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. --I tried this code: I expected to see this happen: it to print . Instead, this happened: it prints . <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.62.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- 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-beta -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Similar effect can already be observed on stable too prints already. But it is indeed a (small?) behavior change in this beta for the case.
I would expect to see this issue in 2020, but not now when we are collecting tokens in (almost) all cases instead of converting them from AST. Apparently for visibilities they are collected incorrectly for some reason. cc (in case you have time for this)
bisection points to searched nightlies: from nightly-2022-01-01 to nightly-2022-08-03 regressed nightly: nightly-2022-05-24 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsThe commit is a rollup so I think_ it's in cc ?
Without even looking at the rest of the rollup, it's definitely my PR. Short of storing whether was used, I'm not sure what could be done.
This will slip into 1.63.

I'll work on this this evening to get it resolved quickly, even if it is too late to patch the beta. I don't think it'll be too difficult.
PR is up: . This also fixes to be , which is certainly better than the status quo of .
Change:
// Can't check len now because count consumes. } <ins> #[test] fn test_once() { let mut it = once(42); assert_eq!(it.next(), Some(42)); assert_eq!(it.next(), None); } #[test] fn test_empty() { let mut it = empty::<i32>(); assert_eq!(it.next(), None); } </ins> #[bench] fn bench_rposition(b: &mut Bencher) { let it: Vec<usize> = (0..300).collect();

Discussion:
cc
Are you OK with just a PR?
Sure!
Is it worth writing tests for this? I'm not really sure how it could break, but better safe than sorry I suppose...
Yeah but just some simple tests would be fine to have
ping?
Working on it right now. , Steven Allen wrote:
Thanks. I had some free time so I thought I'd check.
Change:
shutil.rmtree(os.path.join(dst, fname)) <del> def run(args, verbose=False, exception=False, is_bootstrap=False, help_on_error=None, **kwargs): </del> <ins> def run(args, verbose=False, exception=False, is_bootstrap=False, **kwargs): </ins> """Run a child program in a new process""" if verbose: print("running: " + ' '.join(args))

Discussion:
I accidentally missed this when porting it to rustbuild: It would be nice to add it back. Mentoring instructions: Add a new parameter to and pass it down from : This code moved around in so you may want to base your changes off that PR until it lands. label +E-easy +E-mentor +A-rustbuild <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please also remove the dead code from at the same time:
claim
Change:
<ins> error[E0282]: type annotations needed --> $DIR/incompat-call-after-qualified-path-0.rs:21:6 | LL |   f(|a, b| a.cmp(b)); |      ^     - type must be known at this point | help: consider giving this closure parameter an explicit type | LL |   f(|a: /* Type */, b| a.cmp(b)); |       ++++++++++++ error[E0061]: this function takes 0 arguments but 1 argument was supplied --> $DIR/incompat-call-after-qualified-path-0.rs:21:3 | LL |   f(|a, b| a.cmp(b)); |   ^ --------------- unexpected argument | note: function defined here --> $DIR/incompat-call-after-qualified-path-0.rs:17:4 | LL | fn f() {} |    ^ help: remove the extra argument | LL -   f(|a, b| a.cmp(b)); LL +   f(); | error: aborting due to 2 previous errors Some errors have detailed explanations: E0061, E0282. For more information about an error, try `rustc --explain E0061`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'', 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in nightly-2022-06-04 commit[0] 2022-06-02: Auto merge of - nnethercote:lazify-SourceFile-lines, r=Mark-Simulacrum commit[1] 2022-06-02: Auto merge of - spastorino:simplify-universal-impl-trait-lowering, r=cjgillot commit[2] 2022-06-03: Auto merge of - matthiaskrgr:rollup-5cfxc85, r=matthiaskrgr commit[3] 2022-06-03: Auto merge of - c410-f3r:z-errors, r=petrochenkov commit[4] 2022-06-03: Auto merge of - cjgillot:remove-label-lt-shadow, r=petrochenkov commit[5] 2022-06-03: Auto merge of - Dylan-DPC:rollup-nswmgmx, r=Dylan-DPC commit[6] 2022-06-03: Auto merge of - lcnr:path-generics-diagnostics, r=estebank commit[7] 2022-06-03: Auto merge of - Dylan-DPC:rollup-2yxo7ce, r=Dylan-DPC commit[8] 2022-06-03: Auto merge of - bjorn3:serde_json, r=wesleywiser commit[9] 2022-06-03: Auto merge of - notriddle:notriddle/human-readable-signals, r=yaahc ERROR: no CI builds available between and within last 167 days
It appears I'm hitting this one as well. Tacking this on for good measure. <details</details
Looks like it was originally introduced by (and was renamed later to without any change in functionality). I'd PR a fix but I'm not entirely sure how it's supposed to work. Is this masking a deeper bug or can one simply do something like: Derp, missed there was a PR. indeed fixes this on my end. Thanks for the quick fix on this!
Change:
<del> error: non-binding let on a type that implements `Drop` </del> <ins> error: non-binding let on a type that has a destructor </ins> --> $DIR/issue-119697-extra-let.rs:15:5 | LL |     _ = field;

Discussion:
I tried this code: I got this warning: However, there is no impl on the type, so the error message is misleading. It is true however that there is a destructor, as defined here: That being said, it's insiginificant for all underlying types (only destructor of and type in the ), so ideally the warning still wouldn't even show. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Well, even if the parameter of is , it still has a side-effect (deallocates memory). I don't think we need this special-casing. I do think the diagnostic is a bit misleading and should just say "has a destructor" or "has side-effects when dropped". Is there a more practical code example for why you'd want to suppress this error? The example you gave is a bit artificial, so it's a hard to motivate why we'd want to suppress this code since it really could be rewritten to be clearer.
claim
Change:
let pat = self.parse_pat_with_range_pat(false, None)?; self.sess.gated_spans.gate(sym::box_patterns, lo.to(self.prev_token.span)); PatKind::Box(pat) <del> } else if self.check_inline_const() { </del> <ins> } else if self.check_inline_const(0) { </ins> // Parse `const pat` <del> PatKind::Lit(self.parse_const_expr(lo.to(self.token.span))?) </del> <ins> let const_expr = self.parse_const_block(lo.to(self.token.span))?; if let Some(re) = self.parse_range_end() { self.parse_pat_range_begin_with(const_expr, re)? } else { PatKind::Lit(const_expr) } </ins> } else if self.can_be_ident_pat() { // Parse `ident @ pat` // This can give false positives and parse nullary enums,

Discussion:
As soon as I've seen the new inline_const feature, I've tried to find some use cases for it in my code, and I did find only very few of them, unfortunately, and one of the two uses cases could be reduced to this: That gives errors: So I am not sure if this is a bug report or an enhancement request.
Note that this does work in expressions ():
Support for ranges in patterns ( or ) needs to be separately, to and respectively.
Ohh I've just realized that we had this issue opened, I've fixed this in Going to adjust description of the PR accordingly so it closes this issue when merged.
Change:
.. }) => { if in_trait && !tcx.impl_defaultness(owner).has_value() { <del> span_bug!(tcx.def_span(def_id), "tried to get type of this RPITIT with no definition"); </del> <ins> span_bug!( tcx.def_span(def_id), "tried to get type of this RPITIT with no definition" ); </ins> } find_opaque_ty_constraints_for_rpit(tcx, def_id, owner) }

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
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in
aaah shit, the commit only modified the backtrace :laughing: so "panicked at" no longer triggers before that..
`
maybe
Change:
<ins> error: `recursion_limit` must be a non-negative integer --> $DIR/empty.rs:3:1 | LL | #![recursion_limit = ""] | ^^^^^^^^^^^^^^^^^^^^^--^ |                      | |                      `recursion_limit` must be a non-negative integer error: aborting due to previous error </ins>

Discussion:
The following code since it exceeds the default recursion limit. Using as the recursion limit works as expected. This is because we don't check for integer overflow errors when parsing limits: There's a few options here. My preference would be to silently default to when overflow occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi! I'd like to try and handle this. If I understand this correctly, we should check if there is an , and if that error is an overflow. If it's an overflow, we default to ? claim
correct
Change:
fn check_item(&self, item: &hir::Item) { let def_id = self.tcx.map.local_def_id(item.id); match item.node { <del> hir::ItemImpl(_, _, _, None, _, _) => { </del> <ins> hir::ItemImpl(_, _, _, None, ref ty, _) => { </ins> // For inherent impls, self type must be a nominal type // defined in this crate. debug!("coherence2::orphan check: inherent impl {}",

Discussion:
From: src/test/compile- Error E0118 needs a spanlabel and a spannote to be a simple note, updating from: To: Bonus: It'd be good if we could underline the type it's complaining about.
In case no one is working with this yet, I can give this a go.

From: src/test/compile- Error E0117 needs a span_label, updated error text, and a note, updating it from: to:
In case no one is working with this yet, I can give this a go.
Change:
<ins> error[E0433]: failed to resolve: maybe a missing crate `core`? --> $DIR/issue-102156.rs:4:5 | LL | use core::convert::{From, TryFrom}; |     ^^^^ maybe a missing crate `core`? | = help: consider adding `extern crate core` to use the `core` crate error[E0433]: failed to resolve: maybe a missing crate `core`? --> $DIR/issue-102156.rs:4:5 | LL | use core::convert::{From, TryFrom}; |     ^^^^ maybe a missing crate `core`? | = help: consider adding `extern crate core` to use the `core` crate error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0433`. </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. --code from <!-- 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 --
couple of files from the repo that reproduce this: ./src/test/ui/rfc-2632-const-trait-impl/staged-
This regressed in cc
Thanks for the bisection. This should be a simple fix: Replace with And add a test as well :) label E-easy
claim
Are you still working on this? If not, I would like to fix this as soon as possible.
Sorry for the delay, no problem. Thanks.
Change:
let fty = ty::node_id_to_type(cx.tcx, id); match ty::get(fty).sty { ty::ty_closure(box ty::ClosureTy { <del> store: ty::UniqTraitStore, bounds, .. }) => b(|cx, fv| check_for_uniq(cx, fv, bounds)), </del> <ins> store: ty::UniqTraitStore, bounds: mut bounds, .. }) => { // Procs can't close over non-static references! bounds.add(ty::BoundStatic); b(|cx, fv| check_for_uniq(cx, fv, bounds)) } </ins> ty::ty_closure(box ty::ClosureTy { store: ty::RegionTraitStore(region, _), bounds, ..

Discussion:
Example: The last statement is mutably borrowing x but x is already borrowed (or rather should be) by the proc. The result is a program that compiles fine but segfaults when run.
cc Nominating, closure shouldn't be able to capture borrowed variables.
I'm pretty sure the proc "code" needs a thorough review, giving this issue along with all the other similar proc bugs.
cc
P-backcompat-lang, 1.0.
Change:
) .into(), ty::GenericParamDefKind::Type { .. } => { <del> if !emitted_bad_param_err { </del> <ins> let guar = *emitted_bad_param_err.get_or_insert_with(|| { </ins> tcx.dcx().emit_err( crate::errors::ReturnTypeNotationIllegalParam::Type { span: path_span, param_span: tcx.def_span(param.def_id), }, <del> ); emitted_bad_param_err = true; } Ty::new_bound( tcx, ty::INNERMOST, ty::BoundTy { var: ty::BoundVar::from_usize(num_bound_vars), kind: ty::BoundTyKind::Param(param.def_id, param.name), }, ) .into() </del> <ins> ) }); Ty::new_error(tcx, guar).into() </ins> } ty::GenericParamDefKind::Const { .. } => { <del> if !emitted_bad_param_err { </del> <ins> let guar = *emitted_bad_param_err.get_or_insert_with(|| { </ins> tcx.dcx().emit_err( crate::errors::ReturnTypeNotationIllegalParam::Const { span: path_span, param_span: tcx.def_span(param.def_id), }, <del> ); emitted_bad_param_err = true; } </del> <ins> ) }); </ins> let ty = tcx .type_of(param.def_id) .no_bound_vars() .expect("ct params cannot have early bound vars"); <del> ty::Const::new_bound( tcx, ty::INNERMOST, ty::BoundVar::from_usize(num_bound_vars), ty, ) .into() </del> <ins> ty::Const::new_error(tcx, guar, ty).into() </ins> } }; num_bound_vars += 1;

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -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: [typeopnormalizeclause] normalizing [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --