jiebi/CodeConvo huggingface dataset:
Change:
self.maybe_recover_from_bad_qpath(expr, true) } <del> fn parse_array_or_repeat_expr(&mut self, attrs: AttrVec) -> PResult<'a, P<Expr>> { </del> <ins> fn parse_array_or_repeat_expr( &mut self, attrs: AttrVec, close_delim: token::DelimToken, ) -> PResult<'a, P<Expr>> { </ins> let lo = self.token.span; <del> self.bump(); // `[` </del> <ins> self.bump(); // `[` or other open delim </ins> <del> let close = &token::CloseDelim(token::Bracket); </del> <ins> let close = &token::CloseDelim(close_delim); </ins> let kind = if self.eat(close) { // Empty vector ExprKind::Array(Vec::new())

Discussion:
I ended up spending way too much time debugging the following error, since I was trying to port some C code to rust. Give the error: The error message is very vague and hard to determine the actual error here. Seeing as though some programming languages like Java and C use for arrays, I think it'd make sense for the compiler to suggest using if the user is trying to create an array. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I suppose adding manual diagnostic somewhere around will get the job done. claim
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. pub struct Outer<T: Trait>(T); pub struct Inner<'a> { value: &'a bool } pub trait Trait { type Error; fn ready(self) -> Self::Error; } impl<'a> Trait for Inner<'a> { type Error = Outer<Inner<'a>>; fn ready(self) -> Outer<Inner<'a>> { Outer(self) } } fn main() { let value = true; let inner = Inner { value: &value }; assert_eq!(inner.ready().0.value, &value); } </ins>

Discussion:
Repeating segment:
Note: the type is regular, just not representable (actual non-regular data types make selection overflow, possibly at trans time).
This particular case could be handled in type-checking, but the general case requires some sort of recursion check after the type has been monomorphized.

causes a stack overflow.
This is a stack overflow inside middle::traits::project::normalizeprojectiontype

I've encountered a variant of this bug (or is it another bug? please advise if so and I will post it separately): If I remove the lifetime, the stack overflow no longer occurs.
Seems to be a dupe of
example was fixed in 1.4.

The following program generates a trans-time stack overflow.
Can confirm this is still an issue
This is somewhat distinct from , as it creates an irregular type without selection errors.
actually, not really.

On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.
Change:
use crate::io::prelude::*; <del> use crate::io::{copy, empty, repeat, sink, Empty, Repeat, Sink}; </del> <ins> use crate::io::{copy, empty, repeat, sink, Empty, Repeat, SeekFrom, Sink}; </ins> #[test] fn copy_copies() {

Discussion:
You can create an empty io-reader with , which returns an . That doesn't implement the trait. However, I don't see any reason why it shouldn't.
I don't understand how a reader which is always at EOF should be seekable. Can you please explain more about it?
You can think of a reader which is always at EOF as a reader which is always at position 0 with a stream end of position 0. I don't think there is any disadvantage of having implemented for . It allows it to be passed to more generic code.
Did you hit a case where you actually wanted to do this?
In is discussing ways to implement a 307/308 HTTP redirect. Those two codes (in contrast to 301/302/303) require the payload to be sent after the redirect. However, parts of the payload may already have been sent to the server, before the server responds with the redirect. With a generic API taking an as Payload, it's not possible to seek back to the beginning. Thus, one suggestion is to use instead. To allow an empty body (e.g. for a GET request), it would be nice to keep using . While will probably decide to follow a different way for those redirects, I still think this pattern makes sense to support.
Change:
<del> // Copyright 2016 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. // compile-flags:-Zdump-mir=NEVER_MATCHED // Regression test for #41697. Using dump-mir was triggering // artificial cycles: during type-checking, we had to get the MIR for // the constant expressions in `[u8; 2]`, which in turn would trigger // an attempt to get the item-path, which in turn would request the // types of the impl, which would trigger a cycle. We supressed this // cycle now by forcing mir-dump to avoid asking for types of an impl. #![feature(rustc_attrs)] use std::sync::Arc; trait Foo { fn get(&self) -> [u8; 2]; } impl Foo for [u8; 2] { fn get(&self) -> [u8; 2] { *self } } struct Bar<T: ?Sized>(T); fn unsize_fat_ptr<'a>(x: &'a Bar<Foo + Send + 'a>) -> &'a Bar<Foo + 'a> { x } fn unsize_nested_fat_ptr(x: Arc<Foo + Send>) -> Arc<Foo> { x } fn main() { let x: Box<Bar<Foo + Send>> = Box::new(Bar([1,2])); assert_eq!(unsize_fat_ptr(&*x).0.get(), [1, 2]); let x: Arc<Foo + Send> = Arc::new([3, 4]); assert_eq!(unsize_nested_fat_ptr(x).get(), [3, 4]); } </del>

Discussion:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is
Change:
<ins> error: invalid tuple or struct index --> $DIR/issue-47073-zero-padded-tuple-struct-indices.rs:18:30 | 18 |     let _condemned = justice.00; |                              ^^ help: try simplifying the index: `0` error: invalid tuple or struct index --> $DIR/issue-47073-zero-padded-tuple-struct-indices.rs:20:31 | 20 |     let _punishment = justice.001; |                               ^^^ help: try simplifying the index: `1` error: aborting due to 2 previous errors </ins>

Discussion:
The following compiles, but I think it shouldn't?
The field name is converted to a number too eagerly. This doesn't happen in struct expressions and patterns.
Change:
let mut expected_arg_tys = expected_arg_tys; let expected_arg_count = fn_inputs.len(); <ins> let sp_args = if args.len() > 0 { let (first, args) = args.split_at(1); let mut sp_tmp = first[0].span; for arg in args { let sp_opt = self.sess().codemap().merge_spans(sp_tmp, arg.span); if ! sp_opt.is_some() { break; } sp_tmp = sp_opt.unwrap(); }; sp_tmp } else { sp }; </ins> fn parameter_count_error<'tcx>(sess: &Session, sp: Span, fn_inputs: &[Ty<'tcx>], expected_count: usize, arg_count: usize, error_code: &str, variadic: bool) {

Discussion:
From: src/test/compile- Error E0057 needs a span_label, updating it from: To: Bonus 1: The note seems excessive. Check other E0057 errors. If it is not needed, remove the note. Bonus 2: The span for the error could likely focus on the parameters rather than the whole call.
I'm taking this one.
I think I've got most of this fix/working, but I'm having a problem fixing one of the unit test cases - issue- The other related test cases (issue-, issue-4935, method-call-err-msg, not-enough-arguments, overloaded-calls-bad and variadic-ffi-3) I was able to fix by following your blog guide. For some reason, issue-3044 is 'different' and I don't understand why. Not sure how to proceed...
- can you show the errors you get when you try to get issue-3044 to pass?
I think I fixed the problem. I'm now trying to get my code checked in and pushed to by fork. Having some ssh key/cert issues. I think once I do that, I can do a PR?
I just submitted a PR, but not sure if I did it correctly.
The note of and this one are printed by the same function, can I modify it to print the expected types directly in the label? I also did the bonus2 part for both E0060 and E0061.
Freeing this one up as part of the final push for .
Actually, according to the comments in maybe this is already closed? , can you confirm?
I think should be closed, and progress is under way in .
Change:
} #[instrument(skip(self), level = "trace")] <del> pub fn opaque_ty_origin_unchecked(&self, def_id: LocalDefId, span: Span) -> OpaqueTyOrigin { </del> <ins> fn opaque_ty_origin_unchecked(&self, def_id: LocalDefId, span: Span) -> OpaqueTyOrigin { </ins> let origin = match self.tcx.hir().expect_item(def_id).kind { hir::ItemKind::OpaqueTy(hir::OpaqueTy { origin, .. }) => origin, ref itemkind => {

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
} fn make_run(run: RunConfig<'_>) { <del> run.builder.ensure(Std { stage: run.builder.top_stage, target: run.target }); </del> <ins> run.builder.ensure(Std { stage: run.builder.top_stage, target: run.target, format: if run.builder.config.cmd.json() { DocumentationFormat::JSON } else { DocumentationFormat::HTML }, }); </ins> } /// Compile all standard library documentation.

Discussion:
running only builds the html doc, but builds the json doc. I expected the json flag to act as the documentation says (): using the master branch of this repo commit running with a library profile.
I can't reproduce this. The files show up for me in .
Seems to reproduce, I could totally have overlooked a step tho
oh no it's even simpler than that lol it's calling the wrong function that should be JsonStd, not Std
Should I make the PR or are you gonna do it ?
If you could make a PR that would be great :)
Made the PR but since just changing the ensure wasn't enough there's a thing I'm unsure about (tested it, worked, but could be cleaner)
Change:
deadline: u64, } <del> unsafe impl Send for UnixAcceptor {} unsafe impl Sync for UnixAcceptor {} </del> struct AcceptorState { abort: Event, closed: AtomicBool, } <del> unsafe impl Send for AcceptorState {} unsafe impl Sync for AcceptorState {} </del> impl UnixAcceptor { pub fn accept(&mut self) -> IoResult<UnixStream> { // This function has some funky implementation details when working with

Discussion:
There are quite few os-specific types definitions whose traits implementations are not consistent. With the work happening in OIBIT, I've tried to keep the implementations of built-in traits consistent for both and . Unfortunately, the test suite for these implementations is not unified, therefore there's a high chance that some types for 's implementation may have some traits implemented, whereas the 's implementation doesn't. In theory, we can assume that common types for these implementations should implement the same built-in types, therefore there should be tests that enforce this guarantee in a common place. Some examples may be found in This bug is to track the work there which impacts the of our standard library.
I can mentor on this bug, tagging with
seems interesting. Can i take this bug? :)
it's all yours, lemme know if you need help/reviews
This should be closed now right?
correct. Thanks!
Change:
} _ => { self.tcx.sess.emit_err(YieldExprOutsideOfGenerator { span: expr.span }); <ins> // Avoid expressions without types during writeback (#78653). self.check_expr(value); </ins> self.tcx.mk_unit() } }

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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Assigning and removing .
This ICEs since modify labels: +regression-from-stable-to-stable
Change:
let tail = self.tail; let head = self.head; <del> unsafe { &mut self.buffer_as_mut_slice()[tail..head] } </del> <ins> unsafe { RingSlices::ring_slices(self.buffer_as_mut_slice(), head, tail).0 } </ins> } /// Rotates the double-ended queue `mid` places to the left.

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. --This is my first bug report, so please correct me s if I miss anything :-) I use VecDeque<u8in a toy application () which is handling external reads in a loop, and does possible partial handling of the input. My pattern is I call reserve(N) before pushback() N times, then makecontiguous(), then doing some popfront(). I noticed the app was behaving badly, and was able to generate a stand-alone test case which shows the bug. The code is pretty boring and repetitive, so I put it at to avoid spamming here. Just issue "cargo run" after cloning out that code, and look for the word "BUG" within the terminal output: According to the docs, popfront() on an empty VecDeque should return None. Instead, this happens: If I set the boolean "doreserve" to be false, thus getting rid of all the reserve() calls, I get the expected behavior: The same happens if I set "domake_contiguous" to false as well - so calling both functions is a prerequisite to trigger the bug. The same thing happens in debug and release builds. <!-- 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 below is the version I found it in, but thanks a lot to Steve Klabnik for also testing it on nightly and getting the same buggy behavior. :
I created a minimal sample:
Hmm, if it double-frees then why does Miri not catch it?
Assigning and removing as in the prioritization working group.
Some time ago I've read somewhere that Rust stdlib VecDeque is cursed. I didn't believe them. I'm changing opinion... -.-
This specific case doesn't double free (i32::drop is a noop), using a might have been a better example...
Still, this is memory-unsafe, right?
Yes, It's still a use-after-free regardless
claim
Based on my conversation with lcnr, jonas-schievink, and others , it seems that using with copy types is not UB (it still exhibits a bug though!) because copy types aren't freed. It is UB with non-copy types though (e.g. ).
Change:
layout::Variants::Single { index } => { if let Some(discr) = src.layout.ty.discriminant_for_variant(*self.tcx, index) { assert!(src.layout.is_zst()); <del> return Ok(Scalar::from_uint(discr.val, dest_layout.size).into()); </del> <ins> let discr_layout = self.layout_of(discr.ty)?; return Ok(self .cast_from_int_like(discr.val, discr_layout, dest_layout)? .into()); </ins> } } layout::Variants::Multiple { .. } => {}

Discussion:
Compiling this code on : results in ICE. Casting to anything smaller than /(, , , , , etc) also results in ICE. Casting to anything same size or larger(, , , , etc) works fine. Positive discriminant values also work fine. Version of rustc: (on rust playground) Compiler flags listed as used:
indicates that this was injected in Rust 1.40
Thanks for the report! Please always include the ICE message. This time, it seems to be
Change:
<ins> // Regression test for #59311. The test is taken from // rust-lang/rust/issues/71546#issuecomment-620638437 // as they seem to have the same cause. // FIXME: It's not clear that this code ought to report // an error, but the regression test is here to ensure // that it does not ICE. See discussion on #74889 for details. pub trait T { fn t<F: Fn()>(&self, _: F) {} } pub fn crash<V>(v: &V) where for<'a> &'a V: T + 'static, { v.t(|| {}); //~ ERROR: higher-ranked subtype error } fn main() {} </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:
/// /// let builder = thread::Builder::new().stack_size(32 * 1024); /// ``` <ins> /// /// [stack-size]: ./index.html#stack-size </ins> #[stable(feature = "rust1", since = "1.0.0")] pub fn stack_size(mut self, size: usize) -> Builder { self.stack_size = Some(size);

Discussion:
One can specify the stack size of a thread via . It looks like looks at the env var and attempts to parse it into an integer. If it's not specified or can't parse, it falls back to 2MB. Should we update the thread documentation to mention what the default stack size is and mention that environment variable?
Relevant discussion on IRC
Don't forget that the stack size of the main thread is not determined by Rust.
Opened a PR:
Change:
use adt; use common::*; use machine; <del> use rustc::traits::Reveal; </del> use rustc::ty::{self, Ty, TypeFoldable}; use type_::Type;

Discussion:
On stable, beta, and nightly, the follow code prints followed by : CC
This is probably for drop flags, in which case it should get fixed by
Reduced:
where would there be a drop flag here?
My point isn't that there is, but that the code assumes all trait objects have drop flags. I could be wrong though, it might be a bug in the alignment logic.
Not fixed by , will have to investigate further.
Uhhhh, the computation starts with: Which is completely wrong, because you want no trailing padding, i.e. should be . EDIT: getting a field pointer might also be broken, needs looking into. EDIT2: to handle the "minimum size" needed to compute the field offset, so that works.
Change:
/// # Examples /// /// ``` <del> /// #![feature(string_drain_as_str)] </del> /// let mut s = String::from("abc"); /// let mut drain = s.drain(..); /// assert_eq!(drain.as_str(), "abc"); /// let _ = drain.next().unwrap(); /// assert_eq!(drain.as_str(), "bc"); /// ``` <del> #[unstable(feature = "string_drain_as_str", issue = "76905")] // Note: uncomment AsRef impls below when stabilizing. </del> <ins> #[stable(feature = "string_drain_as_str", since = "1.55.0")] </ins> pub fn as_str(&self) -> &str { self.iter.as_str() } } <del> // Uncomment when stabilizing `string_drain_as_str`. // #[unstable(feature = "string_drain_as_str", issue = "76905")] // impl<'a> AsRef<str> for Drain<'a> { //     fn as_ref(&self) -> &str { //         self.as_str() //     } // } // // #[unstable(feature = "string_drain_as_str", issue = "76905")] // impl<'a> AsRef<[u8]> for Drain<'a> { //     fn as_ref(&self) -> &[u8] { //         self.as_str().as_bytes() //     } // } </del> <ins> #[stable(feature = "string_drain_as_str", since = "1.55.0")] impl<'a> AsRef<str> for Drain<'a> { fn as_ref(&self) -> &str { self.as_str() } } #[stable(feature = "string_drain_as_str", since = "1.55.0")] impl<'a> AsRef<[u8]> for Drain<'a> { fn as_ref(&self) -> &[u8] { self.as_str().as_bytes() } } </ins> #[stable(feature = "drain", since = "1.6.0")] impl Iterator for Drain<'_> {

Discussion:
Tracking Issue for as introduced by Api: - The first one is now gated behind . The other two are not available yet, as trait implementations cannot be unstable. These should be (uncommented) when this feature is stabilized.
Seems there's no blocker, could I ask you to kick off FCP to stabilize it?
cc If it's reasonable, it'd be great if someone starts FCP :)
Do we have any confirmation of usage in the ecosystem? I don't see any problem with the method as designed, but can we confirm that it's being used?
Oh sorry, I don't have the real world use case, unfortunately. I just thought this is straightforward and makes the conversion around easier. And we cannot make any use that requires because it's hidden until we stabilize the feature.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.