jiebi/CodeConvo huggingface dataset:
Change:
// If the trait has a single item (which wasn't matched by Levenshtein), suggest it let suggestion = self.get_single_associated_item(&path, &source, is_expected); <del> self.r.add_typo_suggestion(err, suggestion, ident_span); </del> <ins> if !self.r.add_typo_suggestion(err, suggestion, ident_span) { fallback = !self.let_binding_suggestion(err, ident_span); } </ins> } fallback }

Discussion:
As a python programmer, forgetting a in an assignment to a variable that didn't exist before is an easy mistake to make. () Rust sees two uses of an undefined variable here (E0425 twice): While the second one is fine, in the first case I would have really appreciated a sentence like this: This would helped me as a newcomer to the language, because it does an educated guess what the problem might be and tells me how to fix it. I think the hint should be if the value is assigned to (first error), but not if it is used as an argument (second error). I hope this is the right place and format to file this suggestion, I would appreciate hints if this is not the case. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is the right place, however you should use the "diagnostic" template when creating issues like this. Thanks for the issue though. label +T-compiler +A-diagnostics
claim
Change:
cc @{}, do you think you would have time to do the follow-up work? If so, that would be great! <del> cc @{}, the PR reviewer, and @rust-lang/compiler -- nominating for prioritization. </del> <ins> cc @{}, the PR reviewer, and nominating for compiler team prioritization. </ins> ''').format( relevant_pr_number, tool, status_description,

Discussion:
While it's important to keep on top of regressions to the toolstate, most of the time these issues are fixed quickly, by the author of the PR that caused the regression, or someone else. With GitHub notifications being difficult enough to keep up with as it is, being mentioned on every toolstate change issue is mostly noise. The issues are already tagged T-compiler and nominated, so I think additionally pinging everyone is unnecessary. I think it would be sensible to change: to: cc
I think that's a good idea!
I agree that the pings are rarely useful. Nominating is probably sufficient.
Change:
// (b) cast from an integer-like (including bool, char, enums). // In both cases we want the bits. let bits = self.force_bits(src.to_scalar()?, src.layout.size)?; <del> Ok(self.cast_from_int(bits, src.layout, dest_layout)?.into()) </del> <ins> Ok(self.cast_from_int_like(bits, src.layout, dest_layout)?.into()) </ins> } <del> fn cast_from_int( </del> <ins> fn cast_from_int_like( </ins> &self, v: u128, // raw bits src_layout: TyLayout<'tcx>,

Discussion:
Compiling this code on : results in ICE. Casting to anything smaller than /(, , , , , etc) also results in ICE. Casting to anything same size or larger(, , , , etc) works fine. Positive discriminant values also work fine. Version of rustc: (on rust playground) Compiler flags listed as used:
indicates that this was injected in Rust 1.40
Thanks for the report! Please always include the ICE message. This time, it seems to be
Change:
use cmp; use hash::{Hash, Hasher}; use iter::{Iterator, IteratorExt, ExactSizeIterator, count}; <del> use marker::{Copy, Sized, self}; </del> <ins> use marker::{Copy, Send, Sync, Sized, self}; </ins> use mem::{min_align_of, size_of}; use mem; use num::{Int, UnsignedInt}; use ops::{Deref, DerefMut, Drop}; use option::Option; use option::Option::{Some, None}; <del> use ptr::{Unique, PtrExt, copy_nonoverlapping_memory, zero_memory}; use ptr; </del> <ins> use ptr::{self, PtrExt, copy_nonoverlapping_memory, zero_memory}; </ins> use rt::heap::{allocate, deallocate}; use collections::hash_state::HashState;

Discussion:
This compiles, despite Rc<T: !Send. I'm guessing this is because RawTable only uses K and V with marker::CovariantType, and I guess that isn't enough for the negative-impl to propagate. I haven't checked which other collections might be unsafe.
It appears that this also isn't specifically related to trait bounds: cc
Ah, yeah. RawTable contains only a , which is of course always Send/Sync. It should presumably just contain a plain and impl Send/Sync conditionally?
Or we need a more rich marker type.
may be a good replacement for the current system as it could contain a marker of and for example. For now though a manual impl of and will probably be required. Should other collections with an unsafe representation also be audited?
I can say confidently this is the only problem case in collections. It's the only collection that uses basically a pointer.
ok cool, good to know!
Change:
let outlives_env = OutlivesEnvironment::new(param_env); infcx.process_registered_region_obligations(outlives_env.region_bound_pairs(), param_env); <del> let errors = infcx.resolve_regions(&outlives_env); if !errors.is_empty() { return false; } true </del> <ins> infcx.resolve_regions(&outlives_env).is_empty() </ins> } pub fn trait_ref_is_knowable<'tcx>(

Discussion:
into causes an internal compiler panic This causes an internal compiler error: This seems related to , except this is using
:
This is not specific to . The following produces the same kind of error.
modify labels: +regression-from-stable-to-stable The ICE happens on stable regardless of having the feature gate or not (the ICE does not requires a nightly compiler to reproduce)
Change:
Ok(ret) => written += ret as u64, Err(err) => { return match err.raw_os_error() { <del> Some(libc::ENOSYS | libc::EPERM) => { </del> <ins> Some(ENOSYS | EPERM) => { </ins> // syscall not supported (ENOSYS) // syscall is disallowed, e.g. by seccomp (EPERM) match mode {

Discussion:
While updating my code base from 1.49 to 1.50 we noticed a failures in a program that rebuilds files from small chunks. We are opening a file in append mode, one in read mode, and we stream one into the other (as for the snippet below). Testing this out confirmed that the error happens on the reader file when the writer is in append mode, whenever we use a / or not. If we load the whole file into a string and then use on the same data it works as intended, as does setting the file in write mode (while it becomes necessary to seek to the end). Checking what got shipped into 1.50 we suspect the probable culprit to be What we are guessing is that this change is using the syscall that doesn't support files in append mode even when the file is in append mode, triggering the Bad File Descriptor error I tried this code (): I expected to see this happen: the files to be concatenated Instead, this happened: returns Strace for the code snipped: Example that works with loading the file into a string before copy (): It most recently worked on: 1.49 50 : no backtrace <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-stable-regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
syscall326 is copyfilerange. And indeed, it has this error code overloading the more common meaning of EBADF. assign.
Error: Parsing assign command in failed: ...'ot assign.' ''... Please let know if you're having trouble with this bot.
claim
If you need a workaround for the moment you can do which should defeat the incorrect optimizations by going through a trait object so it can't see it's dealing with a file.
Nice, this is awesome. We will try this tomorrow which should allow to migrate our codebase to 1.50! Thanks a lot for the quick help on this..
Test out the workaround and it works, while we wait for the actual fix to come out, thanks a lot!

label +T-libs-impl +I-prioritize +regression-from-stable-to-stable +C-bug +O-linux workaround is available. fix needs review.
Assigning as discussed as part of the and removing . label -I-prioritize +P-critical
Not sure if this is related, but I have a smaller code which also fails with EBADF: Tested with Rust 1.41.1, stable, nightly on Debian 9 and Rust 1.41.1 on Debian 10. Also, the trick with doesn't work in this case.
Totally unrelated and not a bug. opens a file in write-only mode, then you try to read from it later. Use to create read-write files.
lol, just figured it out and wanted to post. Thanks anyway! It's still strange it's EBADF instead of EPERM.
Change:
<ins> // Regression test for issue #124031 // Checks that we don't ICE when the tail // of an ADT has a type error trait Trait { type RefTarget; } impl Trait for () {} //~^ ERROR not all trait items implemented, missing: `RefTarget` struct Other { data: <() as Trait>::RefTarget, } fn main() { unsafe { std::mem::transmute::<Option<()>, Option<&Other>>(None); } } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: SizeSkeleton::compute(&Other): layout errored (Unknown(Alias(Projection, AliasTy { args: [Other], defid: DefId(2:2049 ~ core[a6f4]::ptr::metadata::Pointee::Metadata) }))), yet tail is not a type parameter or a projection', 'error: internal compiler error: SizeSkeleton::compute(&Other): layout errored (Unknown(Alias(Projection, AliasTy { args: [Other], defid: DefId(2:2049 ~ core[a6f4]::ptr::metadata::Pointee::Metadata) }))), yet tail is not a type parameter or a projection' 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: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
that's true, it's a type error (should be a quick fix)
you may also enjoy this gem: (found somewhere else)
Ah, this ( ) one bisects to fyi ^^
claim
Change:
<del> error: unused doc comment --> $DIR/useless-comment.rs:9:1 | LL | /// foo | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rustdoc does not generate documentation for macro invocations | note: the lint level is defined here --> $DIR/useless-comment.rs:3:9 | LL | #![deny(unused_doc_comments)] |         ^^^^^^^^^^^^^^^^^^^ = help: to document an item produced by a macro, the macro must produce the documentation as part of its expansion error: unused doc comment --> $DIR/useless-comment.rs:32:5 | LL |     /// bar |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rustdoc does not generate documentation for macro invocations | = help: to document an item produced by a macro, the macro must produce the documentation as part of its expansion error: unused doc comment --> $DIR/useless-comment.rs:13:5 | LL |     /// a |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL |     let x = 12; |     ----------- rustdoc does not generate documentation for statements error: unused doc comment --> $DIR/useless-comment.rs:16:5 | LL | /     /// multi-line LL | |     /// doc comment LL | |     /// that is unused | |______________________^ LL | /     match x { LL | |         /// c LL | |         1 => {}, LL | |         _ => {} LL | |     } | |_____- rustdoc does not generate documentation for expressions error: unused doc comment --> $DIR/useless-comment.rs:20:9 | LL |         /// c |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL |         1 => {}, |         ------- rustdoc does not generate documentation for match arms error: unused doc comment --> $DIR/useless-comment.rs:25:5 | LL |     /// foo |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL |     unsafe {} |     --------- rustdoc does not generate documentation for expressions error: unused doc comment --> $DIR/useless-comment.rs:28:5 | LL |     #[doc = "foo"] |     ^^^^^^^^^^^^^^ LL |     #[doc = "bar"] LL |     3; |     - rustdoc does not generate documentation for expressions error: unused doc comment --> $DIR/useless-comment.rs:29:5 | LL |     #[doc = "bar"] |     ^^^^^^^^^^^^^^ LL |     3; |     - rustdoc does not generate documentation for expressions error: unused doc comment --> $DIR/useless-comment.rs:35:13 | LL |     let x = /** comment */ 47; |             ^^^^^^^^^^^^^^ -- rustdoc does not generate documentation for expressions error: unused doc comment --> $DIR/useless-comment.rs:37:5 | LL |       /// dox |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL | /     { LL | | LL | |     } | |_____- rustdoc does not generate documentation for expressions error: aborting due to 10 previous errors </del>

Discussion:
Other expressions work as expected: it reports just one error, for the whole sequence of doc comment lines. () Errors:
( is a rustc lint.)
True, but I as well since it's a rustdoc-related lint.
Change:
path: path.join("::").to_string(), desc: Escape(&shorter(item.doc_value())).to_string(), parent: parent, <ins> parent_idx: None, </ins> search_type: get_index_search_type(&item, parent_basename), }); }

Discussion:
E.g. doesn't show the crate.
ccing myself, will have a look at this in the next week or so.
cc me
Triage: searching for libc doesn't show libc.
Hmm, I deliberately removed the search-index entry in because it was .
Change:
/// A priority queue implemented with a binary heap. /// /// This will be a max-heap. <ins> /// /// It is a logic error for an item to be modified in such a way that the /// item's ordering relative to any other item, as determined by the `Ord` /// trait, changes while it is in the heap. This is normally only possible /// through `Cell`, `RefCell`, global state, I/O, or unsafe code. </ins> #[derive(Clone)] #[stable(feature = "rust1", since = "1.0.0")] pub struct BinaryHeap<T> {

Discussion:
Collections that perform lookups based on a given property (e.g. a hash or an ordering) can be put into an inconsistent state when the property changes while its corresponding item is in the collection. This is normally not a problem, because such collections (at least those in ) do not provide mutable access to the type from which the property is derived (keys in the case of maps, items in the case of sets), but types with interior mutability can induce this behavior in safe code: Output: This is obvious from the definition of interior mutability, but it's definitely a footgun. If the use of such keys cannot be prevented with the type system, the collections should at least document that the property must remain constant for the duration of the item's presence in the collection. For example, Java's contains the following note:
This is a dupe of , which was for reasons in the thread itself. I believe the gist of the conversion was that yes, this can happen. Our implementations should ensure that this does not cause memory unsafety, but otherwise these sorts of "odd assertions" are ok to happen as this should be quite a rare occurrence anyway.
I still think the collection documentation needs to identify this problem. On Friday, March 13, 2015, Alex Crichton wrote:
Hm good point! I've an appropriate tag.
I'm working on a patch to document this.
Change:
#[test] fn ipv6_properties() { <del> fn check(str_addr: &str, unspec: bool, loopback: bool, </del> <ins> fn check(str_addr: &str, octets: &[u8; 16], unspec: bool, loopback: bool, </ins> unique_local: bool, global: bool, u_link_local: bool, u_site_local: bool, u_global: bool, u_doc: bool, m_scope: Option<Ipv6MulticastScope>) { let ip: Ipv6Addr = str_addr.parse().unwrap(); assert_eq!(str_addr, ip.to_string()); <ins> assert_eq!(&ip.octets(), octets); assert_eq!(Ipv6Addr::from(*octets), ip); </ins> assert_eq!(ip.is_unspecified(), unspec); assert_eq!(ip.is_loopback(), loopback);

Discussion:
Tracking issue for First needs to be implemented, then go through an FCP! Looks like the is being implemented over at
This issue is now entering a cycle-long final comment period for stabilization
Discussed recently, the libs team decided to stabilize.
Change:
} else { return ControlFlow::Continue(()); } <ins> in_parent_alias_type = true; </ins> } }

Discussion:
I tried this code: I expected to see this happen: It compiles quickly. Instead, this happened: It takes 10s to complete. Bisected to cc
Why did you title this "is broken"? It just takes longer to compile, or is it broken some other way? I'll look into the upcoming week.
Sorry, it just takes longer to compile.
WG-prioritization assigning priority (). label -I-prioritize +P-medium -regression-untriaged
On my machine (Apple M2 Pro), this test currently takes about 30 seconds. But if I enable , the compiler appears to consume 100% CPU forever. I'm not sure whether it's actually stuck, or just taking an incredibly long time, but I've never seen it finish with debug assertions enabled.
If I apply , the test finishes in about 45 seconds with debug assertions enabled, and about 3 seconds with them disabled.
Change:
<ins> // edition:2018 // run-pass // ignore-emscripten no threads support use std::thread; use std::time::Duration; fn main() { let t1 = thread::spawn(|| { let sleep = Duration::new(0,100_000); for _ in 0..100 { println!("Parking1"); thread::park_timeout(sleep); } }); let t2 = thread::spawn(|| { let sleep = Duration::new(0,100_000); for _ in 0..100 { println!("Parking2"); thread::park_timeout(sleep); } }); t1.join().expect("Couldn't join thread 1"); t2.join().expect("Couldn't join thread 2"); } </ins>

Discussion:
I was trying to troubleshoot this issue: and eventually we figured out that on my machine parktimeout wasn't waking up. I wrote this simple test code which demonstrates the issue: Most of the time it will only print this: Every once in a while it will finish normally. This behavior happens on stable and nightly and I tried a handfull of stable versions all the way back to 1.12 and they all got stuck. Windows (both msvc and gnu appear to never get stuck (at least I couldn't reproduce the issue)). I was able to duplicate this an another mac as well (both running 10.14) If only a single thread is started (or the park happens on the main thread) then I can't reproduce. I'm on 10.14; uname:
This definitely seems broken. Here's dtruss output:
It's a deadlock on the ONCE here:
As a workaround, everything should work fine as long as you construct an at least once in your process before parking.
Doesn't seem to help :(
Oh right sorry, you actually have to subtract two Instants to force that Once to complete. If you instead do at the start of main, it prevents the deadlock.
Works perfectly now! Thanks!
Change:
let mut search_module = self.current_module; loop { // Look for trait children. <del> let mut search_in_module = |module: Module<'a>| module.for_each_child(|_, ns, binding| { if ns != TypeNS { return } let trait_def_id = match binding.def() { Some(Def::Trait(trait_def_id)) => trait_def_id, Some(..) | None => return, }; if self.trait_item_map.contains_key(&(name, trait_def_id)) { add_trait_info(&mut found_traits, trait_def_id, name); let trait_name = self.get_trait_name(trait_def_id); self.record_use(trait_name, TypeNS, binding); </del> <ins> let mut search_in_module = |module: Module<'a>| { let mut traits = module.traits.borrow_mut(); if traits.is_none() { let mut collected_traits = Vec::new(); module.for_each_child(|_, ns, binding| { if ns != TypeNS { return } if let Some(Def::Trait(_)) = binding.def() { collected_traits.push(binding); } }); *traits = Some(collected_traits.into_boxed_slice()); </ins> } <del> }); </del> <ins> for binding in traits.as_ref().unwrap().iter() { let trait_def_id = binding.def().unwrap().def_id(); if self.trait_item_map.contains_key(&(name, trait_def_id)) { add_trait_info(&mut found_traits, trait_def_id, name); let trait_name = self.get_trait_name(trait_def_id); self.record_use(trait_name, TypeNS, binding); } } }; </ins> search_in_module(search_module); match search_module.parent_link {

Discussion:
Before (on librustc): After (on same librustc): cc
The extra RAM usage seems to be because of the AST not getting freed after the early lint checks. Not sure if this is intentional.
The AST should definitely still get freed, nobody touched , so it's not intentional (unless something about the command line options has changed?)
The performance regression in looks like it was caused by . I'll work on a fix now. I'm not sure what caused the RAM increase.
Resolution used to take about 1 seconds a few months ago in winapi and now it takes 9 seconds.
I fixed the performance regression in .
Change:
self, bx: &mut Bx, llvtable: Bx::Value, <ins> ty: Ty<'tcx>, </ins> ) -> Bx::Value { // Load the data pointer from the object. debug!("get_int({:?}, {:?})", llvtable, self); let llty = bx.type_isize(); let ptr_size = bx.data_layout().pointer_size; <del> let ptr_align = bx.data_layout().pointer_align.abi; </del> let vtable_byte_offset = self.0 * ptr_size.bytes(); <del> let gep = bx.inbounds_ptradd(llvtable, bx.const_usize(vtable_byte_offset)); let ptr = bx.load(llty, gep, ptr_align); // VTable loads are invariant. bx.set_invariant_load(ptr); ptr </del> <ins> load_vtable(bx, llvtable, llty, vtable_byte_offset, ty, false) </ins> } } /// This takes a valid `self` receiver type and extracts the principal trait <del> /// ref of the type. fn expect_dyn_trait_in_self(ty: Ty<'_>) -> ty::PolyExistentialTraitRef<'_> { </del> <ins> /// ref of the type. Return `None` if there is no principal trait. fn dyn_trait_in_self(ty: Ty<'_>) -> Option<ty::PolyExistentialTraitRef<'_>> { </ins> for arg in ty.peel_refs().walk() { if let GenericArgKind::Type(ty) = arg.unpack() && let ty::Dynamic(data, _, _) = ty.kind() { <del> return data.principal().expect("expected principal trait object"); </del> <ins> return data.principal(); </ins> } }

Discussion:
<!-- [31mICE[0m: Rustc ./subtyping-impacts-selection-2.rs '-Zvirtual-function-elimination=true -Clto=true -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'expected principal trait object'', 'thread 'rustc' panicked at 'expected principal trait object'' File: /tmp/im/subtyping-impacts-selection-2.rs --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: --
Seems to be a duplicate of
Regression in nightly-2022-06-16 commit[0] 2022-06-14: Auto merge of - b-naber:transition-to-valtrees-in-type-system, r=lcnr commit[1] 2022-06-14: Auto merge of - flip1995:pk-vfe, r=nagisa commit[2] 2022-06-15: Auto merge of - compiler-errors:if-cond-and-block, r=oli-obk commit[3] 2022-06-15: Auto merge of - JohnTitor:rollup-rfg1a4s, r=JohnTitor commit[4] 2022-06-15: Auto merge of - nnethercote:rm-thread-local-IGNORED_ATTRIBUTES, r=michaelwoerister commit[5] 2022-06-15: Auto merge of - JohnTitor:rollup-c17vjdy, r=JohnTitor commit[6] 2022-06-15: Auto merge of - AzureMarker:feature/horizon-std, r=nagisa commit[7] 2022-06-15: Auto merge of - c410-f3r:assert-compiler, r=oli-obk commit[8] 2022-06-15: Auto merge of - sunfishcode:ownedfd-and-dup, r=joshtriplett looks like this has been broken eversince

This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized: