jiebi/CodeConvo huggingface dataset:
Change:
#[inline] fn is_contiguous(&self) -> bool { <ins> // FIXME: Should we consider `head == 0` to mean // that `self` is contiguous? </ins> self.tail <= self.head }

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:
<ins> error[E0491]: in type `&'b &'a ()`, reference has a longer lifetime than the data it references --> $DIR/underconstrained_lifetime.rs:15:26 | LL | type Converter<'a, 'b> = impl ProofForConversion<'a, 'b>; |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: the pointer is valid for the lifetime `'b` as defined here --> $DIR/underconstrained_lifetime.rs:15:20 | LL | type Converter<'a, 'b> = impl ProofForConversion<'a, 'b>; |                    ^^ note: but the referenced data is only valid for the lifetime `'a` as defined here --> $DIR/underconstrained_lifetime.rs:15:16 | LL | type Converter<'a, 'b> = impl ProofForConversion<'a, 'b>; |                ^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0491`. </ins>

Discussion:
() I would’ve expected rustc to complain about the not matching the with a suggestion to turn it into . modify labels: A-typesystem, A-lifetimes, A-traits, A-impl-trait, F-typealiasimpl_trait, T-compiler, requires-nightly and someone please add “I-unsound ” (and/or tell me if there is a way to do it myself).
One thing that is of note here is that we properly enforce type bounds, but not lifetime bounds, as the equivalent program with types fails to compile right where we expect that:
Aha! If we change to have an explicit bound, then we get the right error: so we're just missing a check of the implied bounds on the impl
Change:
hir::ExprRepeat(ref v, ref c) => ExprKind::Repeat { value: v.to_ref(), <del> count: Expr { </del> <ins> count: TypedConstVal { </ins> ty: cx.tcx.expr_ty(c), <del> temp_lifetime: None, </del> span: c.span, <del> kind: ExprKind::Literal { literal: cx.const_eval_literal(c) } }.to_ref() </del> <ins> value: const_eval::eval_const_expr(cx.tcx, c) } </ins> }, hir::ExprRet(ref v) => ExprKind::Return { value: v.to_ref() },

Discussion:
See and relevant FIXME in
As a side-note, would solve this problem quite neatly, if we were to adopt and implement it. :)
Change:
= note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <ins> = help: use an inclusive range pattern, like N..=M </ins> error[E0658]: exclusive range pattern syntax is experimental --> $DIR/range_pat_interactions3.rs:18:17

Discussion:
Came across this when a beginner was very confused about what was wrong with their ; the words "is experimental" and the link to the issue was not sufficient for their discovering what the problem/solution was. The suggested inclusive range pattern doesn't need to contain the actual matching value if producing it is hard or impossible, printing something like is still better than nothing. This issue may of course be ignored/closed if this nightly feature is just about ready to be stabilized or something. No response label +D-terse +C-enhancement +F-exclusiverangepattern <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
// lldb-command:print *owned // lldb-check:[...]$4 = 6 <ins> // lldb-command:continue // lldb-command:print variable // lldb-check:[...]$5 = 2 // lldb-command:print constant // lldb-check:[...]$6 = 2 // lldb-command:print a_struct // lldb-check:[...]$7 = Struct { a: -3, b: 4.5, c: 5 } // lldb-command:print *struct_ref // lldb-check:[...]$8 = Struct { a: -3, b: 4.5, c: 5 } // lldb-command:print *owned // lldb-check:[...]$9 = 6 #![feature(unboxed_closures)] </ins> #![allow(unused_variables)] struct Struct {

Discussion:
So, this code raises an assertion in llvm when compiling with -g. Without -g it works fine. Raised assertion is Edit: reduced code more
Duplicate of ? (there are some comments with unboxed closures and /)
It worked with the rustc versions from around last week. Especially the rustup versions. A friend just tested it with his "old" version from 11/26, and it still works there. So either it's new or it's a regression bug.
cc
I'll look into it.
I suspect the culprit is makereturnslotpointer in librustctrans::trans::builder
Change:
.is_type_alias_impl_trait .set(def_id.index, self.tcx.is_type_alias_impl_trait(def_id)); } <ins> if let DefKind::ImplTraitPlaceholder = def_kind { self.encode_explicit_item_bounds(def_id); } </ins> if tcx.impl_method_has_trait_impl_trait_tys(def_id) && let Ok(table) = self.tcx.collect_return_position_impl_trait_in_trait_tys(def_id) {

Discussion:
I tried this code: Compiled fine with , but gives the following error with : My initial attempt at minimizing the case shown that the single-crate equivalent: compiles just fine. : EDIT: Reduced reproduction code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(This is a issue that is fixed under and ). cc a nice test case to add.
Why do you think this is a limitation of the current lowering? This should definitely work with the current lowering and ideally shouldn't be dependent on . This is just a plain bug claim
The reason: incorrect eyeballing + complete ignorance of the subject matter, AKA saying stupid things . Even better it it's fixable without requiring the new lowering.
This regressed in , cc I will fix this, but I hope that PR doesn't also regress other things, like the last time the encoding for certain items was reduced without sufficient tests :/
Change:
static_parts: &StaticParts<'_>, offset: Indent, ) -> Option<String> { <del> println!("rewriting static"); </del> let colon = colon_spaces(context.config); let mut prefix = format!( "{}{}{}{} {}{}{}",

Discussion:
Many crates that use bindgen are now failing. For example: The bindgen output looks like normal, except that it also has several lines mixed in. For example: It most recently worked on: rustc 1.81.0-nightly from about 2024-06-21 I believe the bug was introduced by commit . modify labels: +regression-from-stable-to-nightly-regression-untriaged
should fix this
Change:
} } <ins> // `pub` may be used for an item or `pub(crate)` if self.prev_token.is_ident_named(sym::public) && (self.token.can_begin_item() || self.token.kind == TokenKind::OpenDelim(Delimiter::Parenthesis)) { err.span_suggestion_short( self.prev_token.span, "write `pub` instead of `public` to make the item public", "pub", appl, ); } </ins> // Add suggestion for a missing closing angle bracket if '>' is included in expected_tokens // there are unclosed angle brackets if self.unmatched_angle_bracket_count > 0

Discussion:
When writing it will suggest and I think nothing should be suggested before it is validated. The statement to be suggested must be checked if it is true or not, if true it is suggested and if not it is not. The issue from: : The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oh dear, I didn't think of that while making the PR. A possible solution could be checking if the current token is for initializing an item? Like, struct/enum/macro, etc.
I wrote this solution, but I don't know if I can use it in rustc, it's currently building
I can't work on the problem unfortunately, whoever will assign it to him you can solve it this way The block
release-assignment
claim
Trying to add a method in token: And add a check: Any other better idea?
could be the keyword, as well. looks alright, ideally the repeated block could be prevented using a macro? I'm afraid that might slightly overengineer it, though.
Change:
<ins> warning: unexpected `cfg` condition name --> $DIR/stmt-no-ice.rs:7:11 | LL |     #[cfg(crossbeam_loom)] |           ^^^^^^^^^^^^^^ | = note: `#[warn(unexpected_cfgs)]` on by default warning: 1 warning emitted </ins>

Discussion:
ICE encountered in a , will post more details when i trace it further:
I am able to reproduce the issue with this code and : And it's combination of ("introduce" the ICE, preexisting issue) and (trigger the lint which trigger the ICE).
Further reduced to:
Change:
<ins> error[E0261]: use of undeclared lifetime name `'a` --> $DIR/bad-item-bound-within-rpitit-2.rs:6:20 | LL |     fn bar<'other: 'a>() -> impl Sized + 'a {} |                    ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn bar<'a, 'other: 'a>() -> impl Sized + 'a {} |            +++ help: consider introducing lifetime `'a` here | LL | trait Foo<'a> { |          ++++ error[E0261]: use of undeclared lifetime name `'a` --> $DIR/bad-item-bound-within-rpitit-2.rs:6:42 | LL |     fn bar<'other: 'a>() -> impl Sized + 'a {} |                                          ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn bar<'a, 'other: 'a>() -> impl Sized + 'a {} |            +++ help: consider introducing lifetime `'a` here | LL | trait Foo<'a> { |          ++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0261`. </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
This needs detailed investigation, and I'd prefer we fully understand why this is resulting in a region error over just adding an check to (or feeding the query).... This probably has to do with the fact that we have a due to the missing region .
Change:
} } } <ins> forward_ref_binop! { impl Shl, shl for Wrapping<$t>, $f, #[stable(feature = "wrapping_ref_ops", since = "1.39.0")] } </ins> #[stable(feature = "op_assign_traits", since = "1.8.0")] impl ShlAssign<$f> for Wrapping<$t> {

Discussion:
The other day I noticed that only implements and co. for , which contradicts that without the shift amount can be any type. So, I think it may be useful to create tests which use macros to shove together all the types we expect to have impls for and check that we're consistent there. What I've noticed: For every operation three extra impls are , with the combinations of single-level references on both sides, e.g. , , for . Assignment ops do the same as the above, with only one extra impl, e.g. for . , , , , exist for all int and float types with themselves , , exist for all int types and bool and allow any integer type for both the left and the right side exists for all ints and floats exists for all ints and bool should mimic all of the above, where references are of the form and not . Like, I wouldn't be surprised if rearranging some macros might add or remove impls for these and adding comprehensive tests might help make sure we covered everything. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seems like a simple but useful task, I will try to finish it.
I am reformulating the task to make sure it is clear (to myself at least) : Create tests using a set of macros to check that every numerical instances of for the following operations are implemented for every combination of numerical instances (, , ...) : with : * having the integer and float types with themselves, ¤ having the integer and bool types with themselves, having the integer and float types with themselves, and Am I correct ? How does this relate to ?(e.g. is it possible to bypass the bug and still implement the test ? I could not see from the issue if a solution had been found)
claim isn't implemented for and /. So this is probably only useful for integer types.
This doesn't actually fix the issue; it should be tested for all types, not just .
Hi ! Are you or anyone else working on adding the missed tests?
They're free for anyone to implement right now!
Nope, not right now. Feel free to take over.

It should be pretty similar to , just add the missing types (bool, fp) and operators (bit wise operators).
Thank you very much and , I'll send a PR.
unassign
claim I'll try to get a PR in by next weekend, If nothing happens past that I'm afraid I may have been too busy so [anyone] feel free to overtake :smile:
claim
Hi, are you still working on this issue
I'm sorry, I couldn't do it. Please feel free to reassign this.
No worries release-assignment
Change:
<ins> error[E0061]: this function takes 1 argument but 2 arguments were supplied --> $DIR/remove-extra-argument.rs:6:5 | LL |     l(vec![], vec![]) |     ^         ------ argument unexpected | note: function defined here --> $DIR/remove-extra-argument.rs:3:4 | LL | fn l(_a: Vec<u8>) {} |    ^ ----------- help: remove the extra argument | LL |     l(vec![]) | error: aborting due to previous error For more information about this error, try `rustc --explain E0061`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): Caused by this line introduced in I found a similar issue in the past, this pull request fixes it: Unfortunately, this one looks like a spurious failure. It can be reproduced in the playground using nightly 2022-04-18, but when I try it locally using the same nightly version there is no ICE. This is the error message: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is this still reproducible? I didn't get the ICE, maybe theres some extra flags needed?
The playground seems to reliably reproduce it. And I can reproduce it sometimes using : But that is not always reliable. Given that the error message is "SourceNotAvailable", I guess this is related to how the toolchain is installed (the rust-src component?). Because at one point I tried the latest nightly with cargo-bisect-rustc and it did not ICE, but some days later I tried the same nightly using the same command and it did ICE. But I would just assume that while there is an in the code this issue is not fixed.
I'm currently using rustc 1.62.0-nightly ( 2022-04-25) and from the 10 times I tried executing the code, all of them generated an ICE.
I think I see this issue too. I also had to go back to 2022-04-18 to be able to compile my code.
I opened a pull request with a one line change that may fix this, but I have no way to reproduce it locally (compiling the example code works fine even without the changes of that pull request). The playground can still reproduce the issue as of nightly 2022-04-29, so we can use it to check if this issue is really fixed after that pull request is merged.
So I accidentally closed this issue by adding the words "may to the pull request description, but fortunately it looks fixed, as you can see thanks to the glacier bot.
Change:
$$(TLIB$(1)_T_$(4)_H_$(3))/libstd.rlib  $$(HLIB$(2)_H_$(4))/libcore.rlib  $$(HLIB$(2)_H_$(4))/$$(CFG_RUNTIME_$(4))  <del> | $$(HBIN$(2)_H_$(4))/ </del> <ins> | $$(HLIB$(2)_H_$(4))/ </ins> @$$(call E, cp: $$@) $$(Q)cp $$< $$@

Discussion:
There comes a time in the life of every Rust developer when they have to blow away various parts of the directory to avoid messages about "multiple matching crates". Then when they do the next build they get things like: . It would be better if the Makefile would just create all the needed parent directories automatically.
+1
I'm pretty sure I know how to do this. (I think the right tools for the job are some in and )
I haven't actually waited for a whole build to go through yet, and I have to leave for the evening. But I'd welcome it if you would be willing to pull this (SHA: ) into your repo and give it a spin. If you don't get around to it, no sweat; it can obviously wait until Monday.
argh ignore comment above; the commit isn't anywhere near fully baked yet; somethings off with my make syntax.
Okay. It would be nice to do this in the interim, but eventually when rustpkg is the build system it will do this (much more easily than with Makefile hacking), so no sweat if you don't get it done :-)
Change:
<ins> // Copyright 2013 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. // xfail-fast pub use local_alias = local; mod local { } fn main() {} </ins>

Discussion:
Having a generic seems to be necessary to exhibit the bug. (Caused .)
Reproduced with . Nominating.
cc me
declining; just-a-bug
cc me; possibly addressed by patch to
This has been fixed, adding a test for it soon.

Nominating well defined.
This seems to be fixed.
Not quite: If you put on the inner module, it works. I think this is actually working as intended: the 'pub' on the item being re-exported is itself the indication of whether it can be seen from outside. Curiously, you can't use it locally (with no anywhere in the file) either. This feels not entirely well defined? Or else I'm not well informed enough to address it. Leaving open until we have Patrick around for subsequent triage.
My two cents: makes sense that a 'd item must be , since that means you don't have to search for a pub use. seems like ought to work though.
accepted for well-defined milestone
This is working now. I think my extraction of privacy from resolve has fixed this. Removing all tags and flagging as needstest.
Change:
<ins> // Copyright 2013 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. // xfail-fast pub use local_alias = local; mod local { } fn main() {} </ins>

Discussion:
With the following test code: You get an ICE:
Looks quite similar to , which is probably .
After updating for removal of and feature-gating of macros, I don't get ICE any more.
Almost certainly fixed by

This code: Causes the ICE cc
Also a similar, but different error:
I've also confirmed that if everything is defined in the same crate, it all compiles just fine.
This may be related to , although it's a different error message so I'm not sure of it.
This is not related to
I just ran into this myself. One interesting thing I found is that the error happens due to the empty variant. This compiles fine for me:
Appears to be fixed now, flagging as needstest.

To replicate: (Original report follows:) I had code like this: This causes rustc to spin forever. Here's the interesting part of the stack trace:
In my attempt to replicate the bug (on a Mac OS machine), this appears to ICE now rather than hang.
(The fact that it ICE's now rather than diverges is probably thanks to )
Reproduced with
This was fixed at some point, the error message is now: which is exactly what one would expect! Flagging as needstest.
Change:
let size = u64::try_from(self.force_bits(size, pointer_size)?).unwrap(); let align = vtable.read_ptr_sized(pointer_size * 2)?.check_init()?; let align = u64::try_from(self.force_bits(align, pointer_size)?).unwrap(); <ins> let align = Align::from_bytes(align) .map_err(|e| err_ub_format!("invalid vtable: alignment {}", e))?; </ins> if size >= self.tcx.data_layout.obj_size_bound() { throw_ub_format!(

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 --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low