jiebi/CodeConvo huggingface dataset:
Change:
} } <del> pub fn mut_last<'a>(&'a mut self) -> &'a mut T { </del> <ins> pub fn mut_last<'a>(&'a mut self) -> Option<&'a mut T> { </ins> match *self { Vec(ref mut v) => v.mut_last(), <del> Empty => fail!("mut_last on empty opt_vec") </del> <ins> Empty => None </ins> } }

Discussion:
changed the , and methods of vectors to return an Option instead of failing on empty vectors. These methods should probably get the same change, to be consistent - - -
I'll try to fix this!
Change:
const Y: u32 = 0; } impl implementors::Whatever for Foo {} <ins> pub mod sub_mod { /// ```txt /// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa /// ``` /// /// ``` /// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa /// ``` pub struct Foo; } </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. --Repro: text /// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa /// rust /// bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb /// Rustdoc output: ! It seems that only code block with language are affected. cc
A quick test showed that the bug was introduced in (i.e.: works fine)
label +regression-from-stable-to-nightly
Thanks, I'll fix it in the next hours.
In case you want to take a look to the fix, it's .
Change:
#![feature(drain_filter)] #![feature(exact_size_is_empty)] #![feature(map_first_last)] <ins> #![feature(map_into_keys_values)] </ins> #![feature(new_uninit)] #![feature(pattern)] #![feature(str_split_once)]

Discussion:
Associative maps ( and ) in Rust are currently missing two methods to get owning iterators to their keys or values. We have to get key-value reference pairs, to get key-value mutable reference pairs and to get owned key-value pairs. I'd expect and to offer a similar trio of methods (with an exception for of course). is there, but the variants are missing for seemingly no good reason. As an example implementation (but perhaps we can do better):
I would accept a PR to introduce unstable intokeys() and intovalues().
Hi, I’m interested in working on this but I have a question regarding the implementation. I guess we can implement this in two ways. First one is implementing like the example in the first comment, like returning . And the second option is to return a struct of its own (like a mixture of and / structs) instead of returning . We can name them IntoKeys and IntoValues and they can be responsible of implementing the trait. I feel like performance wise they are same, since map and custom struct both will be evaluated lazily when we iterate over. But there might be a rule to always return a proper type in the rust std code that I don't know. So I think I’m okay implementing either way but wanted to ask just in case. What do you think?
For the public API I would prefer this implemented using dedicated IntoKeys and IntoValues iterator types. They can be implemented internally as wrappers around Map<IntoIter<K, Vif that simplifies things.
Thanks for the answer Created a PR for this and you as a reviewer. Would you mind taking a look at it when you have time?
Change:
// gdb-command:run // gdb-command:print some <del> // gdb-check:$1 = core::option::Option<&u32>::Some(0x12345678) </del> <ins> // gdb-check:$1 = core::option::Option<&u32>::Some(0x[...]) </ins> // gdb-command:print none // gdb-check:$2 = core::option::Option<&u32>::None // gdb-command:print full <del> // gdb-check:$3 = option_like_enum::MoreFields::Full(454545, 0x87654321, 9988) </del> <ins> // gdb-check:$3 = option_like_enum::MoreFields::Full(454545, 0x[...], 9988) </ins> <del> // gdb-command:print empty_gdb.discr // gdb-check:$4 = (*mut isize) 0x1 </del> <ins> // gdb-command:print empty // gdb-check:$4 = option_like_enum::MoreFields::Empty </ins> // gdb-command:print droid <del> // gdb-check:$5 = option_like_enum::NamedFields::Droid{id: 675675, range: 10000001, internals: 0x43218765} </del> <ins> // gdb-check:$5 = option_like_enum::NamedFields::Droid{id: 675675, range: 10000001, internals: 0x[...]} </ins> <del> // gdb-command:print void_droid_gdb.internals // gdb-check:$6 = (*mut isize) 0x1 </del> <ins> // gdb-command:print void_droid // gdb-check:$6 = option_like_enum::NamedFields::Void </ins> // gdb-command:print nested_non_zero_yep // gdb-check:$7 = option_like_enum::NestedNonZero::Yep(10.5, option_like_enum::NestedNonZeroField {a: 10, b: 20, c: 0x[...]})

Discussion:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.
Change:
} /// Return `a` < `b` lexicographically (Using partial order, `Ord`) <del> pub fn lt<A: Ord, T: Iterator<A>>(mut a: T, mut b: T) -> bool { </del> <ins> pub fn lt<A: Ord, T: Iterator<A>, S: Iterator<A>>(mut a: T, mut b: S) -> bool { </ins> loop { match (a.next(), b.next()) { (None, None) => return false,

Discussion:
They're currently very restricted as they only work with a single iterator type for both arguments, so, e.g. doesn't work. It should be easy to just add another parameter for the second argument.
Change:
let largest_niche = Niche::from_scalar(dl, Size::ZERO, tag.clone()); <del> tcx.intern_layout(Layout { </del> <ins> let tagged_layout = Layout { </ins> variants: Variants::Multiple { tag, tag_encoding: TagEncoding::Direct,

Discussion:
This prints the values in comments: Note that contains strictly more opportunities for optimization, but it's optimized worse. That's because it uses a "niche-filling" layout (using in the field of for ), but the "tag" layout wouldn't be any larger, because it has enough space in bytes to fit the (byte-sized) tag, and . uses the tagged layout since it has no other choice, and ends up with free values in the byte-sized tag, but "jumps the gun" on using a pre-existing niche.
Change:
} } else { let local = mir::RETURN_PLACE; <del> let ty = self.frame().body.local_decls[local].ty; if !self.tcx.is_ty_uninhabited_from_any_module(ty) { throw_unsup!(FunctionRetMismatch(self.tcx.types.never, ty)) </del> <ins> let callee_layout = self.layout_of_local(self.frame(), local, None)?; if !callee_layout.abi.is_uninhabited() { throw_unsup!(FunctionRetMismatch( self.tcx.types.never, callee_layout.ty )) </ins> } } Ok(())

Discussion:
Since we have a strange condition in the Miri/interpreter code that checks if a function got called with appropriate arguments: got replaced by . That's really strange, the layout should contain all the information we need for execution, and module boundaries certainly shouldn't matter for the call ABI. So I don't think this change is right, at least not for Miri. Unfortunately, there is 0 explanation of the "why" in that PR and in the code. It also does fix an ICE. Is this a case of running the interpreter on untyped code? Or why does looking at the layout not work? Cc
This is entirely my fault and also entirely unnecessary for fixing the ICE. I just believed this to be a useful cleanup: The reason is that computing the layout in a cached way (via ) requires that we actually have an IndexVec of locals, which we don't have for const prop. The previous code was so if you prefer that, I'm fine with moving there, I just thought it to be better to fix the problem at the layout checking place instead of at the layout computation place.
I'm afraid I disagree with that being a cleanup -- AFAIK the type-based tests exist for surface language stuff, like exhaustiveness check and whatnot, also taking into account semver considerations. But for the interpreter I'd like to be sure that we use the layout information that will also be used by codegen. constprop making a mess for everyone else, again. :( That other code seems okay to me, the comment is confusing though. What does that have to do with "constants being trivial"? And "don't allocate any locals" sounds like we wouldn't make them , which is not at all what this is about. But if that explains that might be empty when we are in constprop, I'd r+ that.
actually, has just made some changes there or is in the process of further changes. We may be able to revert after those changes are through because we'll have an actual stack frame available
That would be great! I thought there were some performance reasons for this.
There were strong performance reasons in the past. We alleviated most of them, but there are some left: not even 2% regression in artificial const eval benchmarks are fine with me for the enormous reduction in code complexity and duplication.

We may be able to find further improvements that help const prop and const eval now that they have started sharing more code.
Besides this issue here, do we carry existing hacks that we can remove with the more well-behaved const_prop?
I think there are some hacks about fallback behaviour on empty stacks
Change:
<del> error[E0019]: constant contains unimplemented expression type --> $DIR/const_let.rs:13:55 </del> <ins> error[E0493]: destructors cannot be evaluated at compile-time --> $DIR/const_let.rs:16:32 </ins> | LL | const Y: FakeNeedsDrop = { let mut x = FakeNeedsDrop; x = FakeNeedsDrop; x }; <del> |                                                       ^ </del> <ins> |                                ^^^^^ constants cannot evaluate destructors </ins> <del> error[E0019]: constant contains unimplemented expression type --> $DIR/const_let.rs:17:35 </del> <ins> error[E0493]: destructors cannot be evaluated at compile-time --> $DIR/const_let.rs:20:33 | LL | const Y2: FakeNeedsDrop = { let mut x; x = FakeNeedsDrop; x = FakeNeedsDrop; x }; |                                 ^^^^^ constants cannot evaluate destructors error[E0493]: destructors cannot be evaluated at compile-time --> $DIR/const_let.rs:24:21 </ins> | LL | const Z: () = { let mut x = None; x = Some(FakeNeedsDrop); }; <del> |                                   ^ </del> <ins> |                     ^^^^^ constants cannot evaluate destructors error[E0493]: destructors cannot be evaluated at compile-time --> $DIR/const_let.rs:28:22 | LL | const Z2: () = { let mut x; x = None; x = Some(FakeNeedsDrop); }; |                      ^^^^^ constants cannot evaluate destructors </ins> <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to 4 previous errors </ins> <del> For more information about this error, try `rustc --explain E0019`. </del>

Discussion:
In the following example, and are allowed but isn't: The reason is that is lowered to in MIR, and that's not handled in const-checking as a and an assignment (which it functionally is). EDIT: nevermind, promotion works based on temporaries, so it shouldn't be affected. cc
I'm going to label this as a bug since it seems covered by from a T-Lang perspective.
Change:
font-weight: 500; padding: 0; margin: 0; <del> margin-top: 0.5rem; margin-bottom: 0.25rem; </del> } .sidebar-links,

Discussion:
In rustdoc sidebars, most headings are clickable links. For instance, "Required Methods" and "Implementors" in the sidebar of However, the headings under "Other items in..." are not clickable. We should link those to the appropriate subheading on the module page. That allows the user to see a more verbose listing of items in the module, since each one has a description alongside it. <img width=150 src="https://user-"<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So, for instance, sidebar heading should lead ?
claim
Yes, that's correct.
By the way be aware this will conflict with Resolving the conflict should be pretty easy though.
Thanks
any progress on this? I'd like to get it landed before the beta cut, so we have a consistent UI where headings in the sidebar are clickable.
sorry, i couldn't make time last ,i will unassign me, thanks.
Change:
check!(a.created()); check!(b.created()); } <ins> if cfg!(target_os = "linux") { // Not always available match (a.created(), b.created()) { (Ok(t1), Ok(t2)) => assert!(t1 <= t2), (Err(e1), Err(e2)) if e1.kind() == ErrorKind::Other && e2.kind() == ErrorKind::Other => {} (a, b) => panic!( "creation time must be always supported or not supported: {:?} {:?}", a, b, ), } } </ins> } }

Discussion:
First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?
Change:
<del> error[E0577]: expected module, found unresolved item `crate::r#mod` --> $DIR/issue-61732.rs:3:8 </del> <ins> error[E0433]: failed to resolve: maybe a missing crate `r#mod`? --> $DIR/issue-61732.rs:3:15 </ins> | LL | pub(in crate::r#mod) fn main() {} <del> |        ^^^^^^^^^^^^ not a module </del> <ins> |               ^^^^^ maybe a missing crate `r#mod`? </ins> error: Compilation failed, aborting rustdoc error: aborting due to 2 previous errors <del> For more information about this error, try `rustc --explain E0577`. </del> <ins> For more information about this error, try `rustc --explain E0433`. </ins>

Discussion:
Example: Found by crater run (https://crater-) when visibility resolution switched to a different algorithm (early resolution), which doesn't have this problem.
This is a regression from Rust 1.33.
Diagnostic improvements strike again:
Fixed in
Change:
<ins> #![feature(member_constraints)] #![feature(type_alias_impl_trait)] pub trait A { type B; fn f(&self) -> Self::B; } impl<'a, 'b> A for () { //~^ ERROR the lifetime parameter `'a` is not constrained //~| ERROR the lifetime parameter `'b` is not constrained type B = impl core::fmt::Debug; fn f(&self) -> Self::B {} } fn main() {} </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. --: I had first seen: Removing the second lifetime () gives the correct error, Additionally, disabling either or still panics (and prompts to enable those features), except in stable where it prompts to enable the features, but does not panic. Perhaps similar to <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE is fixed in the latest nightly, marking as .
Change:
) fn mk_ident_interner() -> @ident_interner { <del> /* the indices here must correspond to the numbers in special_idents */ let init_vec = ~[@~"_", @~"anon", @~"drop", @~"", @~"unary", @~"!", @~"[]", @~"unary-", @~"__extensions__", @~"self", @~"item", @~"block", @~"stmt", @~"pat", @~"expr", @~"ty", @~"ident", @~"path", @~"tt", @~"matchers", @~"str", @~"TyVisitor", @~"arg", @~"descrim", @~"__rust_abi", @~"__rust_stack_shim", @~"TyDesc", @~"dtor", @~"main", @~"<opaque>", @~"blk", @~"static", @~"intrinsic", @~"__foreign_mod__"]; let rv = @ident_interner { interner: interner::mk_prefill::<@~str>(init_vec) }; /* having multiple interners will just confuse the serializer */ </del> unsafe { <del> assert task::local_data::local_data_get(interner_key!()).is_none() }; unsafe { task::local_data::local_data_set(interner_key!(), @rv) }; rv </del> <ins> match task::local_data::local_data_get(interner_key!()) { Some(interner) => *interner, None => { // the indices here must correspond to the numbers in // special_idents. let init_vec = ~[ @~"_", @~"anon", @~"drop", @~"", @~"unary", @~"!", @~"[]", @~"unary-", @~"__extensions__", @~"self", @~"item", @~"block", @~"stmt", @~"pat", @~"expr", @~"ty", @~"ident", @~"path", @~"tt", @~"matchers", @~"str", @~"TyVisitor", @~"arg", @~"descrim", @~"__rust_abi", @~"__rust_stack_shim", @~"TyDesc", @~"dtor", @~"main", @~"<opaque>", @~"blk", @~"static", @~"intrinsic", @~"__foreign_mod__" ]; let rv = @ident_interner { interner: interner::mk_prefill(init_vec) }; task::local_data::local_data_set(interner_key!(), @rv); rv } } } </ins> } /* for when we don't care about the contents; doesn't interact with TLD or

Discussion:
Here's an example:
I'm going to vote for this to be a 0.4 blocker since it's breaking cargos like . Cargo is violating an assumption in the parser that there's only one parser made per task. calls , which caches an interner in TLS on the first call, or assert if an interner has already been created. Unfortunately cargo creates a new parser session per crate, which triggers the assertion. I think this won't be too hard to work around. We could just get rid of the assertion, and share the interner across all parsers in the same thread. I'll prep a patch for this. I'm not sure if this will violate other assumptions in the compiler though. The other option would be to hack up cargo to run in a new thread. This will require some jury rigging, but it'll keep us from having to tweak the parser this close to release.
-- is this bug fixed now that your interner cache fix is merged?
yep, closing.
Change:
format!("{}-{}", name, target.triple) } else if name == "rust-analyzer" { "rust-analyzer-preview".to_string() <ins> } else if name == "clippy" { "clippy-preview".to_string() </ins> } else if name == "rust-demangler" { "rust-demangler-preview".to_string() } else if name == "miri" {

Discussion:
It should not be possible that clippy component is missing since we are gating on it in CI..? cc
I think this is a rustup bug somehow, it's looking specifically for : I can back this out to give rustup time to fix it in a new release, this wasn't an urgent fix. I want to spend another few minutes investigating first though.
I don't think rustup's rename system is designed to allow changing the name of a component. contains more information about how and why this was done.
says I need at a minimum to keep the key for clippy-preview. I will try to test that out today but I don't have permissions for a dist-static build and it might take me a bit so I'll put up a revert in the meantime.
I'm happy to run dev-static builds as needed, but I agree that a revert is appropriate for the time being. Please feel free to poke on Zulip if you need a quick review, etc. I'm a little surprised our testing in didn't catch this -- let's make sure we understand how to test it in the future.
what went wrong in is that worked before and after, but running before and after did not. I'll make sure to test that in any future PR.
Change:
<ins> // compile-flags: --crate-type=lib #[derive(Default)] //~ ERROR multiple declared defaults enum E { #[default] A, #[default] A, //~ ERROR defined multiple times } </ins>

Discussion:
Found with a thread 'rustc' panicked at 'assertion failed: !suggestion.isempty()', <details<summaryBacktrace</summary</detailsFirst ICEd in nightly-2021-07-29, likely from ( which support for enums. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
PR is up at
Change:
expected: Expectation<'tcx>, ) -> Option<Ty<'tcx>> { if let [callee_expr, rest @ ..] = arg_exprs { <del> let callee_ty = self.check_expr(callee_expr); </del> <ins> let callee_ty = self.typeck_results.borrow().expr_ty_adjusted_opt(callee_expr)?; </ins> // First, do a probe with `IsSuggestion(true)` to avoid emitting // any strange errors. If it's successful, then we'll do a true // method lookup.

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
Regression in /
Perhaps ? :thinking: cc
list of files that reproduce the crash ( is eough) `
I think we should change to a

Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (
Change:
&self, obligation: &PredicateObligation<'tcx>, ) -> bool { <del> self.evaluate_obligation(obligation).may_apply() </del> <ins> self.evaluate_obligation_no_overflow(obligation).may_apply() </ins> } /// Evaluates whether the predicate can be satisfied in the given

Discussion:
Steps to reproduce:
I assume this is the same as
Running into this as well when running on 1.30.0-nightly ( 2018-08-05)
Hit this on the newest nightly ( 2018-08-18)
Same issue, slightly different line number Filtered log:
any idea what's going on here? let us know if you need T-compiler help :)
I didn't check yet, still on my todo list. I'll give it a look this week-end.
It would be great to have a minimized example here =)
True, I'll try to make one.
I think this is the same as as well
visited for triage. PR just needs to be landed.
Reopening; since we never backported , rustdoc ICE's on typenum again.
visiting for triage. It looks like PR is on target to be backported to stable. (In fact, the recent update of the labels to say just leads me to assume that the backport has occurred... yes, it was part of PR )
So, only two questions I have now: I openly mused to myself during this triage session that the failure to backport to beta sooner may represent a process failure of some sort. But there may be a very simple fix: Can/should we revise bors to not autoclose issues that are tagged as stable-to-beta or stable-to-stable regressions? Filed as barosl/homu On the subject of closing: Can we close this issue in light of ? Or do we need to wait until the 1.30.1 point release has officially been deployed?
Closed since 1.30.1 was released already.