jiebi/CodeConvo huggingface dataset:
Change:
#[rustc_const_unstable(feature = "const_ascii_ctype_on_intrinsics", issue = "68983")] #[inline] pub const fn is_ascii_graphic(&self) -> bool { <del> self.is_ascii() && (*self as u8).is_ascii_graphic() </del> <ins> match *self { '!'..='~' => true, _ => false, } </ins> } /// Checks if the value is an ASCII whitespace character:

Discussion:
I noticed this check: and wondered why it's there. Then someone told me it's there because of the . If you pass a non-ASCII char, the would corrupt that char. That's why the check is there before it. But then I wondered: why isn't this just cast to a bigger data type that includes all Unicode code points? This method (and others) are slower than they have to be. Also see this discussion in Discord with more valuable information:
(I can’t seem to find the relevant part in the middle of this discord stream…) I’m not sure what you mean by “corrupt”. is well defined: it takes the numerical value of the code point (same as ), then truncates to keep the lower 8 bits. equals 0x41, but so does . We want to reject the latter since U+1F041 is not an ASCII upper-case letter. If is implemented in terms of , the ASCII range check is necessary. (It could be a range check to, for example with .) But maybe doesn’t need to be implemented in terms of . Maybe it could duplicate the logic instead. Once upon a time was implemented with a lookup table of 256 entries. A flat lookup table for all of Unicode would be way too big. But these days it’s based on matching a range pattern. Doing the same with a range pattern could also work. That said, would it actually be faster? Maybe the optimizer already does its job well. If you want to work on this, consider adding some benchmark to show that code duplication is worth it.
Oh it seems the Discord link is a bit buggy. Try searching for in the search bar on the Discord server. Then you should get to my message with the discussion below it. One guy also posted this comparison of the instructions generated:
I think the minimal standard here should be a benchmark before we change the implementation. Can you provide that?
I'm not that experienced with Rust yet, sorry. I just wanted to point out this possible performance regression. Shouldn't the instruction amount difference as shown on Godbolt suffice to know that it's slower? vs.
Looking at the assembly, it seems that the problem is the check. These three functions produce : So, it seems that the check is unnecessary. I could make a PR for this.

Here are some benchmarks: So it seems that removing the check has a measurable performance difference.
is incorrect. The conversion should happen not for the ASCII check but for the , and the pattern use byte literals like . (Though I expect this won’t affect results much.)
Change:
} }); <del> // It's tempting to just spawn all the tests at once, but since we have // many tests that run in other processes we would be making a big mess. let concurrency = get_concurrency(); </del> <ins> let concurrency = match opts.test_threads { Some(n) => n, None => get_concurrency(), }; </ins> let mut remaining = filtered_tests; remaining.reverse();

Discussion:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.
Change:
<ins> //@ check-pass //@ edition: 2021 // Demonstrates that an async closure may implement `FnMut` (not just `async FnMut`!) // if it has no self-borrows. In this case, `&Ty` is not borrowed from the closure env, // since it's fine to reborrow it with its original lifetime. See the doc comment on // `should_reborrow_from_env_of_parent_coroutine_closure` for more detail for when we // must borrow from the closure env. #![feature(async_closure)] fn main() {} fn needs_fn_mut<T>(x: impl FnMut() -> T) {} fn hello(x: &Ty) { needs_fn_mut(async || { x.hello(); }); } struct Ty; impl Ty { fn hello(&self) {} } </ins>

Discussion:
I've returned to one of my projects after a few months of pause. Before I was using rust nigthly ~1.7x (around November 2023). It also worked through whole 2022 and 2021 IIRC. I've moved to new computer and installed rust nightly 1.80 (latest). After upgrading I noticed that my whole codebase is full of errors around capturing something from environment. . However if I change to it builds and works like previosly. Minimal example below. The error for first method is: i booted my very old PC to check, this is definately not the last version this worked fine: I definately does not work with:
Minimal: This should be possible now to support due to changes in . I'll put up a fix soon.
Change:
<ins> error[E0107]: function takes 2 generic arguments but 1 generic argument was supplied --> $DIR/foreign-generic-mismatch-with-const-arg.rs:6:46 | LL |     foreign_generic_mismatch_with_const_arg::test::<1>(); |                                              ^^^^   - supplied 1 generic argument |                                              | |                                              expected 2 generic arguments | note: function defined here, with 2 generic parameters: `N`, `T` --> $DIR/auxiliary/foreign-generic-mismatch-with-const-arg.rs:1:8 | LL | pub fn test<const N: usize, T>() {} |        ^^^^ --------------  - help: add missing generic argument | LL |     foreign_generic_mismatch_with_const_arg::test::<1, T>(); |                                                      +++ error: aborting due to previous error For more information about this error, try `rustc --explain E0107`. </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. --Not sure how this passes the test suite :upsidedownface: Original code from reduced &lt;!-- 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. --: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongBacktrace&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details
This is caused by The fix is to either enable in - this improves diagnostics but pessimizes compile times for successful compilations. do not use spans of const generic parameters from other crates in diagnostics - this makes diagnostics worse but optimizes compile times for successful compilations.
I can't reproduce this either locally or in playground.
Weird, I can still repro locally with and master :shrug:
mcve from a different file:
This is also weird for me to reproduce: I must be doing something wrong, both my and toolchains are the same rustc/cargo commits ( and ): a (or rustc) ICEs on that stdsimd repro a (or rustc) does not a ICEs (but not rustc)
Yeah, something is very weird. I didn't manage to properly this when I tried. I also failed to reproduce on playground or godbolt, but I have encountered maybe around 20 more or less similar files that hit this ICE when checking reports.
Same for me, found a nightly but failed with the CI artifacts. If somehow invoking differently manually or with/without rustup makes things work or fail, maybe the tool also invokes things in the way that doesn't repro...
I forgot to mention: this does also reproduce on master and reverting seems to fix the ICE indeed, as vadim suggested above.
I'm going to remove has-mcve since we're not sure why it sometimes doesn't ICE.
I think this is the better solution. Otherwise, we'll have more and more special cases in diagnostic code which is already very complex.
Couple more reproducers:
Change:
// Correct delimiter. token::CloseDelim(d) if d == delim => { let (open_brace, open_brace_span) = self.open_braces.pop().unwrap(); <ins> let close_brace_span = self.token.span; if tts.is_empty() { let empty_block_span = open_brace_span.to(close_brace_span); self.last_delim_empty_block_spans.insert(delim, empty_block_span); } </ins> if self.open_braces.len() == 0 { // Clear up these spans to avoid suggesting them as we've found // properly matched delimiters so far for an entire block. self.matching_delim_spans.clear(); } else { self.matching_delim_spans.push( <del> (open_brace, open_brace_span, self.token.span), </del> <ins> (open_brace, open_brace_span, close_brace_span), </ins> ); } // Parse the close delimiter.

Discussion:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.
Change:
<ins> // edition:2018 // run-pass #![feature(async_await)] async fn foo(n: u32, mut vec: Vec<u32>) { vec.push(n); } fn main() {} </ins>

Discussion:
Code: Error: Rustc version: rustc 1.36.0-nightly ( 2019-05-02)
modify labels: A-async-await and T-compiler.
I wonder if this is related to the drop order fix desugaring?
Oops, looks like it is. Thanks for the fix.
Change:
if !self.type_ascription_suggestion(&mut err, base_error.span) { let mut fallback = self.suggest_trait_and_bounds(&mut err, source, res, span, &base_error); <ins> // if we have suggested using pattern matching, then don't add needless suggestions // for typos. </ins> fallback |= self.suggest_typo(&mut err, source, path, span, &base_error); if fallback { // Fallback label. err.span_label(base_error.span, &base_error.fallback_label);

Discussion:
Given the following code: The current output is: Ideally the output should look like: How do we remove other diagnostics in this scenario?
label +D-verbose
Change:
use syntax::ast_map::{path, path_mod, path_name}; use syntax::ast_util; use syntax::{ast, ast_map}; <del> use syntax::parse::token; </del> /** The main "translation" pass for methods.  Generates code

Discussion:
Configured with
I found that does not properly emit some information for android assembler. keep digging do you have any idea to fix this ?
some symbol starts with which arm as cannot recognize it [error] [orig]
Ok, I know what the issue is now. I changed the naming of the vtables, since they are internal, in order to make it easier to debug. So they now have the type attached. Apparently the 's don't get changed the same way the '<' and ''s do. I'll get on it.
works with below patch
Change:
// Simple cases, which don't need DST adjustment: //   * no metadata available - just log the case //   * known alignment - sized types, `[T]`, `str` or a foreign type <del> //   * packed struct - there is no alignment padding </del> <ins> // Note that looking at `field.align` is incorrect since that is not necessarily equal // to the dynamic alignment of the type. </ins> match field.ty.kind() { _ if self.llextra.is_none() => { debug!(

Discussion:
This code panics, but it should not: The panic disappears when the is inlined (because then we hit a different code path in ). What happens here is a bug in the logic that computes the offset of : since it is an unsized field, the offset is computed dynamically, by taking the statically known offset and then rounding it up to the dynamic alignment of the field. However, since the struct is packed, we need to cap the dynamic alignment of the field to the packing of the surrounding struct -- which we currently do not do. This is just yet another case where the non-compositional nature of is causing issues...
A slight variant of this code ICEs: It hits which, it seems, was never updated when support for was implemented.
WG-prioritization assigning priority (). label -I-prioritize +P-medium EDIT: lowered priority after discussion on Zulip
Change:
= note: consult the function's documentation for information on how to avoid undefined behavior error[E0133]: call to unsafe function `remove_var` is unsafe and requires unsafe block <del> --> $DIR/unsafe-env.rs:15:5 </del> <ins> --> $DIR/unsafe-env.rs:25:5 </ins> | LL |     env::remove_var("FOO"); |     ^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function

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: will become in Rust 2024, the above code is using Rust 2021, so this should compile with no issue. Instead, this happened: <!-- 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<summaryBacktrace</summary<pNot needed </p</detailsI think the root cause is the lint , commenting it out would make the code compile: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks for the report! That should not happen. We did a so I don't know how this is even possible... any ideas? This seems to be some bad interaction with .
claim Hmmm, weird that crater run didn't catch this.
I posted a PR fixing this: . Does crater maybe restrict lints?
I don't think it does. Is this code part of the "nix" crate?
If you are asking if this problem originates from the nix crate, then yes, see
I am wondering whether the nix crate as published on fails to build with latest nightly due to this issue.
I think yes, the has been in Nix for a long time. One should be able to reproduce the build failure on a UNIX platform other than: I am currently on Linux, will try reproducing it on my mac tomorrow.
Looks like crater tested nix 0.26.4 and that failed already before the removevar/setvar change (). That's due to the which makes the build fail even when there are just warnings. I guess we can add this to the list of why having deny(warnings) in the code is considered bad practice.
I created an issue and a PR against nix-rust.
Yeah, we can reproduce this on macOS
The reason this was missed is a combination of and
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix already exists, just needs a review: .
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. fn main() { let thing = (); let other: typeof(thing) = thing; //~ ERROR attempt to use a non-constant value in a constant //~^ ERROR `typeof` is a reserved keyword but unimplemented [E0516] } fn f(){ let q = 1; <typeof(q)>::N //~ ERROR attempt to use a non-constant value in a constant //~^ ERROR `typeof` is a reserved keyword but unimplemented [E0516] } </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:
} } <ins> /// Checks whether there is a local type somewhere in the chain of /// autoderefs of `rcvr_ty`. fn type_derefs_to_local<'a, 'tcx>(fcx: &FnCtxt<'a, 'tcx>, span: Span, rcvr_ty: Ty<'tcx>) -> bool { check::autoderef(fcx, span, rcvr_ty, None, check::UnresolvedTypeAction::Ignore, check::NoPreference, |&: ty, _| { let is_local = match ty.sty { ty::ty_enum(did, _) | ty::ty_struct(did, _) => ast_util::is_local(did), ty::ty_trait(ref tr) => ast_util::is_local(tr.principal_def_id()), ty::ty_param(_) => true, // the user cannot implement traits for unboxed closures, so // there's no point suggesting anything at all, local or not. ty::ty_closure(..) => return Some(false), // everything else (primitive types etc.) is effectively // non-local (there are "edge" cases, e.g. (LocalType,), but // the noise from these sort of types is usually just really // annoying, rather than any sort of help). _ => false }; if is_local { Some(true) } else { None } }).2.unwrap_or(false) } </ins> #[derive(Copy)] pub struct TraitInfo { pub def_id: ast::DefId,

Discussion:
E.g. (The repetition is .) However, all of these are useless: because one cannot implement them for anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external. cc
Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for if another type parameter were local, though not with the current orphan rules. Nonetheless, it might be good to just screen them out anyway, as it is unlikely to be what you plan to do.
Change:
<ins> error: concrete type differs from previous defining opaque type use --> $DIR/recursive-tait-conflicting-defn.rs:30:3 | LL |   Some(B { inner }) |   ^^^^^^^^^^^^^^^^^ expected `A`, got `B<TestImpl>` | note: previous use here --> $DIR/recursive-tait-conflicting-defn.rs:20:3 | LL |   A |   ^ error: aborting due to previous error </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. --I tried this code: I expected to see this happen: compile error that said the return type is wrong. Instead, this happened: compiled without 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. --:
cc

edit: minimized see for more details <!-- 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: Compilation should fail, because different generator types should be generated by calling , meaning and should not share the same type . Instead, compilation passes, and occurs during runtime: More context: <!-- 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<summaryNo Backtrace from running it</summary<p</p</details
label +F-typealiasimpl_trait +I-unsound +T-compiler
Only possible with unstable feature label -I-prioritize
it would be good to have an example which does not depend on external crates or macros here.
slightly minimized completely minimized: + incorrectly ignoring recursive definitions, writing a clean MVCE rn
constrains to , which gets ignored because of I am not totally sure how this all interacts, would have to look at the code, but it feels like the same root cause as
Change:
/// Flags for formatting #[stable(feature = "rust1", since = "1.0.0")] <ins> #[rustc_deprecated(since = "1.24.0", reason = "use the `sign_plus`, `sign_minus`, `alternate`,  or `sign_aware_zero_pad` methods instead")] </ins> pub fn flags(&self) -> u32 { self.flags } /// Character used as 'fill' whenever there is alignment

Discussion:
This method is public, but its documentation doesn’t say anything about the meaning of the return value. The bit indices to interpret it are given by the numerical value of variants of the enum. But that enum is private, and all of that information is exposed in other public methods (, , , ) so it looks like the details of that encoding are intended to be private. It looks like there is no way of using that method without making assumptions about private implementation details that we might want to change. Should we document it as such and deprecate it? CC
Yeah I think we'll want to deprecate it.
Change:
Ok(TyKind::BareFn(P(BareFnTy { ext, unsafety, generic_params: params, decl, decl_span }))) } <ins> /// Recover from function pointer types with a generic parameter list (e.g. `fn<'a>(&'a str)`). fn recover_fn_ptr_with_generics( &mut self, lo: Span, params: &mut Vec<GenericParam>, param_insertion_point: Option<Span>, ) -> PResult<'a, ()> { let generics = self.parse_generics()?; let arity = generics.params.len(); let mut lifetimes: Vec<_> = generics .params .into_iter() .filter(|param| matches!(param.kind, ast::GenericParamKind::Lifetime)) .collect(); let sugg = if !lifetimes.is_empty() { let snippet = lifetimes.iter().map(|param| param.ident.as_str()).intersperse(", ").collect(); let (left, snippet) = if let Some(span) = param_insertion_point { (span, if params.is_empty() { snippet } else { format!(", {snippet}") }) } else { (lo.shrink_to_lo(), format!("for<{snippet}> ")) }; Some(FnPtrWithGenericsSugg { left, snippet, right: generics.span, arity, for_param_list_exists: param_insertion_point.is_some(), }) } else { None }; self.sess.emit_err(FnPtrWithGenerics { span: generics.span, sugg }); params.append(&mut lifetimes); Ok(()) } </ins> /// Emit an error for the given bad function pointer qualifier. fn error_fn_ptr_bad_qualifier(&self, span: Span, qual_span: Span, qual: &str) { self.struct_span_err(span, &format!("an `fn` pointer type cannot be `{}`", qual))

Discussion:
Newcomers might attempt to write a “generic” function pointer like . In such case, the compiler should provide a better error message. Inspired by a recent Reddit thread I sadly cannot find anymore. Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters, suggest to move the lifetime(s) to a parameter list (this should be machine-applicable in my judgement) and be able to recover: For later reference, the current output is: Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters and be able to recover emitting two diagnostics, one for each line. The compiler could also suggest moving the generic parameter list further up to the owning function, struct, etc. if available. Note that this might not be what the user intended (since there is a semantic difference between hypothetical higher-ranked generics and normal ones) and therefore shouldn't be machine-applicable. For later reference, the current output is: label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim