jiebi/CodeConvo huggingface dataset:
Change:
/// Therefore this method is unsafe. #[inline] #[must_use] <del> #[stable(feature = "futures_api", since = "1.36.0")] </del> <ins> #[unstable(feature = "local_waker", issue = "118959")] </ins> #[rustc_const_unstable(feature = "const_waker", issue = "102012")] pub const unsafe fn from_raw(waker: RawWaker) -> LocalWaker { Self { waker }

Discussion:
The following code leaks memory: Miri error: The equivalent code with , so I think this is a bug. Cc
I guess this is not too surprising... has but has nothing like that.
Oh, that's may bad. I assumed that RawWaker handled ownership. I can push a PR today in the evening.
This leads to a miri-test-libstd failure every day, would be nice to get a fix soon. :)
Change:
// dependent alignment #[no_mangle] pub fn small_struct_alignment(x: Bytes) -> Bytes { <del> // CHECK: [[VAR:%[0-9]+]] = load i32, i32* %{{.*}}, align 1 </del> <ins> // CHECK: [[VAR:%[0-9]+]] = load {{(i32, )?}}i32* %{{.*}}, align 1 </ins> // CHECK: ret i32 [[VAR]] x }

Discussion:
Hrm, yeah, the IR format changed from 3.6 to 3.7. In this case, it's just the extra result type in the instructions. Making that optional by changing to something like should help with that. If you still have a build using LLVM 3.6 around, it'd be great if you could create a patch for this. If not, let me know and I'll create one this evening.
I will give it a try. I am not planning to switch to 3.7 right now as there is no official release yet.
This is fixed.
Change:
let mut f = std::fs::File::create(&path)?; f.write_all(PRELUDE.as_bytes())?; f.write_all(bindings.as_bytes())?; <ins> f.write_all(ARM_SHIM.as_bytes())?; </ins> Ok(()) }

Discussion:
In the WinAPI definitions have been replaced by windows-bindgen generated bindings. However, the project does not generate metadata for ARM32-specific items, hence the generated bindings lack a few types like and on this platform. It effectively breaks for Rust.
Unfortunately, 32-bit ARM is not being supported by Microsoft going forward. What we could do is insert our own definitions in , copied from before the changes.
Besides the issue with ARM, all UWP targets actually have problems with linkage as well. Previously the APIs forbidden on UWP are gated behind fine-grained conditional compilation flags, but it is no longer the case with generated ones. I got this when building the UWP app that links again a Rust staticlib. !
Iirc, the functions were never gated. But we loaded them lazily (and panicked if they didn't load). This did allow UWP targets to compile. No idea if they actually ran. I'm not sure who's responsible for these targets.
I think you are correct. I can reproduce the link errors with toolchain . Let me file another issue after I pinpoint the underlying problem.
Oh wait, as staticlib? You currently need to make sure to link all the libraries it depends on. You can get them using .
This will fail Windows App Cert Kit tests. !
In that case I'm surprised that lazy loading worked.
WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
for expr in &visitor.returns { if let Some(returned_ty) = typeck_results.node_type_opt(expr.hir_id) { let ty = self.resolve_vars_if_possible(returned_ty); <del> err.span_label(expr.span, &format!("this returned value is of type `{}`", ty)); </del> <ins> if ty.references_error() { // don't print out the [type error] here err.delay_as_bug(); } else { err.span_label( expr.span, &format!("this returned value is of type `{}`", ty), ); } </ins> } } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. 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: We shouldn't show here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
without
another one 
What ideal output would you suggest? Should we remove the suggestion line like:
Ideally we should be checking that the return type . If it's not suggestable, don't mention it.
claim
I actually believe that neither the E0029 nor the E0277 should have been emitted. I would check explicitly for and change the error to be (that way the error isn't printed out, but rustc will ICE if no other error is emitted, which should have happened).
The PR will prevent E0029 and E0277 from printing out after checking the type references.
Change:
/// See also [`DelayDm`](rustc_error_messages::DelayDm) and [`with_no_trimmed_paths!`]. // this is pub to be able to intra-doc-link it pub fn trimmed_def_paths(tcx: TyCtxt<'_>, (): ()) -> DefIdMap<Symbol> { <del> assert!(tcx.sess.opts.trimmed_def_paths); </del> // Trimming paths is expensive and not optimized, since we expect it to only be used for error // reporting. //

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. --what is weird, is that I when looking at the stacktrace, we don't seem to even reach clippy code before the crash, yet I didn't manage to reproduce this with standalone rustc :/ <!-- 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
cc just given the name of the issue
Change:
error[E0282]: type annotations needed <del> --> $DIR/concrete-impl.rs:13:5 </del> <ins> --> $DIR/concrete-impl.rs:14:5 </ins> | LL |     <Struct as Ambiguous<_>>::method(); <del> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `Self` declared on the trait `Ambiguous` </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `A` declared on the trait `Ambiguous` </ins> error[E0283]: type annotations needed <del> --> $DIR/concrete-impl.rs:13:5 </del> <ins> --> $DIR/concrete-impl.rs:14:5 </ins> | LL |     <Struct as Ambiguous<_>>::method(); <del> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `Self` declared on the trait `Ambiguous` </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type of the type parameter `A` declared on the trait `Ambiguous` </ins> | note: multiple `impl`s satisfying `Struct: Ambiguous<_>` found --> $DIR/concrete-impl.rs:9:1 | LL | impl Ambiguous<One> for Struct {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <ins> LL | </ins> LL | impl Ambiguous<Two> for Struct {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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. --: This was also tried on with on Rust Playground, with the same error. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsWithout the fully qualified path, see commented code, the error is . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized: Looking into this. claim label D-incorrect
Change:
<ins> #![feature(type_alias_impl_trait)] trait Static: 'static {} impl Static for () {} type Gal<T> = impl Static; fn _defining<T>() -> Gal<T> {} trait Callable<Arg> { type Output; } /// We can infer `<C as Callable<Arg>>::Output: 'static`, /// because we know `C: 'static` and `Arg: 'static`, fn box_str<C, Arg>(s: C::Output) -> Box<dyn AsRef<str> + 'static> where Arg: Static, C: ?Sized + Callable<Arg> + 'static, C::Output: AsRef<str>, { Box::new(s) } fn extend_lifetime(s: &str) -> Box<dyn AsRef<str> + 'static> { type MalformedTy = dyn for<'a> Callable<Gal<&'a ()>, Output = &'a str>; //~^ ERROR binding for associated type `Output` references lifetime `'a` box_str::<MalformedTy, _>(s) } fn main() { let extended = extend_lifetime(&String::from("hello")); println!("{}", extended.as_ref().as_ref()); } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --. Prior to , these types were rejected with this error: Currently, they're accepted. Based on the assumption that generic parameters on opaque type are not constrained (see Niko's comment ), I believe the previous behavior is correct. CC: label F-typealiasimpl_trait A-impl-trait T-compiler A-lifetimes
Out of curiosity, here's an exploit derived from . It type-checks but fails at monomorphization.
The above exploit is and should be easier to do with , where indirection through would not be necessary, so label I-unsound requires-nightly T-types
if the same code were written without lifetime params and used arguments instead, we'd see the same problem before , right?
Sorry, I've clearly missed the notification :sweat_smile:. I think you already know the answer given that you've just pushed a fix :).
Change:
Ok(t) => { // Parsed successfully, therefore most probably the code only // misses a separator. <del> let mut exp_span = self.sess.source_map().next_point(sp); if self.sess.source_map().is_multiline(exp_span) { exp_span = sp; } </del> expect_err .span_suggestion_short( <del> exp_span, </del> <ins> sp, </ins> &format!("missing `{}`", token_str), token_str, Applicability::MaybeIncorrect,

Discussion:
Was reported here : but still occurring. <!-- 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
Simpler repro: ()
I assume this repros for any non-ascii character, right? I tried with ü, ß, and , and I was able to repro.
Correct :) é was just the character my big fingers typed when I found that bug!
Assigning and removing as .20.E2.80.A6) in the prioritization working group.
This is a regression since modify labels: +regression-from-stable-to-stable
Change:
} } <del> fn macos_deployment_target() -> (u32, u32) { let deployment_target = env::var("MACOSX_DEPLOYMENT_TARGET").ok(); let version = deployment_target </del> <ins> fn deployment_target(var_name: &str) -> Option<(u32, u32)> { let deployment_target = env::var(var_name).ok(); deployment_target </ins> .as_ref() .and_then(|s| s.split_once('.')) <del> .and_then(|(a, b)| a.parse::<u32>().and_then(|a| b.parse::<u32>().map(|b| (a, b))).ok()); </del> <ins> .and_then(|(a, b)| a.parse::<u32>().and_then(|a| b.parse::<u32>().map(|b| (a, b))).ok()) } </ins> <del> version.unwrap_or((10, 7)) </del> <ins> fn macos_deployment_target() -> (u32, u32) { deployment_target("MACOSX_DEPLOYMENT_TARGET").unwrap_or((10, 7)) </ins> } pub fn macos_llvm_target(arch: &str) -> 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> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/impl-const-generic-struct.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ </ins>

Discussion:
produces: which is clearly incorrect.
What I believe is happening here is that is no longer treated as a parameter, because it's in brackets. It's a when it gets to rather than a parameter.
Change:
<ins> error[E0425]: cannot find value `missing_var` in this scope --> $DIR/issue-72839-error-overflow.rs:18:8 | LL |     if missing_var % 8 == 0 {} |        ^^^^^^^^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
Does not appear on Stable or Beta in the playground. () Errors: modify labels: +C-bug, A-diagnostics, D-verbose, E-needs-bisection, T-compiler Edit: nevermind the attempt of adding “regression-from-stable-to-nightly”, I didn’t fully read the description of that label, it doesn’t apply.
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
This can be reproduced outside the playground by adding to your . I suspect that this is caused by we now continue trait selection instead of bailing out when we see an error type. I think we'll want to re-add some kind of bail-out logic, but I'm not sure where the best place would be.
I can confirm regression at modify labels to -E-needs-bisection.
(This bug leaked into beta channel while waiting for PR to land, I think.)
Removing as this have been prioritized already.
This one is already on master and beta backported so closing it as fixed in both channels.
Change:
pub struct UnusedParens { with_self_ty_parens: bool, <ins> /// `1 as (i32) < 2` parses to ExprKind::Lt /// `1 as i32 < 2` parses to i32::<2[missing angle bracket] parens_in_cast_in_lt: Vec<ast::NodeId>, </ins> } impl UnusedParens { pub fn new() -> Self { <del> Self { with_self_ty_parens: false } </del> <ins> Self { with_self_ty_parens: false, parens_in_cast_in_lt: Vec::new() } </ins> } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. 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: The current output is: But with the suggestion applied the compiler displays an error with a different suggestion: <!-- The following is not always necessary. --Ideally the compiler should not output a warning and treat and as identical. <!-- 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. -- label D-incorrect A-suggestion-diagnostics <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think it's relate with and
It would be great if it could give since parenthesizing the expression instead avoids the potential "is that a tuple?" confusion of .
Duplicate of .
Change:
<ins> #![feature(c_variadic)] // Regression test that covers all 3 cases of https://github.com/rust-lang/rust/issues/130372 unsafe extern "C" fn test_va_copy(_: u64, mut ap: ...) {} pub fn main() { unsafe { test_va_copy(); //~^ ERROR this function takes at least 1 argument but 0 arguments were supplied } } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'', 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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 -- label +F-cvariadic +F-fndelegation <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
lol
Thanks! I will take a look. (I'm glad we the check!)
another one that does not need delegation I think
claim
Change:
= note: `#[deny(const_err)]` on by default error[E0080]: evaluation of constant expression failed <del> --> $DIR/issue-50814.rs:18:5 </del> <ins> --> $DIR/issue-50814.rs:17:5 </ins> | LL |     &Sum::<U8,U8>::MAX |     ^----------------- |      | |      referenced constant has errors <del> error: any use of this value will cause an error --> $DIR/issue-50814.rs:13:21 | LL |     const MAX: u8 = A::MAX + B::MAX; |     ----------------^^^^^^^^^^^^^^^- |                     | |                     attempt to add with overflow error: aborting due to 3 previous errors </del> <ins> error: aborting due to 2 previous errors </ins> For more information about this error, try `rustc --explain E0080`.

Discussion:
See https://travis- for failed build
Could you please provide a backtrace for the ICE?
cc
cc more const prop fallout?
Seems likely. I'll have some time tonight to look at it.
Minimal repro:
Cc me
Change:
{ fn for_variant(this: TyLayout<'tcx>, cx: &C, variant_index: VariantIdx) -> TyLayout<'tcx> { let details = match this.variants { <del> Variants::Single { index } if index == variant_index => this.details, </del> <ins> Variants::Single { index } // If all variants but one are uninhabited, the variant layout is the enum layout. if index == variant_index && // Don't confuse variants of uninhabited enums with the enum itself. // For more details see https://github.com/rust-lang/rust/issues/69763. this.fields != FieldPlacement::Union(0) => { this.details } </ins> Variants::Single { index } => { // Deny calling for_variant more than once for non-Single enums.

Discussion:
cc I suspect (but have not verified) that this would be fixed by a backport of
was merged in October, I don't think it's related
Does this need an mcve?
Yeah, but I think at this point a bisection might be more helpful since we're not yet sure what caused this.
Here's a somewhat small-ish MCVE: Haven't managed to remove mio yet, but that's just a matter of time ;) Note, that this doesn't depend on the feature. You can use as well.
Here's a "M"CVE without any dependencies: regression in nightly-2020-01-11 <details<summaryBacktrace</summary</details modify labels: -E-needs-bisection -E-needs-mcve
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-16 regressed nightly: nightly-2020-01-11 searched commits: from to regressed commit: source code: Reproduce bisection with: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryERROR BEFORE ICE REGRESSION</summary<p</p</details
It would be good to continue the bisection into the rollup PR, among the following PRs: (Point at opaque and closure type definitions in type errors) (Reduce special treatment for zsts) (Parse the syntax described in RFC 2632) (rustcastlowering: misc cleanup & rustc dep reductions) (Extend support of in type parameters) (expect after / )
triage: P-high, removing nomination, assigning to self.
Given the backtrace, I think it's probably (Reduce special treatment for zsts)
I can indeed reproduce the ICE at , seems to be the culprit. cc <details<summaryBacktrace</summary</details
Here is a more minimal MCVE: /me needs to invest some time in tools like rust-reduce or creduce...
Okay so now we have two different PR's to fix this. PR is almost certainly the right call for nightly itself. My only Question is whether we should also land PR and also then backport that to beta. My argument for why is that it is "obviously" less risky, which is important because the beta is going to be imminently promoted to stable.
Change:
<ins> error[E0310]: the parameter type `T` may not live long enough --> $DIR/issue-102117.rs:16:9 | LL | /         const { LL | | LL | | LL | |             &VTable { ...  | LL | |             } LL | |         } | |_________^ ...so that the type `T` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound... | LL |     pub fn new<T: 'static>() -> &'static Self { |                 +++++++++ error[E0310]: the parameter type `T` may not live long enough --> $DIR/issue-102117.rs:16:9 | LL | /         const { LL | | LL | | LL | |             &VTable { ...  | LL | |             } LL | |         } | |_________^ ...so that the type `T` will meet its required lifetime bounds | help: consider adding an explicit lifetime bound... | LL |     pub fn new<T: 'static>() -> &'static Self { |                 +++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0310`. </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. --: (latest nightly as of today) </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +F-inline_const
Note the missing bound. requires , and should throw a lifetime bounds error, but I think the inline const block is tripping something up. It works fine if you require or without the inline const block.
claim