jiebi/CodeConvo huggingface dataset:
Change:
Successfully compiles on stable 1.35, fails on beta/pre 1.36.
First reported to FireFox ESR and shared on irlo here:
The impl for requires , but the one for requires .
is a possible fix.

Discussion:
use realstd::collections::CollectionAllocErr::*; use realstd::usize; <ins> // https://github.com/rust-lang/rust/issues/62301 fn _assert_hashmap_is_unwind_safe() { fn assert_unwind_safe<T: crate::panic::UnwindSafe>() {} assert_unwind_safe::<HashMap<(), crate::cell::UnsafeCell<()>>>(); } </ins> #[test] fn test_zero_capacities() { type HM = HashMap<i32, i32>;

use crate::any::Any; use crate::cell::UnsafeCell; <ins> use crate::collections; </ins> use crate::fmt; use crate::future::Future; use crate::pin::Pin;

#[stable(feature = "unwind_safe_atomic_refs", since = "1.14.0")] impl<T> RefUnwindSafe for atomic::AtomicPtr<T> {} <ins> // https://github.com/rust-lang/rust/issues/62301 #[stable(feature = "hashbrown", since = "1.36.0")] impl<K, V, S> UnwindSafe for collections::HashMap<K, V, S> where K: UnwindSafe, V: UnwindSafe, S: UnwindSafe {} </ins> #[stable(feature = "catch_unwind", since = "1.9.0")] impl<T> Deref for AssertUnwindSafe<T> { type Target = T;
Change:
Both Solaris 11 and recentish Illumos provide the same API. While libstd can't presume the existence of the symbol, it seems like using works sufficiently to set the thread name when necessary. While the implementation is different, the API is basically the same for the purposes of . The Linux implementation of will silently truncate the thread name, while the NetBSD (and I think, FreeBSD) will return an error. Since the implementation has no way to return an error right now, we need to choose between silent truncation or silent failure. Given the risk of mis-identification in truncation (it's likely that the unique part of the name is the end), it seems best to fail silently instead. On the plus side, this API has significantly more space than Linux's.

Discussion:
name.as_ptr() as *mut libc::c_void); } } <ins> #[cfg(target_os = "solaris")] pub fn set_name(name: &CStr) { weak! { fn pthread_setname_np( libc::pthread_t, *const libc::c_char ) -> libc::c_int } if let Some(f) = pthread_setname_np.get() { unsafe { f(libc::pthread_self(), name.as_ptr()); } } } </ins> #[cfg(any(target_env = "newlib", <del> target_os = "solaris", </del> target_os = "haiku", target_os = "l4re", target_os = "emscripten",
Change:
There are several bugs here, but they all stem from the same problem -- the stdlib doesn't handle correctly in a few places. causes most other flags to be ignored, so requiring a mode is a little bit weird. Really, should probably be handled as another mode. This one can be worked around pretty trivially (though it is a bit silly in my view), but unfortunately that's when you hit the next issue: This doesn't work with because file descriptors have which means that all s on them fail (this is a security feature). Rust proactively sets close-on-exec in many different places, which means that any method that ends up triggering an gives a spurrious . The most obvious problem is with but I'm sure there are plenty of other examples: Rust really should use because s are blocked on all descriptors (while works without issue).
It does: There's a fallback to support older kernels that you're probably running into:
I figured out the reason why was missing -- it's because of a bug in a kernel patch I'm writing (which I'm simultaneously writing a Rust library for). So the fact that the "let's try setting explicitly" path gets tripped is totally my fault. However, I would argue Rust still really shouldn't be using -- because it doesn't work for (or any file with ) while always works. This would just boil down to and removing it from the impl.
I just found another problem this causes -- will fail with on files because doesn't work on file descriptors: The patch to fix this issue is literally just: I can submit a PR for this if that would be acceptable?
Sure
PR is here: .
I still do not see any fix for Should I open an new issue for it?
Yeah, I forgot to write a fix for that. I can open a new issue for that...
Are you kidding me? Yesterday I looked at the function where I needed this again after a year. And today I get a notifications here. Do you want to claim that coincidence exists? SGTM

Discussion:
target_os = "emscripten", target_os = "fuchsia", target_os = "l4re", <ins> target_os = "linux", </ins> target_os = "haiku")))] pub fn set_cloexec(&self) -> io::Result<()> { unsafe {

target_os = "emscripten", target_os = "fuchsia", target_os = "l4re", <ins> target_os = "linux", </ins> target_os = "haiku"))] pub fn set_cloexec(&self) -> io::Result<()> { unsafe {
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
from
Looks like a bunch of tests are affected the same way:
Cc this is likely caused by your change, somehow.
Likely caused by a missing in function pointer validation. Should be fixed by
I merged branches with my branches in both the rust and miri repos and all the tests passed :D
triage: P-medium, removing nomination, already assigned to
Miri upstream CI passes now, but only because I disabled a bunch of tests. I felt that was the better alternative, compared to not being able to land any update in Miri until a fix happens on the rustc side. But this means we shouldn't update the in-tree Miri tool yet.
PR fixing things for Miri: Blocked on
Miri master got broken again, . Do you want to try to fix that?
I believe broke miri. Hopefully I get time to fix it?
Should be an easy fix by making Miri not use that trait explicitly. It's yours!
Hooray, landed! Looks like this is blocked on a serde regression now, judging from https://travis- EDIT: blocked on , actually.

Discussion:
<del> Subproject commit d2df509867fbbbd35730c90aef54a8e73b046cd6 </del> <ins> Subproject commit b5ddc94bf02c641e5acbb08ae742014f40347f10 </ins>
Change:
This is a tracking issue for implemented in
There are currently 2 unambiguous stable ways to convert a into a without additional inference constraints Also, at the moment works because there is only one trait implementation that can satisfy that call, but because and are it's possible for an external library to add an additional implementation that makes that ambiguous (). In a lot of cases where you need to convert into a you're likely to have inference available to guide the call as well, but not always.
Well there's also [] right? []:
Mmh but that takes a and wraps it into . I think with that context makes a lot of sense.
Shall we stabilize ? 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.
It seems like this is something that should be mentioned in the docs of , specifically as something that differentiates it from .
:bell: This is now entering its final comment period, as per the . :bell:
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. This will be merged soon.

Discussion:
/// This conversion does not allocate on the heap and happens in place. /// /// This is also available via [`From`]. <del> #[unstable(feature = "box_into_pin", issue = "62370")] </del> <ins> /// /// # Notes /// /// It's not recommended that crates add an impl like `From<Box<T>> for Pin<T>`, /// as it'll introduce an ambiguity when calling `Pin::from`. /// A demonstration of such a poor impl is shown below. /// /// ```compile_fail /// # use std::pin::Pin; /// struct Foo; // A type defined in this crate. /// impl From<Box<()>> for Pin<Foo> { ///     fn from(_: Box<()>) -> Pin<Foo> { ///         Pin::new(Foo) ///     } /// } /// /// let foo = Box::new(()); /// let bar = Pin::from(foo); /// ``` #[stable(feature = "box_into_pin", since = "1.63.0")] </ins> #[rustc_const_unstable(feature = "const_box", issue = "92521")] pub const fn into_pin(boxed: Self) -> Pin<Self> where A: 'static, { // It's not possible to move or replace the insides of a `Pin<Box<T>>` <del> // when `T: !Unpin`,  so it's safe to pin it directly without any </del> <ins> // when `T: !Unpin`, so it's safe to pin it directly without any </ins> // additional requirements. unsafe { Pin::new_unchecked(boxed) } }
Change:
As of rustc 1.39.0-nightly ( 2019-09-15) it gives an ICE with the following message: error: internal compiler error: const parameter (Const { ty: usize, val: Param(N/) }/0) out of range when substituting substs=[] Which is the same ICE currently gives.
The ICE is now again the out of bound access on nightly. Another instance:
I believe this is essentially due to the following not working:

Discussion:
use crate::util::common::ErrorReported; use rustc::middle::lang_items; <ins> use rustc::mir::interpret::ErrorHandled; </ins> use rustc::ty; use rustc::ty::adjustment::{Adjust, Adjustment, AllowTwoPhase, AutoBorrow, AutoBorrowMutability}; use rustc::ty::Ty;

}; if element_ty.references_error() { <del> tcx.types.err } else if let Ok(count) = count { tcx.mk_ty(ty::Array(t, count)) } else { tcx.types.err </del> <ins> return tcx.types.err; } match count { Ok(count) => tcx.mk_ty(ty::Array(t, count)), Err(ErrorHandled::TooGeneric) => { self.tcx.sess.span_err( tcx.def_span(count_def_id), "array lengths can't depend on generic parameters", ); tcx.types.err } Err(ErrorHandled::Reported) => tcx.types.err, </ins> } }

<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn foo<const N: usize>() { let _ = [0u64; N + 1]; //~^ ERROR array lengths can't depend on generic parameters } fn main() {} </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-62456.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error: array lengths can't depend on generic parameters --> $DIR/issue-62456.rs:5:20 | LL |     let _ = [0u64; N + 1]; |                    ^^^^^ error: aborting due to previous error </ins>

fn main() { let _ = [0; B::VALUE]; <ins> //~^ ERROR array lengths can't depend on generic parameters </ins> }

LL | impl TraitB for B { | ^^^^^^^^^^^^^^^^^ missing `MyA` in implementation <del> error: aborting due to 2 previous errors </del> <ins> error: array lengths can't depend on generic parameters --> $DIR/issue-69602-type-err-during-codegen-ice.rs:21:17 | LL |     let _ = [0; B::VALUE]; |                 ^^^^^^^^ error: aborting due to 3 previous errors </ins> Some errors have detailed explanations: E0046, E0437. For more information about an error, try `rustc --explain E0046`.
Change:
In the implementation of , we find: (And similarly in with .) Note the comment: Is this actually true, even for instantiations where happens to be ? Does the language guarantee that there exist no type such that the fields of would be re-ordered? Or do we need to add to and ? CC
If this were user-facing code it would be a clear case of "no that's not specified, don't assume that". However, I believe rustc does currently honor this assumption and libstd can of course rely on rustc implementation details. would know best. Note that because unsizing happens with "reorganizing" the struct, the struct with a sized T has to be laid out "as if unsized" from the start. For example, and and many other can all be casted to without touching the , the differences in layout between those are quite constrained (limited to different amounts of paddding to respect alignment, I think?). This reasoning wouldn't apply if there was a type that couldn't ever be involved in unsizing, but I don't think the compiler can ever realistically rule that out locally, and I'm rather certain that it doesn't today.
Ah that’s a good point. The constraint that layout cannot change while unsizing is probably enough indeed.
We should probably add a comment to that effect so "don't assume that" is clearer to everyone.
We should! See
FWIW these are nowadays so this got properly fixed at some point.

Discussion:
unsafe fn data_offset<T: ?Sized>(ptr: *const T) -> isize { // Align the unsized value to the end of the `RcBox`. // Because it is ?Sized, it will always be the last field in memory. <ins> // Note: This is a detail of the current implementation of the compiler, // and is not a guaranteed language detail. Do not rely on it outside of std. </ins> data_offset_align(align_of_val(&*ptr)) }

unsafe fn data_offset<T: ?Sized>(ptr: *const T) -> isize { // Align the unsized value to the end of the `ArcInner`. // Because it is `?Sized`, it will always be the last field in memory. <ins> // Note: This is a detail of the current implementation of the compiler, // and is not a guaranteed language detail. Do not rely on it outside of std. </ins> data_offset_align(align_of_val(&*ptr)) }
Change:
I see the following error on the and channels, but not on : Found with the help of .
triage: P-high, because errors being swallowed, even in the presence of other errors, scares me a bit.
Perhaps might be a good candidate to investigate?
The error that is not being emitted is ~Looking.~ Found, incoming PR shortly.

Discussion:
} else if self.look_ahead(1, |t| *t == token::OpenDelim(token::Paren)) { let ident = self.parse_ident().unwrap(); self.bump();  // `(` <del> let kw_name = if let Ok(Some(_)) = self.parse_self_arg_with_attrs() { "method" } else { "function" </del> <ins> let kw_name = match self.parse_self_arg_with_attrs() { Ok(Some(_)) => "method", Ok(None) => "function", Err(mut err) => { err.cancel(); "function" } </ins> }; self.consume_block(token::Paren); let (kw, kw_name, ambiguous) = if self.check(&token::RArrow) {

<ins> pub t(# //~^ ERROR missing `fn` or `struct` for function or struct definition //~ ERROR this file contains an un-closed delimiter </ins>

<ins> error: this file contains an un-closed delimiter --> $DIR/issue-62546.rs:3:53 | LL | pub t(# |      - un-closed delimiter LL | LL | |                                                     ^ error: missing `fn` or `struct` for function or struct definition --> $DIR/issue-62546.rs:1:4 | LL | pub t(# | ---^- help: if you meant to call a macro, try: `t!` error: aborting due to 2 previous errors </ins>
Change:
This simple code should not trigger any error, except a leak of course. But miri report an error before: First, I suspected a miri bug but look like the code of could be the problem, I don't really understand the code of the . Is this code correct and it's a miri bug or the code is incorrect ? as you write the code maybe you want be ping.
/cc
The code in question:
Should be ok for me but it's still trigger miri
On a first glance this looks like an issue I have seen before, where the problem is that is a normal function call. So the creates a raw pointer and reads from it, but then the original pointer gets used again, which invalidates the raw pointer. So this is basically the same as
What about:
That's basically a transmute, but with even fewer compiler-level checks. At that point I'd just recommend transmuting to .
Isn't transmuting to always valid?
There's in fact a safe method for it, called . ;) But my suggestion does not involve .
While using + comment seems like the better option in the interim, my long-term preference here would be to just remove the check that doesn't let you destructure -implementing types as discussed in
This leads to 's suggestion, which seems to trigger Miri nevertheless. This indeed solves the problem here, but I was wondering about the more general pattern (See ): what if, for instance, had a second non ZST field: needing to extract an unaliased pointer from a struct implementing is actually not that easy to do soundly, once it entirely is not doable; _ Another idea (again, considering that may contain a second field that prevents it from being transmuted into the return value directly):
would be more appropriate than as it more correctly documents what you're doing. Also both and use internally.
So we have 2 clean solutions that doesn't trigger miri what do we pick ?

Discussion:
/// /// [`Drop`]: ../ops/trait.Drop.html fn into_inner(self) -> Box<[u8]> { <del> unsafe { let result = ptr::read(&self.inner); mem::forget(self); result } </del> <ins> // Rationale: `mem::forget(self)` invalidates the previous call to `ptr::read(&self.inner)` // so we use `ManuallyDrop` to ensure `self` is not dropped. // Then we can return the box directly without invalidating it. // See https://github.com/rust-lang/rust/issues/62553. let this = mem::ManuallyDrop::new(self); unsafe { ptr::read(&this.inner) } </ins> } }
Change:
produces: It would be nice if it produced a suggestion to split it up: (This , but was broken in a previous change.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi I'd like to try this one. Just found the removed suggestion.
claim
assign Hmm, triagebot is not well...
It doesn't look like you're still working on this. Is it ok if I take over?
Sure. Thanks for your help.

Discussion:
self.err_dotdotdot_syntax(self.token.span); } <ins> if self.token == token::LArrow { self.err_larrow_operator(self.token.span); } </ins> self.bump(); if op.is_comparison() { self.check_no_chained_comparison(&lhs, &op);

.emit(); } <ins> fn err_larrow_operator(&self, span: Span) { self.struct_span_err( span, "unexpected token: `<-`" ).span_suggestion( span, "if you meant to write a comparison against a negative value, add a  space in between `<` and `-`", "< -".to_string(), Applicability::MaybeIncorrect ).emit(); } </ins> fn mk_assign_op(&self, binop: BinOp, lhs: P<Expr>, rhs: P<Expr>) -> ExprKind { ExprKind::AssignOp(binop, lhs, rhs) }

// DotDotDot is no longer supported, but we need some way to display the error token::DotDotDot => Some(DotDotEq), token::Colon => Some(Colon), <ins> // `<-` should probably be `< -` token::LArrow => Some(Less), </ins> _ if t.is_keyword(kw::As) => Some(As), _ => None }

fn foo() { let (x, y) = (0, 0); <del> x <- y; //~ ERROR expected one of </del> <ins> x <- y; //~ ERROR unexpected token: `<-` </ins> } fn main() {

<del> error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `<-` </del> <ins> error: unexpected token: `<-` </ins> --> $DIR/bad.rs:5:7 | LL |     x <- y; <del> |       ^^ expected one of 8 possible tokens here </del> <ins> |       ^^ help: if you meant to write a comparison against a negative value, add a space in between `<` and `-` | LL |     x < - y; |       ^^^ </ins> error: expected expression, found keyword `in` --> $DIR/bad.rs:10:5

fn main() { let x = -5; <del> if x<-1 { //~ ERROR expected `{`, found `<-` </del> <ins> if x<-1 { //~ ERROR unexpected token: `<-` </ins> println!("ok"); } }

<del> error: expected `{`, found `<-` </del> <ins> error: unexpected token: `<-` </ins> --> $DIR/placement-syntax.rs:3:9 | LL |     if x<-1 { <del> |     --  ^^ expected `{` |     | |     this `if` statement has a condition, but no block </del> <ins> |         ^^ help: if you meant to write a comparison against a negative value, add a space in between `<` and `-` | LL |     if x< -1 { |         ^^^ </ins> error: aborting due to previous error
Change:
I just ran into this ICE: I can't share the code but here are some observations: The ICE occurs in debug mode as well. It does not occur when running . It does not* occur on my MacBook (same nightly, different architecture). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Can you try to isolate the code, e.g. produce some code (not longer than 50 lines) that reproduces this issue?
I have no idea where to even start. Maybe a  run will help.
How big is the code? You could start by removing 'mod xxx' in your Remove types that are not needed. Then if you only have a few files left, merge them into one and remove more things (e.g. not needed functions, structs, enums), try to replace macros with their actual content.
Using I have determined that the ICE started to appear with (). I'll try to isolate the code now.
i'm hitting this too, will see if i can make a small repro. building for target from a linux x86_64 host.
My project doesn't build for ARM even with , which casts doubt on the above rollup merge containing the cause, I think. (Also possible that there are two similar bugs introduced at different times.) I'll try to bisect.
My bisect indicates the regression was introduced in . Armed with this clue I'm trying to figure out which part of my (giant) project is triggering it in order to make a repro.
I've narrowed down the block of code that triggers the regression, and simplified it to the extent possible, but when extracted from the project it no longer causes rustc to panic. In case it's useful: If the line with the arrow is commented out, the code compiles. Uncommented, it fails with: Will update if I have any success producing a standalone reproduction.
OK, I managed to extract a standalone reproduction:
cc
I a comment in the repo; you can make it build or fail to build by just reversing the order of two lines of code.
I updated the repo by folding a minimised implementation of into it rather than depending on the crate, since seemed to be necessary to trigger the bug. In doing so I updated to std::future and the ICE disappeared. Adding to round-trip the future through a 0.1 Future brings the ICE back. (see comments in )
claim
Thanks for reporting this! Fix should be landing soon.

Discussion:
Ok(variant) }).collect::<Result<IndexVec<VariantIdx, _>, _>>()?; <ins> size = size.align_to(align.abi); </ins> let abi = if prefix.abi.is_uninhabited() || variants.iter().all(|v| v.abi.is_uninhabited()) { Abi::Uninhabited

<ins> // This test created a generator whose size was not rounded to a multiple of its // alignment. This caused an assertion error in codegen. // build-pass // edition:2018 #![feature(async_await)] async fn noop() {} async fn foo() { // This suspend should be the largest variant. { let x = [0u8; 17]; noop().await; println!("{:?}", x); } // Add one variant that's aligned to 8 bytes. { let x = 0u64; noop().await; println!("{:?}", x); } } fn main() { let _ = foo(); } </ins>
Change:
returned the containing all the information. Now you should access them via the methods provided by the trait, e.g. ,  etc.
Thanks for explanation. But I think the deprecated message is misleading.
PRs to change the wording would likely be accepted, but nothing better comes to mind right now. It seems pretty straightforward to me what the deprecation means.

Discussion:
/// } /// ``` #[stable(feature = "metadata_ext", since = "1.1.0")] <del> #[rustc_deprecated(since = "1.8.0", reason = "deprecated in favor of the accessor  methods of this trait")] </del> <ins> #[rustc_deprecated( since = "1.8.0", reason = "other methods of this trait are now prefered" )] </ins> #[allow(deprecated)] fn as_raw_stat(&self) -> &raw::stat;