jiebi/CodeConvo huggingface dataset:
Change:
// object (usually called `crtX.o), which then invokes initialization callbacks // of other runtime components (registered via yet another special image section). <ins> #![feature(no_core, lang_items)] </ins> #![crate_type="rlib"] <del> #![no_std] </del> <ins> #![no_core] </ins> #![allow(non_camel_case_types)] <ins> #[lang = "sized"] trait Sized {} #[lang = "sync"] trait Sync {} #[lang = "copy"] trait Copy {} impl<T> Sync for T {} </ins> #[cfg(all(target_os="windows", target_arch = "x86", target_env="gnu"))] pub mod eh_frames { #[no_mangle]

Discussion:
This looks weird. Isn't a .dll the right thing for this target? cc
Could you try passing ? Seems like may not be making its way to Cargo, or the shim is really messing up here (probably the latter)

Because that's what the old build system does: but rustbuild and rsbegin.o ends up being an ELF on linux: The fix should be simple in theory. You just have to pass to the in the code linked above. But then you run in problems with the order of the operations: " not found for $TARGET". cc
FWIW, trying to cross compile to i686-pc-windows-gnu I get this: Trying to cross compile to x86_64-pc-windows-gnu results in
Yeah not passing would do it, should be easy to add though! (I think that's all that's necessary)
Actually, the solution is the opposite. rustbuild is building these startup files for linux but it should compile them for windows hence the has to be .
Oh right sorry "it" there was "would cause this problem", we should indeed pass !
Change:
<ins> // Copyright 2016 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. struct RepeatMut<'a, T>(T, &'a ()); impl<'a, T: 'a> Iterator for RepeatMut<'a, T> { type Item = &'a mut T; fn next(&'a mut self) -> Option<Self::Item> //~^ ERROR method not compatible with trait //~| lifetime mismatch //~| NOTE expected type `fn(&mut RepeatMut<'a, T>) -> std::option::Option<&mut T>` //~| NOTE    found type `fn(&'a mut RepeatMut<'a, T>) -> std::option::Option<&mut T>` { //~^ NOTE the anonymous lifetime #1 defined on the body //~| NOTE ...does not necessarily outlive the lifetime 'a as defined on the body Some(&mut self.0) } } fn main() {} </ins>

Discussion:
Receiving info about MIR or some other intermediate form in a user error report. I tried this code which most likely has some lifetime issue that I am yet to resolve: I should have received information about the scope defined by some part of my code or if the issue is with auto-generated code then possibly no information about an internal scope. Instead, this happened: :
This seems to be more common than I first thought: Made a resulted in:
Issue exists in latest nightly as well.
Can confirm experiencing it. Smaller sample: Not an issue in current stable or beta, which reports rather than
Does this qualify as a regression?
Yes, though not the kind we'd do a point release for, IMO
should mark as such then :)
Here's another small one:
It took me a minute to figure out that this issue is about the error message & not the error. I've also been getting CallSiteScope and so on nonsense in my error output recently. This seems like a pretty serious regression in the usability of our error messages! My impression has been that this impacts just about every lifetime issue I've been getting recently, but I could be wrong. Could we get this fixed by next stable release? I disagree with that this isn't worth making a point release for (currently its only in nightly, so that's not an issue).
Nominated for consideration by the compiler team.
This appears to be in beta (testing on the playground). Super tiny repro: gives
Has nobody looked into this? I'll take a peek before the compiler meeting today. EDIT: Of course it was me who introduced this bug, or rather triggered sigh. EDIT2: Basically, after , any uses of are suspicious. I'll try to make a PR.
Fix is at , using reduction as the testcase for this issue.
triage: P-high We have a fix though =)
Change:
panic!() } <ins> fn unused_parens_around_block_return() -> u32 { let foo = { (5) //~ ERROR unnecessary parentheses around block return value }; (5) //~ ERROR unnecessary parentheses around block return value } </ins> trait Trait { fn test(&self); }

Discussion:
I'd be interested in handling this. Looking at , it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. ) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?
what sort of ambiguity do you mean? I'd expect a single lint on in your example (note that we about unused ).
To use your original example, Both and are , since they represent the implicit return at the end of a block. I was wondering if we'd care about the case, and if we did, if it made sense to treat it the same as . If you naively add a match arm to the visitor, you get the same diagnostic for both.
Yes, both and should be linted here.
Change:
<ins> trait Foo { fn err(&self) -> MissingType; //~^ ERROR cannot find type `MissingType` in this scope } impl Foo for i32 { fn err(&self) -> MissingType { //~^ ERROR cannot find type `MissingType` in this scope 0 } } fn coerce(x: &i32) -> &dyn Foo { x } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: async fn coroutine return type not an inference variable: impl Future<Output = &'b ()', 'error: internal compiler error: async fn coroutine return type not an inference variable: impl Future<Output = &'b ()' 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 [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in module [analysis] running analysis passes on this crate --
Also ices in Rust 2021 in case anybody was wondering. Further reduced:
(see below)
It's of course :upsidedownface:
fyi
Change:
fn test<T: Display>(t: T, recurse: bool) -> impl Display { let f = || { let i: u32 = test::<i32>(-1, false); <del> //~^ ERROR mismatched types </del> <ins> //~^ ERROR concrete type differs from previous defining opaque type use </ins> println!("{i}"); }; if recurse {

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
"checksum globset 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)" = "ef4feaabe24a0a658fd9cf4a9acf6ed284f045c77df0f49020ba3245cfb7b454" "checksum handlebars 0.32.4 (registry+https://github.com/rust-lang/crates.io-index)" = "d89ec99d1594f285d4590fc32bac5f75cdab383f1123d504d27862c644a807dd" "checksum handlebars 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d82e5750d8027a97b9640e3fefa66bbaf852a35228e1c90790efd13c4b09c166" <del> "checksum hashbrown 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "570178d5e4952010d138b0f1d581271ff3a02406d990f887d1e87e3d6e43b0ac" </del> <ins> "checksum hashbrown 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "9529213c67695ca2d146e6f263b7b72df8fa973368beadf767e8ed80c03f2f36" </ins> "checksum heck 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ea04fa3ead4e05e51a7c806fc07271fdbde4e246a6c6d1efd52e72230b771b82" "checksum hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)" = "805026a5d0141ffc30abb3be3173848ad46a1b1664fe632428479619a3644d77" "checksum home 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "80dff82fb58cfbbc617fb9a9184b010be0529201553cda50ad04372bc2333aff"

Discussion:
In 1.35, 's requires , but in 1.36-beta it requires . Both are auto-derived, so it must be a change in their internals. Obviously, is quite different than the old implementation. ! ! Ditto for . I'm not sure if there's any real impact in this, but it should be considered, and perhaps audit for other similar changes. cc as discussed on IRC.
This is fixed in hashbrown 0.4.0.
Shouldn't be fixed as well?
Since is actually based on , it derives the same constraints.
Ah, gotcha. Thanks! Sorry for the false alarm :).
I think it would be a good idea to add a run-pass to check that these auto-trait impls don't change again.
might make sense to add them as tests to most collections. , , etc. don't have tests for these either. I've made this error in some of my collections (changing some internal implementation detail and breaking users that rely on auto traits working "like before").
Change:
(true,  true)  => flt2dec::Sign::MinusPlusRaw, }; <del> let mut buf = [0; 1024]; // enough for f32 and f64 let mut parts = [flt2dec::Part::Zero(0); 16]; let formatted = if let Some(precision) = fmt.precision { flt2dec::to_exact_fixed_str(flt2dec::strategy::grisu::format_exact, *num, sign, precision, false, &mut buf, &mut parts) </del> <ins> if let Some(precision) = fmt.precision { float_to_decimal_common_exact(fmt, num, sign, precision) </ins> } else { <del> flt2dec::to_shortest_str(flt2dec::strategy::grisu::format_shortest, *num, sign, 0, false, &mut buf, &mut parts) }; fmt.pad_formatted_parts(&formatted) </del> <ins> float_to_decimal_common_shortest(fmt, num, sign) } } // Don't inline this so callers don't use the stack space this function // requires unless they have to. #[inline(never)] fn float_to_exponential_common_exact<T>(fmt: &mut Formatter, num: &T, sign: flt2dec::Sign, precision: usize, upper: bool) -> Result where T: flt2dec::DecodableFloat { unsafe { let mut buf: [u8; 1024] = mem::uninitialized(); // enough for f32 and f64 let mut parts: [flt2dec::Part; 7] = mem::uninitialized(); let formatted = flt2dec::to_exact_exp_str(flt2dec::strategy::grisu::format_exact, *num, sign, precision, upper, &mut buf, &mut parts); fmt.pad_formatted_parts(&formatted) } } // Don't inline this so callers that call both this and the above won't wind // up using the combined stack space of both functions in some cases. #[inline(never)] fn float_to_exponential_common_shortest<T>(fmt: &mut Formatter, num: &T, sign: flt2dec::Sign, upper: bool) -> Result where T: flt2dec::DecodableFloat { unsafe { // enough for f32 and f64 let mut buf: [u8; flt2dec::MAX_SIG_DIGITS] = mem::uninitialized(); let mut parts: [flt2dec::Part; 7] = mem::uninitialized(); let formatted = flt2dec::to_shortest_exp_str(flt2dec::strategy::grisu::format_shortest, *num, sign, (0, 0), upper, &mut buf, &mut parts); fmt.pad_formatted_parts(&formatted) } </ins> } // Common code of floating point LowerExp and UpperExp.

Discussion:
floattodecimalcommon in does this: let mut buf = [0; 1024]; let mut parts = [flt2dec::Part::Zero(0); 16]; and then passes buf and parts to flt2dec::toexactfixedstr or flt2dec::toshorteststr Looking at the docs for those functions at and the "parts" array needs to have length at least 5, right? And the "buf" array needs to be at least 800+ for the toexactfixedstr case but only 17 (MAXSIGDIGITS) for the toshorteststr case, afaict. Changing the toshorteststr case to not use the huge buffer would probably help out too. Also, it's not clear to me that the "buf" scratch buffer needs to be zero-initialized. Does it?
Note that I'm poking at this a bit.
I spun off the zeroing thing into because I have a fix for that... we may still want to make the stackframe here smaller, though.
Change:
use super::lazy::LazyKeyInner; use crate::cell::Cell; use crate::sys::thread_local_dtor::register_dtor; <del> use crate::{fmt, mem, panic}; </del> <ins> use crate::{fmt, mem, panic, ptr}; </ins> #[doc(hidden)] #[allow_internal_unstable(thread_local_internals, cfg_target_thread_local, thread_local)]

Discussion:
At , acquire a pointer of type from a shared reference , and subsequently, in the , we reinterpret as and use it as a mutable pointer At the method of the field requires as defined in The whole process can be that we use to acquire a and call a mutable method on that variable, which seems problematic.
The code is sound if it uses , and all the fields inside that type is covered by . It should use or instead of pointer-casting.
Edit: I think what I want to ask about is the following example, which is almost identical to the original question and passes miri's check:
No, you should not do that.
So this is what is happening in the standard library: There is a structure like ; In , is converted to and passed to ; In , is converted to , then is called. requires , so it is actually , which means that a is born from a . In the entire process, we haven’t touched on anything related to . And, I also believe that containing an is not a reason for to be treated differently.
Yes, should be and not .
I should clarify that my "should not" here is that it can potentially pass miri, but my understanding is that it is brittle and relying on the operational semantics being a certain way, rather than being a "necessarily true" interpretation of Rust's semantics. Programs which are slight modifications easily become unsound, and libstd unfortunately has slight modifications done to it all the time, so... aiui this code currently passes miri because we do run miri on libstd's tests, but is not what I would consider "durable".
( probably. )
Change:
| '5' | '6' | '7' | '8' | '9' ; ``` <ins> ##### Character literals </ins> A _character literal_ is a single Unicode character enclosed within two `U+0027` (single-quote) characters, with the exception of `U+0027` itself, which must be _escaped_ by a preceding U+005C character (``). <ins> ##### String literals </ins> A _string literal_ is a sequence of any Unicode characters enclosed within two `U+0022` (double-quote) characters, with the exception of `U+0022` itself, which must be _escaped_ by a preceding `U+005C` character (``), or a _raw string literal_. <ins> ##### Character escapes </ins> Some additional _escapes_ are available in either character or non-raw string literals. An escape starts with a `U+005C` (``) and continues with one of the following forms:

Discussion:
The doesn't document what escape sequences are valid if any. For example, documentation doesn't state whether this will match a newline as would be expected: It also doesn't specify what format these strings are supposed to be written in. Much of the documentation including many escape sequences are documented in the but it is difficult (slow) to parse as it is. I think it would be good to have it in or at least to make the reference more clear. More escape documentation is in (though it's not exactly related). For what it's worth, doesn't seem to document it either (at least, I couldn't find it). Below is my first shot at what it could look like. followed by any number (including zero) of 's followed by and closed in the reverse: A single ASCII character: A sequence of ASCII characters: Note: I'm not really familiar with all the string formats. I'm just to collect them together so they're more obvious. Does it make sense to collect them onto the  page? If so, I can probably submit a PR making something like this but I'm not sure where it should go.
Python , but in the language reference rather than the standard library documentation. Perhaps Rust’s escape sequences should be documented in the reference, where most other language-documenting features go.
Horizontal Tab, AKA t, ASCII/Unicode 9. See .
Oh, I completely misread this as 6 escapes (but it's 3 with their definitions). The .
I'm quite surprised to find that Rust doesn't have (i.e: 'backspace') built in to the language. Is there a particular reason for this?
asking on is a better place than on a three and a half year old issue.
Change:
// except according to those terms. #![forbid(non_snake_case)] <ins> //~^ NOTE `forbid` level set here </ins> <del> #[allow(non_snake_case)] //~ ERROR E0453 </del> <ins> #[allow(non_snake_case)] //~^ ERROR allow(non_snake_case) overruled by outer forbid(non_snake_case) //~| NOTE overruled by previous forbid </ins> fn main() { }

Discussion:
From: src/test/compile- E0453 needs a spanlabel and a spannote changed to a span_label, updating it from: To:
Change:
<ins> // Copyright 2018 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. // // Tests that automatic coercions from &mut T to *mut T // allow borrows of T to expire immediately - essentially, that // they work identically to 'foo as *mut T' #![feature(nll)] struct SelfReference { self_reference: *mut SelfReference, } impl SelfReference { fn set_self_ref(&mut self) { self.self_reference = self; } } fn main() {} </ins>

Discussion:
In , reported several NLL errors in dependencies of the servo crate. later minimized one of those errors into : which yields: Removing feature(nll) makes the code work, so probably this is an NLL bug.
I'd like to take a look at this.
Explicitly casting to fixes the issue: My guess is that there's an issue with the automatic coercion from to . I'll investigate further.
It turns out you can remove one layer of indirection and still get the same error:
Change:
error[E0308]: mismatched types <del> --> $DIR/tail-expr-as-potential-return.rs:7:9 </del> <ins> --> $DIR/tail-expr-as-potential-return.rs:28:9 </ins> | LL | /     if x { LL | |         Err(42) | |         ^^^^^^^ expected `()`, found enum `Result` <ins> LL | |                 //| HELP you might have meant to return this value </ins> LL | |     } | |_____- expected this to be `()` |

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like it does for the : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +D-papercut
I'm gonna try and take a shot at this. claim
Thanks for putting up a PR so quickly, label +AsyncAwait-Triaged +AsyncAwait-Polish
Change:
// if there are any file names remaining, they were moved on the fs. // our data must remain up to date, so it must be removed from issues.txt // do this automatically on bless, otherwise issue a tidy error <del> if bless && !remaining_issue_names.is_empty() { let issues_txt_header = r#" /* ============================================================ ⚠️⚠️⚠️NOTHING SHOULD EVER BE ADDED TO THIS LIST⚠️⚠️⚠️ ============================================================ */ [ "#; </del> <ins> if bless && (!remaining_issue_names.is_empty() || !is_sorted) { </ins> let tidy_src = root_path.join("src/tools/tidy/src"); // instead of overwriting the file, recreate it and use an "atomic rename" // so we don't bork things on panic or a contributor using Ctrl+C

Discussion:
1) modify some code of 2) run =for the first ~6 seconds, tidy is being built in parallel, but for the remaining ~1 minute and 9 seconds llvm is doing some sequential work. I'm not sure what takes so long, there must be one epic cgu that it is processing or something?
I wanted to check the problem but couldn't reproduce it locally.
! :thinking:
aha lol! it boils down to , an array of ~4K static &strs which is being inlined into the code it seems. When I cut the file down to just a handful of items, compilation time reduces to 7 seconds :upsidedownface: cc I guess?
Can you check if reduces this slowness?
It does indeed.
Ah, but if people give the tests meaningful names, it will reduce the build time. :relieved:
Change:
let (expected_name, actual_name, output, actual) = self.run_common(); if !output.is_empty() { <del> // If we can bless (meaning we have a file to write into and the `RUSTC_BLESS_TEST` // environment variable set), then we write into the file and return. if let Some(ref expected_file) = self.expected_file { if std::env::var("RUSTC_BLESS_TEST").is_ok() { println!("Blessing `{}`", expected_file.display()); fs::write(expected_file, actual); return; } </del> <ins> if self.maybe_bless_expected_file(&actual) { return; </ins> } panic!( "test failed: `{}` is different from `{}`nn{}",

Discussion:
While working on , I noticed that running an test with appears to succeed, but doesn't actually update the snapshot file(s). This seems to be a side-effect of . The test does successfully bless the temporary copy of the snapshot file in , but that has no effect on the original snapshot file in .
cc label +A-run-make T-bootstrap
Change:
use rustc_hir::def_id::{DefId, LocalDefId}; use rustc_hir::intravisit::{walk_generics, Visitor as _}; use rustc_hir::{GenericArg, GenericArgs, OpaqueTyOrigin}; <del> use rustc_infer::infer::{InferCtxt, InferOk, TyCtxtInferExt}; </del> <ins> use rustc_infer::infer::{InferCtxt, TyCtxtInferExt}; </ins> use rustc_infer::traits::ObligationCause; use rustc_middle::middle::stability::AllowUnstable; use rustc_middle::ty::GenericParamDefKind; use rustc_middle::ty::{ <del> self, Const, GenericArgKind, GenericArgsRef, IsSuggestable, Ty, TyCtxt, TypeVisitableExt, </del> <ins> self, Const, GenericArgKind, GenericArgsRef, IsSuggestable, ParamEnv, Ty, TyCtxt, TypeVisitableExt, </ins> }; use rustc_session::lint::builtin::AMBIGUOUS_ASSOCIATED_ITEMS; use rustc_span::edit_distance::find_best_match_for_name;

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ow, my bad! claim