jiebi/CodeConvo huggingface dataset:
Change:
#[stable(feature = "rust1", since = "1.0.0")] impl<T> Drop for IntoIter<T> { <ins> #[unsafe_destructor_blind_to_params] </ins> fn drop(&mut self) { // destroy the remaining elements for _x in self {}

Discussion:
The following code compiles on stable and beta, but not nightly: For reference, the error produced by the above is: The original test case was reduced down to the above thanks to eddyb and bluss. The original problematic line was (clap → → → boom). Specifically, the issue was with the method, though the error pointed to an earlier temporary as not living long enough. If desired, I can provide a complete, in-context example of this going awry. bluss suggested that this was related to .
cc
Hmm I wonder if the iterators involved need to have the escape hatch for dropck to them.
Here is a variant (that has also regressed) that does not use the macro:
(It looks like may need similar treatment too, but I am having trouble actually making a concrete test illustrating the necessity there -- it seems when I call instead of in the above test case, even stable and beta complain about lifetime issues. Maybe the old dropck is catching something I'm missing in my manual analysis of , so I'm not going to lump that in until I see evidence that it is warranted.) Update: Oh, duh, has a lifetime bound (and a impl), so of course the old dropck was going to reject it.
Change:
missing_weak_lang_items .iter() .map(|item| (format!("{prefix}{item}"), SymbolExportKind::Text)), <del> ) </del> <ins> ); if tcx.allocator_kind(()).is_some() { // At least one crate needs a global allocator. This crate may be placed // after the crate that defines it in the linker order, in which case some // linkers return an error. By adding the global allocator shim methods to // the linked_symbols list, linking the generated symbols.o will ensure that // circular dependencies involving the global allocator don't lead to linker // errors. linked_symbols.extend(ALLOCATOR_METHODS.iter().map(|method| { ( format!("{prefix}{}", global_fn_name(method.name).as_str()), SymbolExportKind::Text, ) })); } </ins> }); }

Discussion:
I have a project that overrides the global allocator in , and recently noticed that I can no longer link the test binary for my project with recent beta/nightly compilers. points to which certainly looks relevant. I reproduced the error using a slightly modified example from the global allocator documentation: If I move the allocator definition from to , I no longer have a problem. Is that the right thing to do? If so, do I need to do anything else to make sure my tests use the desired allocator? I tried this code: I expected to see this happen: Instead, this happened: searched nightlies: from nightly-2023-05-25 to nightly-2023-06-16 regressed nightly: nightly-2023-05-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details modify labels: +regression-from-stable-to-beta -regression-untriaged
Adding the full linker error output here in case it's of interest.
I tried adding based on a brief look at the change that pointed to. It doesn't seem to make any difference, but that's why it's in my repro above.
I can reproduce this. and such are properly defined in the library rlib. It seems to be caused by the library order. Traditional linkers require symbols to have their uses in object files before their definition. So for circular dependencies and has to be used or libraries have to be mentioned multiple times. And indeed which doesn't have this restriction is entirely fine with this. I think registering a circular dependency between the defining crate of and liballoc (and every crate that depends on it) at would work. Edit: Reading the code it references closer, I think adding to would be enough to fix this. I can't work on this tomorrow, but unless someone else picks it up, I will work on this.
Finished some work early. fixes the issue.
thank you for the quick fix!
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
use rustc_hir::HirId; use rustc_lint_defs::Applicability; use rustc_resolve::rustdoc::source_span_for_markdown_range; <ins> use rustc_span::def_id::DefId; </ins> use rustc_span::Symbol; use crate::clean::utils::find_nearest_parent_module;

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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage
Change:
} // let exprs last <del> if self.option_loud_drop(20).is_some() // 2 && self.option_loud_drop(19).is_some() // 1 </del> <ins> if self.option_loud_drop(19).is_some() // 1 && self.option_loud_drop(20).is_some() // 2 </ins> && let Some(_d) = self.option_loud_drop(23) // 5 && let Some(_e) = self.option_loud_drop(22) { // 4 self.print(21); // 3

Discussion:
If you consider the following program: It will print "2,3,4,1," four times. The issue occurs on recent nightly as well as all the way back to 1.0.0. This is a bit weird IMO, and makes && and chains non-associative. IMO it's a bug that should be fixed to print "1,2,3,4,". IDK how much we can do about this at the current point, given backwards compatibility concerns. It might not stop programs from compiling, but programs might differ in their runtime output. There is with the name "Stabilize drop order" but if you read the text, it only concerns the drop order of structs, vecs, tuples, etc. Also, after the merge, the RFC author themself made a PR to add regression tests in , and mentioned that that PR was enough for getting the RFC tested. The RFC didn't include anything about && chains. I think the language should not be interpreted too generally. It took a long time until in which we we got some further drop order tests for "established" language constructs, while there have been many PRs with drop order tests for let-else. Originally I've discovered this in: , but given that it's so visible, I'm sure that someone else has already complained about this. Maybe one can just implement the change to "1,2,3,4," and make a crater run for it? cc label T-lang
Change:
*/ #![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")] <ins> #![feature(bindings_after_at)] </ins> #![feature(bool_to_option)] #![feature(box_syntax)] #![feature(crate_visibility_modifier)]

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
glacier ""
cc
Guess I should claim this too since its likely a duplicate of that issue? claim

<!-- 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 --
This no longer needs since minconst_generics has been stabilized. cc
claim
Change:
impl Bar<A> { fn foo() {} } impl Bar<B> { fn foo() {} } <ins> // Regression test for issue #89820: impl Bar<u8> { pub fn a() {} pub fn aa() {} } impl Bar<u16> { pub fn b() {} pub fn bb() {} } impl Bar<u32> { pub fn a() {} pub fn aa() {} pub fn bb() {} pub fn b() {} } </ins> fn main() {}

Discussion:
's stm32f4 is failing:
I suspect this is caused by , merged in (rollup) and root PR -- is this expected breakage (i.e., code in stm32f4 is unsound/should never have been accepted)?
Change:
_ => unreachable!(), } <del> let terminator = bb.terminator_mut(); // add StorageDead for the place switched on at the top of each target for bb_idx in new_targets.iter() { storage_deads_to_insert.push(( *bb_idx, Statement { source_info: terminator.source_info, kind: StatementKind::StorageDead(opt.to_switch_on.local), }, )); } terminator.kind = TerminatorKind::SwitchInt { discr: Operand::Move(opt.to_switch_on), switch_ty: opt.branch_value_ty, values: vec![new_value].into(), targets: new_targets, }; </del> // delete comparison statement if it the value being switched on was moved, which means it can not be user later on if opt.can_remove_bin_op_stmt { bb.statements[opt.bin_op_stmt_idx].make_nop();

Discussion:
The following program runs fine in Miri on mir-opt-levels 0-2, but in level 3 it errors: The error is: Looks like something changes the liveness ranges of locals and it does so incorrectly. Cc
Could you describe affected rustc version and reproduction steps?
The rustc version is commit , but most likely a nightly will also do it. To reproduce, run this in a Miri checkout:
The SimplifyComparisonIntegral introduces StorageDead for a local which didn't have any markers before. Currently this also makes the local dead on the entry to the function. Related to the issue about semantics of StorageLive without matching StorageDead (this would be the reverse).
The LLVM docs for their version of (which the Rust thing translates to) So just introducing a without also having appropriate is pretty clearly wrong, I would say.
That is the doc for , not . The doc for is:
oops sorry, yeah. We'd have to check the MIR here to see if it makes any sense at all; however, currently I think not just Miri but also our dataflow framework assumes that variables with any liveness annotations are initially dead.
Diff for this case before/after SimplifyComparisonIntegral: Note the placed in both successors of the , when there was no to begin with. cc -- along the lines of , you could leave the as a copy in this case for later optimisation passes to clean up. This is definitely a case I can cover for .
Does this analysis ensure that is not used any more afterwards? As in, would it be sufficient to add a in the start block? (I am not saying that that's a good fix, just trying to feel out the design space here.) I guess I am also surprised that an "integral comparison simplification" pass touches storage liveness.
That part is my fault. I incorrectly assumed that there's a storagedead before the switch. Maybe there is one in some situations, idk, if there is, we should probably just not do the optimization instead of rewriting the storage markers.
Should this be marked as I-unsound?
Assigning as discussed as part of the . modify labels: +P-medium -I-prioritize
Error: Label P-medium can only be set by Rust team members Please let know if you're having trouble with this bot.
Change:
<del> Subproject commit 14a3b123074e066d64a99886941473058e52197d </del> <ins> Subproject commit cf9304d6d0c6a66c27a1664dd55d8bcc8be0bf09 </ins>

Discussion:
The following code, when compiled with opt level of 2 or higher results in an llvm assertion (if they're enabled) on i686-pc-windows-gnu. <details<summaryllc backtrace when compiling the --emit llvm-ir output</summary</details
I don't think it's windows-gnu specific: I'll try to backport the fix.
Opened which waits for (I don't have permission).
Change:
#[unstable(feature = "step_trait", reason = "recently redesigned", issue = "42168")] impl Step for $i_wider { step_identical_methods!(); <ins> step_signed_methods!($u_wider); </ins> #[inline] fn steps_between(start: &Self, end: &Self) -> Option<usize> {

Discussion:
I tried this code: I expected to see this happen: No UB. Instead, this happened: UB, confirmed by Miri. is called, which does , or . The implementation of is correct here, and should be safe to call. The implementation that does a wrapping cast from to before doing the unchecked math is the incorrect code here. Signed integers should switch to just using wrapping or unsigned math, whichever gets better codegen out of LLVM. We do have and methods now, but no . <!-- 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. --:
Note that this is reachable on stable since the default impl of uses and not all adapters forward both.
did you find this with Miri or just use Miri to confirm the bug? (I'm asking because I may want to add this to our "bugs found by Miri" list :)
Only confirmed/diagnosed with Miri, spotted manually when looking at the code.
Change:
ast::GenericBound::Trait(ref poly_trait_ref) => { let snippet = context.snippet(self.span()); let has_paren = snippet.starts_with('(') && snippet.ends_with(')'); <del> let ast::TraitBoundModifiers { constness, asyncness, polarity, } = poly_trait_ref.modifiers; let mut constness = constness.as_str().to_string(); if !constness.is_empty() { constness.push(' '); } let mut asyncness = asyncness.as_str().to_string(); if !asyncness.is_empty() { asyncness.push(' '); } let polarity = polarity.as_str(); let shape = shape .offset_left(constness.len() + polarity.len()) .max_width_error(shape.width, self.span())?; </del> poly_trait_ref .rewrite_result(context, shape) <del> .map(|s| format!("{constness}{asyncness}{polarity}{s}")) </del> .map(|s| if has_paren { format!("({})", s) } else { s }) } ast::GenericBound::Use(ref args, span) => {

Discussion:
I tried : I expected to see this happen: nothing Instead, this happened: rustfmt reorders and incorrectly...
cc I imagine this blocks stabilization.
Ah, I definitely forgot to reorder these bounds after we settled the ordering.
Change:
cg: codegen_options, externs, target_triple: target, <del> // Ensure that rustdoc works even if rustc is feature-staged unstable_features: UnstableFeatures::Allow, </del> <ins> unstable_features: UnstableFeatures::from_environment(), </ins> actually_rustdoc: true, debugging_opts: debugging_options, error_format,

Discussion:
This generates documentation with a stable rustdoc today without any warnings. Interestingly, rustdoc does seem to check that the feature gate is in the crate (i.e., must exist), and will error if a feature gate has been removed (e.g., custom_attribute on nightly).
cc
I'd guess this is related to somehow. I'm not entirely sure what rustdoc relies on which would mandate the locking in of the permission to use unstable features, but perhaps would know?
Normally, for such things rustdoc relies on rustc internals to do the work. Maybe an option is badly set?
triage: looks like this should be T-rustdoc's call as to what priority to assign here. Leaving unprioritized and nominated, at least for a week.
I made the priority medium: it's not a huge bug but the quicker it's fixed, the better it'll be for everyone.
should fix this.
Thanks! I've also gone ahead and nominated it for beta backport as it's probably good to close the stability hole sooner rather than later; it's a trivial patch.
Change:
use rustc_session::lint::builtin::AMBIGUOUS_ASSOCIATED_ITEMS; use rustc_span::edit_distance::find_best_match_for_name; use rustc_span::symbol::{kw, Ident, Symbol}; <del> use rustc_span::{sym, Span, DUMMY_SP}; </del> <ins> use rustc_span::{sym, BytePos, Span, DUMMY_SP}; </ins> use rustc_target::spec::abi; use rustc_trait_selection::traits::wf::object_region_bounds; use rustc_trait_selection::traits::{self, NormalizeExt, ObligationCtxt};

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 --
the problem is probably line 8 of the suggestion? !
claim
Minimized a bit more: The issue occurs because we compute a wrong span for the args . Instead of this: it spans the entire distance from the end of in the first line to the end of in the next line: The reasons for this is that we compute the span starting from the end of the variant path segment ( in this case) to end of the args (the right angle bracket of of ). Normally it works, but leads to the above miscalculation when the variant and the args reside in different macros or expansions as in the present case. The offending source code doing the span computation is this:
Change:
<ins> use self::A::*; use V; //~ ERROR `V` is ambiguous use self::B::*; enum A { V } enum B { V } fn main() {} </ins>

Discussion:
thread 'rustc' panicked at ': inconsistent resolution for an import', <details<summaryBacktrace</summary</detailsRegression in nightly-2018-12-30 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same error message as , but this one is self-contained and might be a separate bug.
claim
how about make this to an error with diagonostic? Seems we don't have a chance to insert , because the is before the later . If we change code to this: It will be:
Could we register an exactly in the place we ICE?
Yes, this is also a solution, and then we can report error in the same function .
Change:
<del> #![crate_type="lib"] </del> <ins> #![crate_type = "lib"] </ins> pub struct Bar; pub trait Foo { type X; <del> fn foo() -> Self::X; </del> <ins> fn foo(x: u32) -> Self::X; </ins> } #[doc(alias = "foo")] //~ ERROR

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
ICE only appears since 1.52. label regression-from-stable-to-stable
Better-looking code example Bisection points to
Reading the descriptions, I’d guess most likely , cc
This is indeed caused by since we're now checking parameters unlike before. The issue is in when . The call to panics because there is no name for a param. The question I have is whether we should support params for doc aliases. I didn't find anything in the tracking issue to indicate that it was supposed to be supported, and I personally don't think it makes sense. If we decide to not support doc aliases for params, then it should be an easy change to to error when is a . cc
Doc aliases are only supported for items showing up in doc search, function parameters don't, so in this case, it should error on the doc alias attribute.
Do you want to send a fix or should I?
I'll submit a fix.
Thanks! Please ping me on it (and don't forget to add a test for it too ;) ).
Change:
<ins> // Copyright 2012 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. #![deny(unused_variables)] fn main() { for _ in match return () { () => Some(0), } {} } </ins>

Discussion:
Code: Warning: It probably has something to do with for loop desugaring.
I think this should be marked "E-Easy" Relevant code is in . Prefixing the variable name with an should probably be enough to fix this (and a testcase in )
E-easy‽ I'd like to try this one.
Change:
#include <iostream> <ins> // for raw `write` in the bad-alloc handler #ifdef _MSC_VER #include <io.h> #else #include <unistd.h> #endif </ins> //===----------------------------------------------------------------------=== // // This file defines alternate interfaces to core functions that are more

Discussion:
Running a build of , as part of a Koiji (Fedora Build System) job, I get the following for the target: Also see:
To my understanding this should be Rust
I think this is "just" an OOM situation. Fedora builds with full debuginfo by default, and this package is configured for fat LTO as well, which will all get quite heavy. When I tried to reproduce this with the stable toolchain, I got: It completed when I turned off debuginfo though. With Fedora's toolchain, I can reproduce your SIGSEGV in LLVM, but it also completes the build when debuginfo is off. My guess is that it is also hitting an allocation failure, but perhaps in a place that doesn't properly check the pointer before trying to use it.
With the rustup toolchain, it's running out of memory in LLVM's , which calls allocation methods that abort on failure. That's where we get the "LLVM ERROR: out of memory", "Allocation failed". With the Fedora toolchain, it's running out of memory in LLVM's , which calls to plain , throwing . Rust runs its own destructors during that unwind, in particular dropping that calls , and this segfaults in a (presumably the same one).
I encontered this when compiling a big proprietary project to --target=i686-unknown-linux-musl using nightly-2024-03-01 on a x86_64 host
with an x86_64 host and a different backtrace, I doubt that yours has the same root cause. I suggest filing a separate issue -- but it's going to be hard for anyone to help if they can't reproduce it, since your code is proprietary.
Change:
if (self.pred)(&mut node.as_mut().element) { // `unlink_node` is okay with aliasing `element` references. self.list.unlink_node(node); <del> return Some(Box::from_raw(node.as_ptr()).element); </del> <ins> return Some(Box::from_raw_in(node.as_ptr(), &self.list.alloc).element); </ins> } } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: alloc <addrand dealloc <addris printed Instead, this happened: only alloc <addris printed <!-- 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. --: forgets that it's been initialized with an allocator, and always deletes the node with the global allocator. There seems to be one more place where this happens in the same file. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
Normal, Loop(hir::LoopSource), Closure, <ins> AsyncClosure, </ins> LabeledBlock, AnonConst, }

Discussion:
With: you get: Note how it references "a closure" which seems confusing for a user who doesn't presume the implementation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I'm assuming its ok to leave this as the same error code of E0267 - in essence it's the same error, just more specific text.
Yeah I think it's fine.