jiebi/CodeConvo huggingface dataset:
Change:
//~^ ERROR casting references to a bigger memory layout } <ins> { let x: Box<dyn Send> = Box::new(0i32); let _z = unsafe { &*(&*x as *const dyn Send as *const i32) }; } </ins> unsafe fn from_ref(this: &i32) -> &i64 { &*(this as *const i32 as *const i64) }

Discussion:
I believe this code is well defined. It runs successfully in Miri with . However, since (nightly-2024-02-14), the following deny-by-default lint is triggered in : Rustc thinks the is 0 bytes, whereas for the purpose of the memory model as I understand it, it has a runtime size that is bigger than 0 bytes.
The here is the size reported at compile time, which obviously doesn't make sense with DST, the lint implementation should be gated on the types being sized. (to be honest, I completely forgot about this). There should probably be an somewhere after this
My code is also regressing in this: Gives the error on nightly This doesn't involve DST though. But the pattern is the same as we just go through a which shouldn't count as a dereference.
Your sample code is as far as I can tell UB and with the lint. <subIf you want to continue this conversation, let's create a new issue as to not diverge this specific issue.</sub
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
self.as_inner_mut().custom_flags(flags); self } <del> fn as_flags(&self) -> io::Result<libc::c_int> { self.as_inner().as_flags() } </del> } /// Unix-specific extensions to [`fs::Metadata`].

Discussion:
The following code compiles fine with nightly-2020-09-22 (and stable rustc since 1.10.0) but not nightly-2020-09-23. This is minimized from Mentioning , ,
Whoops, I didn't realize the trait itself was stable. Probably the PR should either be reverted or add a default implementation for .
Assigning P-critical as as part of the Prioritization Working Group procedure and removing I-prioritize.
is now broken on nightly as well:
I was under the impression that the traits were not intended to be implemented outside of which means this is really an issue with which shouldn't have implemented at all.  for example has had several methods to it since 1.0. Is there something different with or is this just that it was implemented by a popular crate?
The trait likely should have been , but I think sealed traits were not invented until after 1.0.0.
Can we retroactively seal ? It seems like we should, if we keep adding methods like in
Wouldn't that be a breaking change?
Yes, just like adding more methods to it (which has been done several times)
We could do a crater run to see if sealing it would break anything.
Well clearly it would - it would break async-std the same way broke async std. We need to get them not to use before we can change anything here.
My comment was in reference to sealing , not .
Change:
use rustc_hir::def::{DefKind, Res}; use rustc_middle::ty::print::RegionHighlightMode; use rustc_middle::ty::subst::{GenericArgKind, SubstsRef}; <del> use rustc_middle::ty::{self, RegionVid, Ty}; </del> <ins> use rustc_middle::ty::{self, DefIdTree, RegionVid, Ty}; </ins> use rustc_span::symbol::{kw, sym, Ident, Symbol}; use rustc_span::{Span, DUMMY_SP};

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
Changing Self{field} to MyStruct{field} makes it build btw.
I haven't done a search for the exact commit, but on the playground this regressed between beta and nightly. label +regression-from-stable-to-nightly
This is due to the NLL stabilization PR , since it manifests with on 1.61 (with to allow feature flags). I'll be looking at it in a few hours when I get home!
Change:
// Protect against infinite recursion, for example // `struct S(*mut S);`. <ins> // FIXME: A recursion limit is necessary as well, for irregular // recursive types. </ins> if !acc.cache.insert(ty) { return FfiSafe; } <del> // Additional recursion check for more complex types like // `struct A<T> { v: *const A<A<T>>, ... }` for which the // cache check above won't be enough (fixes #130310) if !tcx.recursion_limit().value_within_limit(acc.recursion_depth) { return FfiUnsafe { ty: acc.base_ty, reason: fluent::lint_improper_ctypes_recursion_limit_reached, help: None, }; } acc.recursion_depth += 1; </del> match *ty.kind() { ty::Adt(def, args) => { if let Some(boxed) = ty.boxed_ty()

Discussion:
The windows-rs crate is getting a whole bunch of spurious FFI-safe warnings: See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc which introduced the recursion limit.
Repro:
Anyways I'll put up a revert PR claim
Change:
/// /// # Examples /// <del> /// ## Calling a by-value closure /// /// ``` /// let x = 5; /// let square_x = move || x * x; /// assert_eq!(square_x(), 25); /// ``` /// </del> /// ## Using a `FnOnce` parameter /// /// ```

Discussion:
In the documentation for , there are two examples. The first is This is not a closure, as it never moves out of a variable in a way that would prevent it from calling again.
As a technical point, all closures are closures, because they may be called at least once. implies which implies . However, closures that modify their environment are only and (not ) and closures that move out of their environment are only .
Fair point. But as someone new to the documentation, I feel there's an implication in a few places (including the book, but unfortunately that section is frozen) that any closure is only and neither or , which isn't true.
Yes, it needs to be made more clear that those are totally orthogonal issues.
I personally think that the first example is better to be removed from the page, since (in my opinion) it causes more confusion then that it actually helps. I guess that most people looking up FnOnce already know a bit about closures and might already know about the syntax. The page also references the book on closures, so I don't think its necessary to provide an example for calling by-value. The second example also includes the calling by value part. I can imagine that users think the first example can only be called once (because they are on the FnOnce page), but this code also works: What do you think about this? I can pick this up if you agree.
Sounds good to me!
Change:
let y: Simd<u8, 2> = simd_shuffle(a, b, I2); assert_eq!(y.0, [1, 5]); } <ins> // Test that an indirection (via an unnamed constant) // through a const generic parameter also works. // See https://github.com/rust-lang/rust/issues/113500 for details. let a = Simd::<u8, 16>([0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]); let b = Simd::<u8, 16>([16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31]); unsafe { __shuffle_vector16::< { [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] }, Simd<u8, 16>, Simd<u8, 16>, >(a, b); } </ins> }

Discussion:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This might be related to cc
Reverting from to (before was merged) fixes the issue for me.
Change:
<ins> // Copyright 2014 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. fn main() { let mut x = Some(1); let mut p: proc(&mut Option<int>) = proc(_) {}; match x { Some(ref y) => { p = proc(z: &mut Option<int>) { *z = None; let _ = y; //~^ ERROR cannot capture variable of type `&int`, which does not fulfill `'static` }; } None => {} } p(&mut x); } </ins>

Discussion:
Example: The last statement is mutably borrowing x but x is already borrowed (or rather should be) by the proc. The result is a program that compiles fine but segfaults when run.
cc Nominating, closure shouldn't be able to capture borrowed variables.
I'm pretty sure the proc "code" needs a thorough review, giving this issue along with all the other similar proc bugs.
cc
P-backcompat-lang, 1.0.
Change:
#![allow(non_camel_case_types)] // ignore-emscripten <ins> // ignore-aarch64 FIXME: https://github.com/rust-lang/rust/issues/54510 </ins> // Test that the simd_reduce_{op} intrinsics produce the correct results.

Discussion:
Running on I get one failed test as shown below. This is the first time I've run the tests on this target some I'm unsure if it's a regression. Nightly commit CC ?
I think that's some flavor of On stdsimd/packedsimd we work around this by falling back to scalar code instead, so this shouldn't be used anywhere in the ecosystem on aarch64 anyways. The "fix" for this is to just ignore this test on aarch64.
Update: LLVM PR36796 is fixed.
It's not merged to Rust's LLVM fork.
How about now?
FWIW was released in LLVM 9 which rustc currently uses, so this ought to be fixed.
Seems like we need to add a test in that case.
No need for a new test, reverting (not ignoring that test on AArch64 any longer) should suffice. Although I'm not sure if we have CI for that target.
I'd suggest to wait for the LLVM 10 upgrade, which will address some additional issues. While LLVM 9 fixed the majority of this, there were still issues with ordered and non-fast reductions in some cases.
Triage: is already "reverted" in and we're on LLVM 10 now. I think there's nothing more we could do here? Closing.
Change:
<del> // Verify that we can pretty print invalid constant introduced // by constant propagation. Regression test for issue #93688. // // compile-flags: -Copt-level=0 -Zinline-mir </del> <ins> // Verify that we can pretty print invalid constants. </ins> #![feature(inline_const)] <del> #[inline(always)] pub fn f(x: Option<Option<()>>) -> Option<()> { match x { None => None, Some(y) => y, } } </del> <ins> #[derive(Copy, Clone)] #[repr(u32)] enum E { A, B, C } #[derive(Copy, Clone)] enum Empty {} </ins> // EMIT_MIR invalid_constant.main.ConstProp.diff fn main() { <del> f(None); union Union { </del> <ins> // An invalid char. union InvalidChar { </ins> int: u32, chr: char, } <del> let _invalid_char = const { Union { int: 0x110001 } }; </del> <ins> let _invalid_char = const { InvalidChar { int: 0x110001 } }; // An enum with an invalid tag. Regression test for #93688. union InvalidTag { int: u32, e: E, } let _invalid_tag = [InvalidTag { int: 4 }]; // An enum without variants. Regression test for #94073. union NoVariants { int: u32, empty: Empty, } let _enum_without_variants = [NoVariants { int: 0 }]; </ins> }

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched toolchains through Regression in which is my rollup :sweat_smile: : ... Maybe ? cc
Reduced: `
Thanks for report and test case. In , I removed the special case for enums without variants, expecting that now that we handle failure gracefully it would be caught there. Alas, in this specific case, the succeeds while returning a non-existing variant index.
Change:
<del> error: cannot specialize on `Binder(ProjectionPredicate(ProjectionTy { substs: [V], item_def_id: DefId(0:6 ~ repeated_projection_type[54ea]::Id::This) }, Ty((I,))), [])` --> $DIR/repeated_projection_type.rs:19:1 </del> <ins> error: cannot specialize on associated type `<V as Id>::This == (I,)` --> $DIR/repeated_projection_type.rs:19:15 </ins> | LL | impl<I, V: Id<This = (I,)>> X for V { <del> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |               ^^^^^^^^^^^ </ins> error: aborting due to previous error

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should not reference the debug format of an internal type <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. -- modify labels +F-specialization +A-specialization +requires-nightly
Change:
<del> Subproject commit b00ecbeb268ee97cef9fa9b2375e6f6cf0864db2 </del> <ins> Subproject commit d10eefc62284c40c5a95a2eed19fc1f414a5364d </ins>

Discussion:
It was notified on before
Note that this worked in 1.42, so this is a stable-to-stable regression.
This basically . We re-stabilized some of the avx512 features that were used by BLAKE3, but it seems that we missed rav1e.
Any chance you could prepare a fix? I think this is worth a stable point release.
Summarizing some discussions in the lang team meeting, regarding CPU feature naming: there are inconsistencies in feature naming between LLVM, GCC, GAS, and the Linux kernel, but we have a mild technical reason to defer to LLVM (doing otherwise requires renaming the feature). So let's defer to LLVM naming of CPU features, which doesn't tend to use underscores.
In I stabilized all remaining x86 features for feature detection. 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] [ ] 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.
Why wasn't this caught by the crater runs for 1.43? It builds stuff from github, no?
:bell: This is now entering its final comment period, as per the . :bell:
Hmm yeah there were compiling the asm files: <details</details
I looks like the assembler is too old and doesn't recognize the AVX-512 instructions
cc We missed a regression on crater because it had an old version of nasm, which caused the crate to fail to compile. It seems that nasm 2.14 is required for the AVX512 instruction used.
Hmm yeah that might be it. It Ubuntu 18.04 LTS which uses nasm 2.13. An update to 20.04 LTS will bring nasm 2.14 and probably fix the issue short term but not long term once rav1e starts requiring newer nasm versions.
(removing stable-nominated tag, as we nominate PR's for backport, not issues)
Change:
host: TargetSelection, target: TargetSelection, ) -> Compiler { <del> if self.build.force_use_stage2() { </del> <ins> if self.build.force_use_stage2(stage) { </ins> self.compiler(2, self.config.build) <del> } else if self.build.force_use_stage1(Compiler { stage, host }, target) { </del> <ins> } else if self.build.force_use_stage1(stage, target) { </ins> self.compiler(1, self.config.build) } else { self.compiler(stage, host)

Discussion:
With , and a empty folder, and running , I get the following error On , x86-64, linux. <details<summaryFull Log </summaryCC </detailsCC
is this a recent regression? are you able to bisect it?
off the top of my head, looks very fishy, that should never happem
I've locally bisected to , which contains this PR that sounds relevant:
Change:
let expr_exit = self.add_ast_node(id, &[]); // Keep track of the previous guard expressions <del> let mut prev_guards = Vec::new(); </del> <ins> let mut prev_guard = None; let match_scope = region::Scope { id, data: region::ScopeData::Node }; </ins> for arm in arms { // Add an exit node for when we've visited all the

Discussion:
ICE with the borrow checker on nightly. Tried on stable/beta and it correctly errors with in nightly, I get : Backtrace:
Reduced: cc
Bisected this one to and , that is, PR . cc
Change:
X86_64 => "core2", X86_64_macabi => "core2", Arm64_macabi => "apple-a12", <ins> Arm64_sim => "apple-a12", </ins> } .to_string() } fn link_env_remove(arch: Arch) -> Vec<String> { match arch { <del> Armv7 | Armv7s | Arm64 | I386 | X86_64 => vec!["MACOSX_DEPLOYMENT_TARGET".to_string()], </del> <ins> Armv7 | Armv7s | Arm64 | I386 | X86_64 | Arm64_sim => { vec!["MACOSX_DEPLOYMENT_TARGET".to_string()] } </ins> X86_64_macabi | Arm64_macabi => vec!["IPHONEOS_DEPLOYMENT_TARGET".to_string()], } }

Discussion:
Currently in our application we cannot run the iOS simulator on M1 machines because it is expecting architecture. Forcing using the target can build the project and ship the application but this targets the iOS Device SDK, and will not build in the simulator for testing with this error: should provide an target that uses the iOS Simulator SDK.
Is relevant at all? Can the same path be followed?
Awesome find I'll try doing this! If successful I'll open a similar PR :)
Ran into this now too. Happy to help here as well. Did you already get started?
I did but having trouble I've pushed my changes here: More than happy to work with you on this Jan!
I'll try to get a dev environment set up and then I'll take a look.
I built the toolchain successfully, but when I try to compile my project (with either or ) I'm getting: I think I've missed a setting in the build config I'm using, because the normal nightly compiles fine :( : Edit looks like I will try off :
Yeah, that looks like upstream breakage in because of recent changes. I can try taking your code tomorrow and throw this against my project to see if that fixes my simulator issues.
Yeah I the patch mentioned in that issue and am getting further but: which Xcode still seems to be getting x8664 somewhere: I tried replacing all the with and got closer: but got:
I believe my current version is working but there's something off in my Xcode project that I need to figure out:
Ah, you're building a binary? Yeah, that seems to sort-of work now? I managed to build your branch, my static library is still unchanged. I think we actually need LLVM 12 first to fully enable this ().
It was just a test to see if the simulator is working at all XD. Yeah my file is still saying it's :
Change:
<ins> // Test that Fn-family traits with lifetime parameters shouldn't compile and // we suggest the usage of higher-rank trait bounds instead. fn fa(_: impl Fn<'a>(&'a str) -> bool) {} //~^ ERROR `Fn` traits cannot take lifetime parameters fn fb(_: impl FnMut<'a, 'b>(&'a str, &'b str) -> bool) {} //~^ ERROR `Fn` traits cannot take lifetime parameters fn fc(_: impl std::fmt::Display + FnOnce<'a>(&'a str) -> bool + std::fmt::Debug) {} //~^ ERROR `Fn` traits cannot take lifetime parameters use std::ops::Fn as AliasedFn; fn fd(_: impl AliasedFn<'a>(&'a str) -> bool) {} //~^ ERROR `Fn` traits cannot take lifetime parameters fn fe<F>(_: F) where F: Fn<'a>(&'a str) -> bool {} //~^ ERROR `Fn` traits cannot take lifetime parameters fn main() {} </ins>

Discussion:
The following code: currently produces a heap of semi-helpful diagnostics: <details<summary<bstderr (7 errors)</b</summary</detailswhen instead we could special-case this and emit a single (or at least fewer) diagnostic that suggests the following: If the bound in not inside , like in: we currently emit the following: which is less verbose for sure but still, we should provide the same suggestion I propose above. Related issue: . label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing ping command in failed: ...'stbot ping' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I'd like to take a look. claim
I'm wondering if taking an approach that suggests using higher-rank trait bounds () for an Fn-family trait with a lifetime parameter. Is it appropriate? I'm concerned that it may not a comprehensive solution because HRTB can be used outside of the Fn-family traits (as I understand). Or is it okay only for the Fn-family traits for now?
I am not sure I fully understand what you mean. As you probably know, none of , , take a lifetime parameter and probably never will. Of course, you could define such a trait with unstable features but there is no way to use them, so it's not relevant: Yes, I'd say so. I wouldn't look for names however (like , , …) but just look for an opening parenthesis after a generic parameter list. This way, we can emit the same suggestion for the following case (where the name is ):
Ah, definitely. Thank you!
Change:
assert_eq!(last_event("{"a":1"),   Error(SyntaxError(EOFWhileParsingObject, 1, 7))); assert_eq!(last_event("{"a":1 1"), Error(SyntaxError(InvalidSyntax,         1, 8))); assert_eq!(last_event("{"a":1,"),  Error(SyntaxError(EOFWhileParsingObject, 1, 8))); <ins> assert_eq!(last_event("{"a":1,}"), Error(SyntaxError(TrailingComma, 1, 8))); </ins> assert_stream_equal( "{}",

Discussion:
Gives me:
That's because JSON doesn't allow for a trailing comma, I'd imagine.
The specification is clearly wrong here and the decoder should accept trailing commas.
Well, that's not how standards work.
Not sure what you mean by that. I'm not saying that the encoder should produce trailing commas.
There is some precedence for not allowing trailing commas: Go, Chromium, and Firefox reject such json. The specification is still wrong for not allowing them and I see no reason not to parse them.
sad but true. Please feel free to close the issue then.
We could, however, have a better error message.
It shouldn't fail, since it returns a containing possible parse errors.
Change:
// A tuple index may not have a suffix self.expect_no_suffix(sp, "tuple index", suf); <del> let dot_span = self.prev_span; hi = self.span; </del> <ins> let idx_span = self.span; </ins> self.bump(); let invalid_msg = "invalid tuple or struct index";

Discussion:
If a procedural macro generates an access to a named struct field like then the may be either defsite or callsite and it works either way. But if accessing an unnamed tuple struct field like then it only works if is call_site. I believe it should work either way in either case.
Sorry for the delay! Fixed in .