jiebi/CodeConvo huggingface dataset:
Change:
<del> use rustc_infer::infer::TyCtxtInferExt; </del> <ins> use rustc_infer::infer::{DefiningAnchor, TyCtxtInferExt}; </ins> use rustc_middle::ty::query::Providers; use rustc_middle::ty::{ParamEnvAnd, TyCtxt}; use rustc_span::source_map::DUMMY_SP;

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. -- Regressed between ( 2022-07-17) .. ( 2022-07-21). ~Probably ~. Cc Edit: Regressed in Minimized from . Cc label regression-from-stable-to-nightly A-impl-trait <!-- 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 --
Duplicate of
No wait, huh? That's another issue
This must've been broken before. That revert should not be able to cause a stable to nightly regression
I was wrong, bisection points to . I guess it is . Cc
claim
Change:
dir: RelationDir) -> RelateResult<'tcx, Generalization<'tcx>> { <ins> debug!("generalize(ty={:?}, for_vid={:?}, dir={:?}", ty, for_vid, dir); </ins> // Determine the ambient variance within which `ty` appears. // The surrounding equation is: //

Discussion:
When using the nightly with the bugfix for the problems with , this error happens when trying to document the crate: note: rustc 1.31.0-nightly ( 2018-10-01) running on x86_64-apple-darwin
cc: FYI
it seemed to document fine for me on the most recent nightly build
This is fixed as of
Closing then! Thanks! :D
Will this need backporting at all?
Change:
force_rerun: matches.opt_present("force-rerun"), target_cfg: LazyCell::new(), <ins> nocapture: matches.opt_present("nocapture"), </ins> } }

Discussion:
passes fails On recent master (commit ), with to avoid building LLVM: Extra spin/Side note: Contrary to the above, with , both and pass well: and . All the same when invoking with instead of . Also discussed at https://rust- <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think is not actually passing through to libtest, it's just acting as a filter on the tests (like would). looks like today the only way to configure this is through an env variable: changing that to accept seems useful
claim
Wow. Thank you.
Change:
impl<'tcx> From<EvalErrorKind<'tcx>> for EvalError<'tcx> { fn from(kind: EvalErrorKind<'tcx>) -> Self { <del> let backtrace = match env::var("RUST_BACKTRACE") { </del> <ins> let backtrace = match env::var("MIRI_BACKTRACE") { </ins> Ok(ref val) if !val.is_empty() => Some(Backtrace::new_unresolved()), _ => None };

Discussion:
After a while I have noticed that compilation wasn't going to stop. And I see 3 rustc processes with However, after 15 minutes I saw one more process with And 9 minutes after there was another process. So, it looks like compilation is not infinite per se, it just tooks way more time to finish. (P.S. It took 28 minutes to fall with "can't find crate for "). For example, rustc has the following stack of a thread that burns CPU:
cc
Thanks for the bug report,
Strangely enough looks like it happens only on Windows (both msvc and gnu).
Just to clarify: building the dependencies for the crate failing with the above error took 28 minutes. The final crate errors immediately. So it's not const eval related just because it mentions . It is const eval related though ;) And the issue is most likely backtrace generation. Is it possible generating backtraces takes a long time on windows? Every const eval error generates a backtrace. I think we can safely assume noone needs those except for someone debugging miri. The backtraces are also an issue for FreeBSD. I don't want to remove them because they are super helpful for miri debugging, but since they obviously have a negative effect, I'll add a check to only generate them if explicitly requested.
triage: P-high

Bisecting it seems to be an issue with . It appears this may be a double crash? Like it's hitting some error and then unwinding improperly and crashing again. Not familiar enough with the traces to know.
The root error seems to be a crash from - everything else is a result of that.
The issue is with the crate. Miri's errors generate a true backtrace (not const eval backtrace, but from within the compiler). cc You can work around this issue for now by not passing () Not sure what the correct course of action is here (except for fixing on FreeBSD of course, but I can't do that). Should we simply not generate backtraces on bsd?
Ah this is unfortunate :( But yeah the "best" solution for now is probably to avoid backtrace generation on freebsd
should that be disabled in rustc or in the backtrace crate?
Either's fine by me, but I'd probably recommend rustc
I prefer the backtrace crate. There is a lot of code that depends on and will fail on these platforms anyways. If doesn't support some platform, it should probably, silently, just write backtraces that state "platform not supported" or similar instead of crashing or failing to compile.
Change:
///     Some(&12345), /// ); /// ``` <ins> /// /// You can use `OnceLock` to implement a type that requires "append-only" logic: /// /// ``` /// use std::sync::{OnceLock, atomic::{AtomicU32, Ordering}}; /// use std::thread; /// /// struct OnceList<T> { ///     data: OnceLock<T>, ///     next: OnceLock<Box<OnceList<T>>>, /// } /// impl<T> OnceList<T> { ///     const fn new() -> OnceList<T> { ///         OnceList { data: OnceLock::new(), next: OnceLock::new() } ///     } ///     fn push(&self, value: T) { ///         // FIXME: this impl is concise, but is also slow for long lists or many threads. ///         // as an exercise, consider how you might improve on it while preserving the behavior ///         if let Err(value) = self.data.set(value) { ///             let next = self.next.get_or_init(|| Box::new(OnceList::new())); ///             next.push(value) ///         }; ///     } ///     fn contains(&self, example: &T) -> bool ///     where ///         T: PartialEq, ///     { ///         self.data.get().map(|item| item == example).filter(|v| *v).unwrap_or_else(|| { ///             self.next.get().map(|next| next.contains(example)).unwrap_or(false) ///         }) ///     } /// } /// /// // Let's exercise this new Sync append-only list by doing a little counting /// static LIST: OnceList<u32> = OnceList::new(); /// static COUNTER: AtomicU32 = AtomicU32::new(0); /// /// let vec = (0..thread::available_parallelism().unwrap().get()).map(|_| thread::spawn(|| { ///     while let i @ 0..=1000 = COUNTER.fetch_add(1, Ordering::Relaxed) { ///         LIST.push(i); ///     } /// })).collect::<Vec<thread::JoinHandle<_>>>(); /// vec.into_iter().for_each(|handle| handle.join().unwrap()); /// /// for i in 0..=1000 { ///     assert!(LIST.contains(&i)); /// } /// /// ``` </ins> #[stable(feature = "once_cell", since = "1.70.0")] pub struct OnceLock<T> { once: Once,

Discussion:
These types are now, however, the docs don't properly mention them everywhere yet: lists OnceCell in the overview, but not LazyCell. The docs should also explain when I should use which of these types, as they are superficially pretty similar. lists Once and OnceLock, but not LazyLock. The same point about "when to use which type" applies. (It seems like is basically the same as , but I am not sure.) Cc
thatnks for the PR! The question of Once vs OnceLock seems to remain unresolved though. If Once is to OnceLock what is to Mutex, then it should probably be considered extremely niche as one can't even safely protect any data that way?
Yeah, I do indeed have nothing useful to say about Once, basically, because it doesn't seem very useful except as a raw implementation primitive of OnceLock. I suppose we could add a comment that soft-discourages it?
Yeah I think that would be useful.
Change:
#[inline] pub fn sleep(dur: Duration) { <ins> let micros = dur.as_micros() + if dur.subsec_nanos() % 1_000 > 0 { 1 } else { 0 }; let micros = u64::try_from(micros).unwrap_or(u64::MAX); </ins> unsafe { <del> hermit_abi::usleep(dur.as_micros() as u64); </del> <ins> hermit_abi::usleep(micros); </ins> } }

Discussion:
Multiple targets currently use to implement conversion from a Duration to a value in microseconds. However, currently reads as so: Up. Note this which means is not a valid implementation of this spec. Note that this is not the only problem that espidf poses with respect to its std implementation: :
First found on espidf: cc
Same bug: cc
Agreed - problem is clear and I'll fix shortly - thanks for noticing! An interesting question here is whether it is allowed - in - to busy-wait for sleeping? Because this is exactly what would happen on the ESP IDF . Given that the documentation is silent in this regard, I suggest to keep the current behavior (i.e. busy-waiting for durations < 10ms) as that allows callers of to "at least do some sleep - busy-looping or not". I don't think this is a problem on the ESP IDF, . Or processes thereof.
Yes, I believe busy-waiting is a valid implementation of sleep, and especially in particular, if we were to have a hypothetical that returned if the platform didn't have an actual syscall for sleeping for that long, I would expect busy-waiting to be on the other side of the if/else almost every single time.
Change:
if let StabilityLevel::Unstable { reason, issue, is_soft } = stability.level { let feature = stability.feature; if !self.active_features.contains(&feature) && !span.allows_unstable(feature) { <del> stability::report_unstable(self.session, feature, reason, issue, is_soft, span); </del> <ins> let node_id = ast::CRATE_NODE_ID; let soft_handler = |lint, span, msg: &_| self.session.buffer_lint(lint, node_id, span, msg); stability::report_unstable( self.session, feature, reason, issue, is_soft, span, soft_handler ); </ins> } } if let Some(depr) = &stability.rustc_depr {

Discussion:
Hi there, I'm updating rust-sgx-sdk (solving rust-sgx-sdk ) to use latest rust nightly compiler to help the error info more ergonomic by the help of . However, the compiler always panics. Your help would be very much helpful. The current code is at . To reproduce this bug, please checkout branch and build sgxtstd as follows: And the reproducible failure info is: : rustc 1.40.0-nightly ( 2019-10-03) binary: rustc commit-hash: commit-date: 2019-10-03 host: x8664-unknown-linux-gnu release: 1.40.0-nightly LLVM version: 9.0 Backtrace:
It'd be helpful to have a more minimal example here I suspect -- for example, at least reducing to a single crate. cc since this deals with diagnostic machinery
It seems like this was introduced a month ago in , CC
I think I find the solution on my side: the removal of .
A working branch is baidu/rust-sgx-sdk : test-2019-10. Failing branch is librustc-bug-report. After I enable , the compiler starts to fail.
The minimum sample is as follows: and compile by
Fixed in
Cool!
Change:
($lvl:expr, $($arg:tt)+) => {} } <ins> macro_rules! check { ($ty:ty, $expected:expr) => {}; ($ty_of:expr, $expected:expr) => {}; } </ins> fn main() { println!("{}" a);

Discussion:
I don't know what to make of this error. () Errors: On stable (1.34) the output is
I'm pretty sure this is fallout from the "missing comma here" suggestion for macros, that evaluates the macro again with the current arguments but adding a comma token in between the argument tokens in different combinations to see if it would be correct. My guess is that that is causing a parse error that doesn't happen for normal things than only have one token in them. We can disable the suggestion when fully qualified paths are involved.
Change:
stop = true; return; } <ins> if sym.contains("__rust_end_short_backtrace") { start = true; return; } </ins> } } <del> res = bt_fmt.frame().symbol(frame, symbol); </del> <ins> if start { res = bt_fmt.frame().symbol(frame, symbol); } </ins> }); if stop { return false; } if !hit { <del> res = bt_fmt.frame().print_raw(frame.ip(), None, None, None); </del> <ins> if start { res = bt_fmt.frame().print_raw(frame.ip(), None, None, None); } </ins> } idx += 1;

Discussion:
v.s. is less verbose, but I remember it also filtering out some stack frames in some previous compiler versions. (Only frame # 6 is really useful to me here.) Indeed, contains some code that looks for a symbol on the stack to find out what to filter. It looks like some functionality has regressed. Stepping through the program in gdb it looks like the function is called, but despite there’s apparently no stack frame (anymore?) for it. CC and for , , and .
contains a fix for this
Now being worked on in instead afaict?
It is.
This issue hasn't been active in almost two years, and so have the issues linked here. Is there any intention of resuming work on this? It's mostly a small papercut because currently when crashing, programs suggest: run with environment variable to display a backtrace. and after setting that, also claim that: Some details are omitted, run with for a verbose backtrace. even though no details were omitted at all (which is the issue of course)
A simple fix would be to just look for "std::rt::lang_start::{{closure}}" instead until the real solution to the disappearing function is found..
This single fix is likely to have the biggest positive effect on my use of Rust since async/await. Thank you so much!
Awesome! I'm happy to see this finally fixed :D Thanks to everyone who had a part in this fix :)
Change:
<ins> error[E0277]: `?` couldn't convert the error to `()` --> $DIR/option-to-result.rs:5:6 | LL |     a?; |      ^ the trait `std::convert::From<std::option::NoneError>` is not implemented for `()` | = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait = note: required by `std::convert::From::from` help: consider converting the `Option<T>` into a `Result<T, _>` using `Option::ok_or` or `Option::ok_or_else` | LL |     a.ok_or_else(|| /* error value */)?; |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0277]: `?` couldn't convert the error to `std::option::NoneError` --> $DIR/option-to-result.rs:11:6 | LL |     a?; |      ^ the trait `std::convert::From<i32>` is not implemented for `std::option::NoneError` | = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait = note: required by `std::convert::From::from` help: consider converting the `Result<T, _>` into an `Option<T>` using `Result::ok` | LL |     a.ok()?; |      ^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
It seems that should provide a better error message or hint when one tries to use the operator on an in a function returning a or vice-versa. Currently this is the error you get: However, it would be better to suggest the use of or , or , instead of referencing something dependent on the feature (). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This error is emitted here: We could look at whether the is , and if so, provide a more targeted error, including a structured suggestion for .
Can I claim this issue?
claim
Change:
max-width: 100%; } <del> .content.source { </del> <ins> .source .content { </ins> margin-top: 50px; max-width: none; overflow: visible;

Discussion:
What it looks like on : ! ! The strange color change on the side with the new sidebar style looks kind of tacky (especially at the bottom) and was probably not intended. Currently on : ! !
This is also broken on beta, tagging as such.
I'm looking into this. I see three potential options: the sidebar white on the src pages. This would look the same as the old styling. the width of the src view so it doesn't overlap with the sidebar. The sidebar is empty on src pages though so this looks kind of weird. If the sidebar retained its items from the other doc pages, this might look nice. the sidebar color and the background of the code block match so there isn't slightly different shades of grey on top of each other. I'm leaning toward option 1 for now but I think option 2 might be worth considering in the future. Thoughts?
While I am certainly not the most qualified to weigh in on this, my thoughts would be that 3 is less than desirable (having a random grey stripe on the left side looks out-of-place regardless of whether the color matches or not), 2 would unnecessarily decrease the usability of pages by decreasing the amount of horizontal space available to the code, and 1 is likely the best option. 3 would also mean that the code block would have padding on the right side but no padding on the left.
1 seems good
Ok. Option 1 it is!
Change:
<ins> // issue: 114145 #![feature(return_position_impl_trait_in_trait)] trait Iterable { type Item<'a> where Self: 'a; fn iter(&self) -> impl '_ + Iterator<Item = Self::Item<'_>>; } impl<'a, I: 'a + Iterable> Iterable for &'a I { type Item<'b> = I::Item<'a> where 'b: 'a; //~^ ERROR impl has stricter requirements than trait fn iter(&self) -> impl 'a + Iterator<Item = I::Item<'a>> { //~^ ERROR the type `&'a I` does not fulfill the required lifetime (*self).iter() } } fn main() {} </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
This needs detailed investigation, and I'd prefer we fully understand why this is resulting in a region error over just adding an check to (or feeding the query).... This probably has to do with the fact that we have a due to the missing region .
Change:
use vec; use vec::VectorVector; use option::*; <ins> use ptr; </ins> #[bench] fn iterator(bh: &mut BenchHarness) {

Discussion:
While landed a nice optimization of in , he said that it's still not performing as fast as doing a malloc and a . We should figure out why it is not performing as well as it should be and fix it in order to remove the temptation of using the faster unsafe functions.
It turns out this is substantially slower than I expected. With this test benchmark: I'm getting these results: This is related to and .
mentioned in irc that with the difference is: Which is much better, but still not great.
memset "cheats" with sse. fromelem spends a lot of time in moveval_init without optimizations so there's a bunch of unnecessary function calls. With optimizations, the thing that's killing it is the copies.
LLVM knows how to optimize loops to the same code as memcpy/memmove/memset though, as long as you generate good IR.
I a bench for the literal vec repeat syntax as well: Without optimizations: With optimizations (-O): Looking at the optimized IR, both setmemory and vecrepeat become a memset but setmemory seems to have a lot more overhead. does not become a memset hence the bad results.
this gets a lot better with the optimization passes from , from ~3x as slow to ~2x as slow Before (opt-level=2): After (opt-level=2)
the problem is with the code bloat from the surrounding code, rather than itself - I think we actually produce some IR there with undefined behaviour
greatly speeds up , fixing half of the issue Before: After:
The performance of all 3 has improved, but got slower relative to the others:
It looks like the remaining issue is our pointer arithmetic being slow. The and functions compile to conversions to and from integers, rather than actual pointer arithmetic with the stricter semantics. I think we need to make the and implementations for pointers a compiler feature.
Fixed by .
This since that fix, is attempting a bisect atm. Update: bisect finished, is to blame. isn't optimized. Maybe the needs to be inlined for further optimizations.
Note that set_memory has regressed by ~16ns, cause is ()
Change:
__internal::with_parse_sess(|sess| { let src = src.to_string(); let cfg = Vec::new(); <del> let name = "rustc-macro source code".to_string(); </del> <ins> let name = "<rustc-macro source code>".to_string(); </ins> let mut parser = parse::new_parser_from_source_str(sess, cfg, name, src); let mut ret = TokenStream { inner: Vec::new() };

Discussion:
Noticed it causing issues with cargo as it uses and then parses the files as part of the fingerprinting process. It seems every instance of macro generated code (e.g. via serde_derive) creates a entry into this file which when cargo tries to look up it can't find. Cargo issue:
Added this to the macros 1.1 tracking issue (I consider this a blocker for stabilization)
Change:
debug_assert!(tail.has_non_region_param()); Ok(SizeSkeleton::Pointer { non_zero, tail: tcx.erase_regions(tail) }) } <ins> ty::Error(guar) => { // Fixes ICE #124031 return Err(tcx.arena.alloc(LayoutError::ReferencesError(*guar))); } </ins> _ => bug!( "SizeSkeleton::compute({ty}): layout errored ({err:?}), yet  tail `{tail}` is not a type parameter or a projection",

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: SizeSkeleton::compute(&Other): layout errored (Unknown(Alias(Projection, AliasTy { args: [Other], defid: DefId(2:2049 ~ core[a6f4]::ptr::metadata::Pointee::Metadata) }))), yet tail is not a type parameter or a projection', 'error: internal compiler error: SizeSkeleton::compute(&Other): layout errored (Unknown(Alias(Projection, AliasTy { args: [Other], defid: DefId(2:2049 ~ core[a6f4]::ptr::metadata::Pointee::Metadata) }))), yet tail is not a type parameter or a projection' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
that's true, it's a type error (should be a quick fix)
you may also enjoy this gem: (found somewhere else)
Ah, this ( ) one bisects to fyi ^^
claim
Change:
<del> error: --> $DIR/issue-90014-tait2.rs:44:27 | LL |     fn make_fut(&self) -> Box<dyn for<'a> Trait<'a, Thing = Fut<'a>>> { |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^query stack during panic: #0 [typeck] type-checking `<impl at $DIR/issue-90014-tait2.rs:43:1: 43:13>::make_fut` #1 [type_of] computing type of `Fut::{opaque#0}` #2 [check_mod_item_types] checking item types in top-level module #3 [analysis] running analysis passes on this crate end of query stack </del> <ins> error[E0792]: expected generic lifetime parameter, found `'a` </ins> error: aborting due to previous error <ins> For more information about this error, try `rustc --explain E0792`. </ins>

Discussion:
Found this while minimizing :smile: So maybe related? didn't seem like duplicates. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +S-bug-has-mcve +F-typealiasimpl_trait
Regression in nightly-2022-07-01 reproduced based of a modifiction of which does not need any feature gates and crashes stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium