jiebi/CodeConvo huggingface dataset:
Change:
lp: &Rc<LoanPath<'tcx>>) { debug!("check_if_path_is_moved(id={}, use_kind={:?}, lp={})", id, use_kind, lp.repr(self.bccx.tcx)); <ins> // FIXME (22079): if you find yourself tempted to cut and paste // the body below and then specializing the error reporting, // consider refactoring this instead! </ins> let base_lp = owned_ptr_base_path_rc(lp); self.move_data.each_move_of(id, &base_lp, |the_move, moved_lp| { self.bccx.report_use_of_moved_value(

Discussion:
So I was curious how Drop handles cycles, because this could lead to dangling pointers, which is why . And indeed the below example does not call Drop. But is moved into , so why does this compile at all?
Nominating, seems like a soundness hole.
This is an issue with zeroing dynamic drops (which are going to be removed: rust-lang/rfcs) – when is moved, its drop flag is cleared, which prevents the destructor of from running. A clearer example is:
Structs that implement drop are not supposed to be in a partially initialized state. We already prevents moves out from individual fields, but we also need to prevent individual fields from being re-initialized. cc since (iirc?) he was working on the patches that made us more accepting around re-initializing fields and so forth, and maybe this bug is of interest to him.
So we are not supposed to allow structs that implement drop to be partially initialized. We already disallow going from fully-initialized to partially initialized. But it seems (from the first example) that we missed disallowing going from fully-uninitialized to partially initializd. That needs to be fixed. Assigning P-backcompat-lang, 1.0.
While this will hopefully be fixed soon, as there is a PR up, it seems to have fallen through the cracks as a P-backcompat-lang issue that is only on the 1.0 milestone and not 1.0 beta. Nominating for 1.0 beta. (Also, I guess I will try to run through and find any other such overlooked issues.)
Assigning 1.0 beta.
Change:
<ins> error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/unsized-function-parameter.rs:5:9 | LL | fn foo1(bar: str) {} |         ^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `str` = help: unsized fn params are gated as an unstable feature help: function arguments must have a statically known size, borrowed types always have a known size | LL | fn foo1(bar: &str) {} |              ^ error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/unsized-function-parameter.rs:11:9 | LL | fn foo2(_bar: str) {} |         ^^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `str` = help: unsized fn params are gated as an unstable feature help: function arguments must have a statically known size, borrowed types always have a known size | LL | fn foo2(_bar: &str) {} |               ^ error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/unsized-function-parameter.rs:17:9 | LL | fn foo3(_: str) {} |         ^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `str` = help: unsized fn params are gated as an unstable feature help: function arguments must have a statically known size, borrowed types always have a known size | LL | fn foo3(_: &str) {} |            ^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
() Errors: Applying the suggestion leads to yet more errors. The new errors do suggest using , but they still suggest invalid code: After applying the new suggestions, I get: This seems likely to send new users in circles. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Assigning and removing as in the prioritization working group.
I've bisected to this nightly range: +nightly-2020-07-12-x8664-unknown-linux-gnu =old error msg +nightly-2020-07-26-x8664-unknown-linux-gnu =new error message (I cannot bisect further because in between of that range I cannot install nightlies :man_shrugging: )
Funny enough, when using as variable name, the suggestion will get displayed correctly:
This seems to be fixed on nighlty, but not on beta... somewhere between ... Fixed in Fixed by So this can be closed
But, as a sidenote: How could this ever be commited to master? I mean, it's obviosly wrong so say :/ I hope, that in the future the review process can be improved to detect such errors early on. The error was introduced in , where the test has been adapted to match the wrong syntax, but nobody has seen this :( Let's hope in the future it will get noticed right away
It looks like that PR caused a bunch of small diagnostics changes, so the reviewers probably just missed that bug.
Assigning myself for adding a test. claim
Change:
let paths = builder .paths .iter() <del> .map(components_simplified) .filter_map(|path| { if path.get(0) == Some(&"compiler") { path.get(1).map(|p| p.to_owned()) } else { None } </del> <ins> .filter(|path| { let components = components_simplified(path); components.len() >= 2 && components[0] == "compiler" </ins> }) .collect::<Vec<_>>();

Discussion:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild
Change:
// See ./transparent.rs // Some platforms pass large aggregates using immediate arrays in LLVMIR <del> // Other platforms pass large aggregates using struct pointer in LLVMIR </del> <ins> // Other platforms pass large aggregates using by-value struct pointer in LLVMIR // Yet more platforms pass large aggregates using opaque pointer in LLVMIR </ins> // This covers the "immediate array" case. #![feature(no_core, lang_items, transparent_unions)]

Discussion:
The motivation behind the "just ignoring" approach for this PR was based on the fact that I was looking at this as two independent tasks. One of them is to ignore this test for aarch64 (inevitable) and the other is to add suitable tests for the same target. The former is immediate, the latter requires a bit more effort, and is something that should follow. But if we should proceed in a different way, that's fine too. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign
I started taking a look at this. Adding the tests should be straight forward, but I am also interested in finding out why the llvm bitcode is being generated the way it is for aarch64.
Triage: Are you still working on this?
Change:
<ins> use std::fmt::{self, Debug}; </ins> use rustc_data_structures::captures::Captures; use rustc_data_structures::fx::FxHashMap; use rustc_data_structures::graph::WithNumNodes; <del> use rustc_index::bit_set::BitSet; </del> use rustc_index::IndexVec; <del> use rustc_middle::mir::coverage::*; </del> <ins> use rustc_middle::mir::coverage::{CounterId, CovTerm, Expression, ExpressionId, Op}; </ins> <del> use super::graph::{BasicCoverageBlock, CoverageGraph, TraverseCoverageGraphWithLoops}; use std::fmt::{self, Debug}; </del> <ins> use crate::coverage::graph::{BasicCoverageBlock, CoverageGraph, TraverseCoverageGraphWithLoops}; </ins> /// The coverage counter or counter expression associated with a particular /// BCB node or BCB edge.

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'', 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc ^_^
Further reduced:
(Also note that even before this presumably would have still ICEd, because the only thing we did with that error was unwrap it.)
I think the assertion is just incorrect in this case. Normally a BCB will only have a physical counter if it has exactly one in-edge. If it has multiple in-edges, it will get an expression that sums up all of its in-edges, most of which will have physical counters. That's what the assertion is verifying. However, if a BCB has an out-edge back to itself (i.e. ), it gets a physical counter regardless. The assertion doesn't account for this, and fails. Perhaps the reason we haven't seen this before is that the other in-edge to the loop node usually happens to be the one chosen to get an expression, so the assertion never sees the two-counters case.
I tried to fix the assertion itself, but that ended up being pretty complicated. The information we'd need isn't readily available in the place that we need it, and there's also a related assertion in that has the same problem. Given that these assertions aren't load-bearing (the code should work fine even if it's violated), I'm inclined to just rip them out. They only exist as a holdover from the original implementation anyway.
Change:
<ins> // check-pass #![allow(dead_code)] trait Structure<E>: Sized where E: Encoding { type RefTarget: ?Sized; type FfiPtr; unsafe fn borrow_from_ffi_ptr<'a>(ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget>; } enum Slice {} impl<E> Structure<E> for Slice where E: Encoding { type RefTarget = [E::Unit]; type FfiPtr = (*const E::FfiUnit, usize); unsafe fn borrow_from_ffi_ptr<'a>(_ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget> { panic!() } } trait Encoding { type Unit: Unit; type FfiUnit; } trait Unit {} enum Utf16 {} impl Encoding for Utf16 { type Unit = Utf16Unit; type FfiUnit = u16; } struct Utf16Unit(pub u16); impl Unit for Utf16Unit {} struct SUtf16Str { _data: <Slice as Structure<Utf16>>::RefTarget, } impl SUtf16Str { pub unsafe fn from_ptr<'a>(ptr: <Slice as Structure<Utf16>>::FfiPtr) -> Option<&'a Self> { std::mem::transmute::<Option<&[<Utf16 as Encoding>::Unit]>, _>( <Slice as Structure<Utf16>>::borrow_from_ffi_ptr(ptr)) } } fn main() { const TEXT_U16: &'static [u16] = &[]; let _ = unsafe { SUtf16Str::from_ptr((TEXT_U16.as_ptr(), TEXT_U16.len())).unwrap() }; } </ins>

Discussion:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest
Change:
<ins> // check-pass #![allow(dead_code)] trait Structure<E>: Sized where E: Encoding { type RefTarget: ?Sized; type FfiPtr; unsafe fn borrow_from_ffi_ptr<'a>(ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget>; } enum Slice {} impl<E> Structure<E> for Slice where E: Encoding { type RefTarget = [E::Unit]; type FfiPtr = (*const E::FfiUnit, usize); unsafe fn borrow_from_ffi_ptr<'a>(_ptr: Self::FfiPtr) -> Option<&'a Self::RefTarget> { panic!() } } trait Encoding { type Unit: Unit; type FfiUnit; } trait Unit {} enum Utf16 {} impl Encoding for Utf16 { type Unit = Utf16Unit; type FfiUnit = u16; } struct Utf16Unit(pub u16); impl Unit for Utf16Unit {} struct SUtf16Str { _data: <Slice as Structure<Utf16>>::RefTarget, } impl SUtf16Str { pub unsafe fn from_ptr<'a>(ptr: <Slice as Structure<Utf16>>::FfiPtr) -> Option<&'a Self> { std::mem::transmute::<Option<&[<Utf16 as Encoding>::Unit]>, _>( <Slice as Structure<Utf16>>::borrow_from_ffi_ptr(ptr)) } } fn main() { const TEXT_U16: &'static [u16] = &[]; let _ = unsafe { SUtf16Str::from_ptr((TEXT_U16.as_ptr(), TEXT_U16.len())).unwrap() }; } </ins>

Discussion:
While minimizing I stumbled upon another ICE () Errors:
modify labels: I-ICE A-closures A-impl-trait C-bug F-typealiasimpl_trait T-compiler
The ICE doesn't appear on the latest nightly
Change:
pub trait EarlyLintPass: LintPass { fn check_ident(&mut self, _: &EarlyContext, _: Span, _: ast::Ident) { } fn check_crate(&mut self, _: &EarlyContext, _: &ast::Crate) { } <ins> fn check_crate_post(&mut self, _: &EarlyContext, _: &ast::Crate) { } </ins> fn check_mod(&mut self, _: &EarlyContext, _: &ast::Mod, _: Span, _: ast::NodeId) { } fn check_foreign_item(&mut self, _: &EarlyContext, _: &ast::ForeignItem) { } fn check_item(&mut self, _: &EarlyContext, _: &ast::Item) { } <ins> fn check_item_post(&mut self, _: &EarlyContext, _: &ast::Item) { } </ins> fn check_local(&mut self, _: &EarlyContext, _: &ast::Local) { } fn check_block(&mut self, _: &EarlyContext, _: &ast::Block) { } <ins> fn check_block_post(&mut self, _: &EarlyContext, _: &ast::Block) { } </ins> fn check_stmt(&mut self, _: &EarlyContext, _: &ast::Stmt) { } fn check_arm(&mut self, _: &EarlyContext, _: &ast::Arm) { } fn check_pat(&mut self, _: &EarlyContext, _: &ast::Pat) { }

Discussion:
For clippy's lint, I made use of a so I could stop clippy from linting the same macro multiple times while being reasonably fast. However, this unfortunately means the lint ignores .. attributes below the crate level. To solve this and other related problems, I propose any of allow a lint to check anything from anywhere in the analysis by moving up the parent chain to check the level allow a lint to opt out of calls for the duration of a specific node including its child nodes add methods to the {Early, Late}LintPass trait, so lints can decide themselves The third option is probably the easiest to implement, yet the most flexible. This would bring the trait closer to other stream parser implementations like SAX.
Seeing that we already have a few, _post methods, I think adding some more will be an acceptable solution here. I'll have a PR shortly.
Change:
#[multipart_suggestion( lint_addr_metadata_suggestion, style = "verbose", <del> applicability = "machine-applicable" </del> <ins> // FIXME(#53934): make machine-applicable again applicability = "maybe-incorrect" </ins> )] pub struct AmbiguousWidePointerComparisonsAddrMetadataSuggestion<'a> { pub ne: &'a str,

Discussion:
No response The lint is marked able but applying the suggestion fails: ` No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same problem with
claim
I think this is a known issue with with applying all suggestions even if they are multually exclusive. I'm pretty sure there's nothing to do in the lint, it correctly suggests the two (valid) suggestions, only one of them should be applied.
Well we can either remove one of the suggestions or make the lint MaybeIncorrect or something?
I think this is We can't remove one of the suggestions, they are both necessary. We can however make them for the time being.
That is indeed unfortunate.
Change:
/// } /// assert_eq!(buf, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]); /// ``` <del> #[unstable(feature = "vecdeque_rotate", issue = "56686")] </del> <ins> #[stable(feature = "vecdeque_rotate", since = "1.36.0")] </ins> pub fn rotate_right(&mut self, k: usize) { assert!(k <= self.len()); let mid = self.len() - k;

Discussion:
Currently if you want to rotate a VecDeque n elements to the left or right, you'd have to write something like this: I wonder if it would be possible to add 2 functions: rotateleft(mid: usize) rotateright(mid: usize) You then only have to write: This would be equal to slice's and . It could probably be implemented on a lower level than with pop's and pushes for a little more efficiency.
Ooh, I like this -- is a circular buffer internally, so it should be doable with at most two . EDIT: PR
PR is r+'d, so I turned this into a tracking issue.
I've since the feature replaced any code that used the pop - push technique with the rotate methods. This was fairly easy to do. It's been a few months now, are there any issue's preventing this from landing stable?
fcp 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:
Is "left" or "right" the word we want to use here? Previously we have deprecated () of in favor of and so that we do not assume the string is laid out from left to right. Here we seem to assume is to while is to ? Are we able to use some words that express the and without assuming a left-to-right layout?
As discussed here, we have to use those names to stay consistent with the slice rotate_{left |right} methods
, sorry I missed that. That makes sense.
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.
Change:
m_expr: ty::TypeAndMut<'tcx>, m_cast: ty::TypeAndMut<'tcx>, ) -> Result<CastKind, CastError> { <del> // array-ptr-cast. if m_expr.mutbl == hir::Mutability::Not && m_cast.mutbl == hir::Mutability::Not { </del> <ins> // array-ptr-cast: allow mut-to-mut, mut-to-const, const-to-const if m_expr.mutbl == hir::Mutability::Mut || m_cast.mutbl == hir::Mutability::Not { </ins> if let ty::Array(ety, _) = m_expr.ty.kind() { // Due to the limitations of LLVM global constants, // region pointers end up pointing at copies of

Discussion:
cc is this a coercion that's expected to work?
triage: I-nominated
The first cast is from to , the second is from to . I'm not actually sure if this is meant to work, I guess it should. The intention here is to give a way to treat arrays like C-arrays and get a pointer to the start of the array. It seems that if the array is mutable, then the pointer should be too. I recommend this is P-low - it is backwards compatible, rare, and just a bug by omission, really. The fix should be pretty easy though.
Ah I wasn't sure if this was intended, if it's actually intended then I don't mind removing the nomination as well!
I'm not sure how intended this is, but it doesn't seem too harmful. ;)
P-low, (perhaps "just a bug", perhaps a minor feature.)
Triage: no change
This still happens today (with ), but the error message is slightly different: is another -related issue.
Change:
tcx.ty_error().into() } else { // This is a default type parameter. <ins> let substs = substs.unwrap(); if substs.iter().any(|arg| match arg.unpack() { GenericArgKind::Type(ty) => ty.references_error(), _ => false, }) { // Avoid ICE #86756 when type error recovery goes awry. return tcx.ty_error().into(); } </ins> self.astconv .normalize_ty( self.span, tcx.at(self.span).type_of(param.def_id).subst_spanned( tcx, <del> substs.unwrap(), </del> <ins> substs, </ins> Some(self.span), ), )

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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Change:
return; } <del> // When initializing a local, record whether the *value* being // stored in it needs dropping, which it may not, even if its // type does, e.g. `None::<String>`. if let Place::Local(local) = *dest { if qualif.intersects(Qualif::NEEDS_DROP) { self.local_needs_drop[local] = Some(self.span); } } </del> match *dest { Place::Local(index) if self.mir.local_kind(index) == LocalKind::Temp => { debug!("store to temp {:?}", index);

Discussion:
These currently compile, even if they can be used from compile-time code to trigger a drop: cc
Change:
<ins> // edition: 2021 #![deny(dead_code)] pub fn foo() { let closure = || { fn a() {}   //~ ERROR function `a` is never used }; closure() } pub async fn async_foo() { const A: usize = 1; //~ ERROR constant `A` is never used } fn main() {} </ins>

Discussion:
I tried this code: I expected to see the warning: Instead no warning was reported by the compiler. Observed in nightly, 1.67. Seems like the warning was shown in 1.63 and stopped showing in 1.64.
Bisected to CI has expired so I couldn't automatically bisect further, but looks like a likely candidate
It looks like the issue is that dead code detection doesn't work inside closures and generators (which async functions use in their desugaring) This is denied by 1.63 but allowed on 1.64+. label +regression-from-stable-to-stable Here, the parent of the closure is so checking dead code is skipped.
WG-prioritization assigning priority (). label -I-prioritize +P-medium