jiebi/CodeConvo huggingface dataset:
Change:
.TP fBRUST_TEST_THREADSfR The test framework Rust provides executes tests in parallel. This variable sets <del> the maximum number of threads used for this purpose. </del> <ins> the maximum number of threads used for this purpose. This setting is overridden by the --test-threads option. </ins> .TP fBRUST_TEST_NOCAPTUREfR

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:
// Regression test for issue #98833. <del> // compile-flags: -Zinline-mir </del> <ins> // compile-flags: -Zinline-mir -Cdebug-assertions=off </ins> fn main() { println!("{}", live::<false>()); <ins> let f = |x: bool| { debug_assert!( x ); }; f(false); </ins> } #[inline]

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
return; } <del> let attrs = merge_attrs(cx, parent_module.into(), load_attrs(cx, did), attrs); debug!("merged_attrs={:?}", attrs); </del> let tcx = cx.tcx; let associated_trait = tcx.impl_trait_ref(did);

Discussion:
I tried this code: I expected to see this happen: both impls being highlighted as needing the feature. Instead, this happened: only the impl got the message: ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +T-rustdoc
claim
Change:
let lines = lines.lines.as_slice(); if lines.len() > MAX_LINES { <del> try!(write!(&mut w.dst, "{}:{} {}n", fm.name, lines[0] + 1, fm.get_line(lines[0] as int))); </del> <ins> if let Some(line) = fm.get_line(lines[0]) { try!(write!(&mut w.dst, "{}:{} {}n", fm.name, lines[0] + 1, line)); } </ins> try!(write!(&mut w.dst, "...n")); <del> let last_line = lines[lines.len()-1]; try!(write!(&mut w.dst, "{}:{} {}n", fm.name, last_line + 1, fm.get_line(last_line as int))); } else { for line in lines.iter() { </del> <ins> let last_line_number = lines[lines.len() - 1]; if let Some(last_line) = fm.get_line(last_line_number) { </ins> try!(write!(&mut w.dst, "{}:{} {}n", fm.name, <del> *line + 1, fm.get_line(*line as int))); </del> <ins> last_line_number + 1, last_line)); } } else { for &line_number in lines.iter() { if let Some(line) = fm.get_line(line_number) { try!(write!(&mut w.dst, "{}:{} {}n", fm.name, line_number + 1, line)); } </ins> } } let last_line_start = format!("{}:{} ", fm.name, lines[lines.len()-1]+1);

Discussion:
When trying to build with I'm getting
Is there a temporary workaround? Thanks!
Most likely change the occurrences of (or ) to . Like .
I just tripped over this ICE in serde. I love c-reduce. It came up with the following code that reproduces the bug by reducing 203K down to this in 15 minutes: Here's the error:
Change:
UnconditionalRecursion, InvalidNoMangleItems, PluginAsLibrary, <ins> DropWithReprExtern, </ins> ); add_builtin_with_new!(sess,

Discussion:
(imported from improperly closed bug ) As suggested by Until is done, we really should lint for this scenario.
triage: P-low
oops. triage: P-high (but nonetheless not 1.0)
I feel like this should be stronger than a medium-priority lint. I feel like rustc should reject programs that attempt to on a struct, for as long as that changes the size of that struct. In particular, not fixing this by 1.0 would foreclose the ability to change the drop flag after 1.0, since that would change the size / ABI of structs, right? Or is ABI stability not a guarantee of ?
Yeah this label got auto renamed. I'm up'ing the priority
triage: P-high I'll assign to self too
( I'm pretty confident we could fix this post 1.0, e.g. adding new warnings is allowed, and the representation issue would be "just a bug to be fixed." Nonetheless I I do I do want I do want to fix.)
Change:
name = name, generics = f.generics.print(cx), where_clause = print_where_clause(&f.generics, cx, 0, Ending::Newline), <del> decl = f.decl.full_print(header_len, 0, header.asyncness, cx), </del> <ins> decl = f.decl.full_print(header_len, 0, cx), </ins> notable_traits = notable_traits_decl(&f.decl, cx), ); });

Discussion:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.
Change:
use rustc_span::{sym, BytePos, Span, DUMMY_SP}; use rustc_target::spec::abi; use rustc_trait_selection::traits::wf::object_region_bounds; <del> use rustc_trait_selection::traits::{self, NormalizeExt, ObligationCtxt}; use rustc_type_ir::fold::{TypeFoldable, TypeFolder, TypeSuperFoldable}; </del> <ins> use rustc_trait_selection::traits::{self, ObligationCtxt}; </ins> use std::fmt::Display; use std::slice;

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 --
Ow, my bad! claim
Change:
<ins> // aux-build:generics_of_parent.rs // check-pass #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] extern crate generics_of_parent; use generics_of_parent::{Foo, S}; fn main() { // regression test for #87603 const N: usize = 2; let x: S<u8, N> = S::test(); } // regression test for #87674 fn new<U>(a: U) -> U { a } fn foo<const N: usize>(bar: &mut Foo<N>) where [(); N + 1]: , { *bar = new(loop {}); } </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. --I tried simplifying my code, but the code is quite complex and I wasn't able to recreate the ICE. Here is the repo which you can try building to see it for yourself: The main source of the issue is my Tensor structs which look similar to the below code. I have had issues with this . The ICE started happening after I convolution with fft. I to simplify writing the types. Maybe it's related? Sorry for the code mess; I didn't plan to show this code to other people. <!-- 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
Please add A-const-generics, F-constevaluatablechecked, and F-const_generics labels
Maybe related to , but I had this ICE already all the way back in 04/06/2021. Back then the error was
Smaller repro of ICE:
confirming potentially predates 1.56 nightly
Change:
fn div(self, rhs: RHS) -> Self::Output; } <del> macro_rules! div_impl { </del> <ins> macro_rules! div_impl_integer { </ins> ($($t:ty)*) => ($( <ins> /// This operation rounds towards zero, truncating any /// fractional part of the exact result. </ins> #[stable(feature = "rust1", since = "1.0.0")] impl Div for $t { type Output = $t;

Discussion:
Using Google I can find lots of old arguments over how integer division should work in Rust, but I cannot find anything in the reference, the API docs for the integer types, or the API docs for the trait that says what was actually decided. (And the documentation seems to imply that , , and may not all do the same thing.) This is further confused by the integer type documentation apparently sometimes using to refer to integer division and sometimes to mathematical division. (I can't come up with out any other reasonable interpretation of in the documentation.) It would be nice if this were clearly documented somewhere, since this varies between languages and is one of the main confusions with integer arithmetic.
talks about 'overflow' and mentions wrapping, but you're right that we can surface this better.
This is about rounding, not wrapping. We use LLVM's , which rounds towards zero (and has the same sign as the dividend). We should document this (the documentation for currently lies_, claiming that it rounds towards negative infinite).
This should also leave a warning, because integer / integer is not always desired and happens by accident. Just a thought if anyone is reading this.
Change:
miri = "Broken" # ping @Manishearth @llogiq @mcarton @oli-obk <del> clippy = "Broken" </del> <ins> clippy = "Testing" </ins> # ping @nrc rls = "Testing"

Discussion:
branch: master Compiling cargometadata v0.2.3 Compiling clippylints v0.0.166 (file:///home/ryan/git/rust/src/tools/clippy/clippylints) error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: :vis fragment specifier is experimental and subject to change (see issue ) --<declarelint macros:1:3 | 1 | ( NAME : ident , desc : expr ) =( | ^^^^^^^^^^^ | = help: add #![feature(macrovismatcher)] to the crate attributes to enable error: aborting due to previous error error: aborting due to previous error error: Could not compile . warning: build failed, waiting for other jobs to finish... error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed This failure is expected (see ) Build completed successfully in 1:46:49
Everything is actually fine, as you can see by the last two lines of the log. I hope to remove the error log if the failure is expected in the future, but not sure yet how best to do that.
Is it related to rust-lang-nursery/rust-clippy?
Change:
use core::cell::Cell; use core::cmp::Ordering; <ins> use core::mem::MaybeUninit; </ins> use core::result::Result::{Err, Ok}; #[test]

Discussion:
This was reported by on Zulip: https://rust- Demo:
I think the fix should be as simple as using instead of as the type of - that will work regardless of whether or not the memory is initialized.
The other option is just removing the case entirely. Llvm is smart enough to turn that loop in the branch into a memset.
It does help the gcc codgen backend at least as it can't manage to produce a memset for u64 so I assume it would fail to do the same for u8 if it weren't for that specialization.
It also fails for the case:
It does call memset if you don't pass an array.
I'd think the intrinsic could easily have its type changed to take a , which would let one solve this problem. The stable function of course cannot be changed, though...
Reopening to track adding a test. (That's the standard procedure for this, isn't it?)
I would like to try working on adding the test, though this will be my first contribution so I'd need some guidance. I'm assuming this would be a miri test as it's related to correctness--may I DM you on Zulip? (or would someone else be more suitable?)
great. :) Miri runs the libcore test suite via So adding it as a test in libcore makes most sense, IMO.
Change:
<ins> // run-rustfix // Check that we try to correct `=>` to `>=` in conditions. #![allow(unused)] fn main() { let a = 0; let b = 1; if a >= b {} //~ERROR } fn foo() { let a = 0; if a >= 1 {} //~ERROR } fn a() { let a = 0; if 1 >= a {} //~ERROR } fn bar() { let a = 0; let b = 1; if a >= b && a != b {} //~ERROR } fn qux() { let a = 0; let b = 1; if a != b && a >= b {} //~ERROR } fn baz() { let a = 0; let b = 1; let _ = a >= b; //~ERROR } fn b() { let a = 0; let b = 1; match a >= b { //~ERROR _ => todo!(), } } </ins>

Discussion:
When encountering code like , we currently emit But it should be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi! I'd like to try working on this issue if nobody else is currently. claim
Change:
} } <ins> #[stable(feature = "chars_debug_impl", since = "1.38.0")] impl fmt::Debug for Chars<'_> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { write!(f, "Chars(")?; f.debug_list().entries(self.clone()).finish()?; write!(f, ")")?; Ok(()) } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<'a> DoubleEndedIterator for Chars<'a> { #[inline]

Discussion:
Currently, the Debug of prints the underlying bytes, rather than the chars: Returns: As I was trying to work out what was (whether it was unicode points or bytes or something else), the first output was v confusing - is there a reason we don't print something like the second case? Would you take a PR to change this? I couldn't find any previous discussion on this - was the closest I could find.
The first one is UTF-8 bytes. You see this because the impl for is auto-generated: Strictly speaking, since the bytes inside of should always be valid UTF-8, this could have a custom impl that makes it pretend to contain a string by formatting the member as . The reason it doesn't display as individual chars is because it doesn't have individual ; determining their boundaries is the entire point of the iterator. I suppose this same argument could be used against the call to , which needs to scan the whole string to validate it. (but then the solution seems to be to use , which seems awfully heavy-handed for a impl. And perhaps it doesn't even matter, because the cost of most impls probably outweighs the cost of this validation) I guess that, questionable concerns of efficiency aside, my main concern is simply that showing a list of individual chars would be... dishonest, I guess.
Do & contain more data than ? I had thought they both contained the underlying bytes and then these were decoded as needed - including as part of the & implementations
No, they contain the same data. They're all just UTF-8 bytes. And the implementation of simply writes the bytes contained in the directly to the instance. Suppose we are writing to STDOUT. On UNIX, the impl writes these bytes directly to the underlying file descriptor with no processing: I would imagine this is because the console on any UNIX platform almost certainly uses UTF-8.[^1] It is your terminal application that is then responsible for decoding these bytes and producing glyphs. Considering that UTF-8 dominates much of the web space as well, it's quite possible that even on the playground, these bytes are ultimately sent over the wire to your PC with minimal processing, where your browser is responsible for decoding and displaying them. On Windows, transcodes the UTF-8 into the UTF-16 format expected by the windows APIs: and then Windows does whatever it does with those UTF-16 code units.

(Quite likely, it hands them directly to the console, which is then responsible for decoding and displaying them) [^1]: (I think in actuality UNIX accepts arbitrary strings of bytes, and then the portions of these strings which are valid UTF-8 are rendered appropriately by the console. I don't know; doesn't really matter)
OK, so given that - is there still an objection to displaying the unicode characters for but not ?
Change:
#[rustc_const_unstable(feature = "const_ascii_ctype_on_intrinsics", issue = "68983")] #[inline] pub const fn is_ascii_whitespace(&self) -> bool { <del> self.is_ascii() && (*self as u8).is_ascii_whitespace() </del> <ins> match *self { 't' | 'n' | 'x0C' | 'r' | ' ' => true, _ => false, } </ins> } /// Checks if the value is an ASCII control 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:
#[test] fn smoke() { <ins> #[derive(Clone)] </ins> struct TypeWithDrop; impl Drop for TypeWithDrop { fn drop(&mut self) {

Discussion:
With on , will not drop the inside , just like does not drop the original before overwriting it. However, a manual implementation of can only make use of the efficiency of a overriden on (e.g. memory reuse by a ) by simply forwarding to it, which means that will not forget the old value. This new (forwarding, so (potentially) dropping) behaviour was in , and (for now) reverted in So question for What behaviour would be correct? There are arguments for both. Whatever the decision, we should document it and add a test for it.
I feel that the old behavior is correct (not calling drop). should behave like which for means not dropping the old value. I don't think there is much loss of efficiency in practice: use of is already pretty rare and I don't think there are any cases of it being used with .
Sounds good. Closing this.
No wait, we still need to do this part. :)
Change:
//! Otherwise it drops all the values in scope at the last suspension point. use crate::abort_unwinding_calls; <del> use crate::add_call_guards; </del> use crate::deref_separator::deref_finder; use crate::errors; use crate::pass_manager as pm;

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. -- <p<details</p</details<!-- 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</detailsBuild with
can reproduce
can you include a and (for example as a link to a project (+commit), or right here), to be able to reproduce this in the future?
Sorry, forgot to add those, I've attached them
does needs MCVE mean an example not relying on tokio?
yes
Ran a bisect. searched nightlies: from to regressed nightly: searched commit range: ... regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Spent some unforgettable time chopping down 80k lines of tokio code piece by piece, but it was worth it, I hope. Here's an MCVE: : :
Since this seems to be somehow caused by mir drop tracking, cc
WG-prioritization assigning priority (). label -I-prioritize +P-high