jiebi/CodeConvo huggingface dataset:
Code change:
LL |     type Bar<'a>: Deref<Target = <Self>::Bar<'a, Target = Self>>; |                                              +++ <del> error: aborting due to previous error </del> <ins> error[E0229]: associated type bindings are not allowed here --> $DIR/issue-85347.rs:3:46 | LL |     type Bar<'a>: Deref<Target = <Self>::Bar<Target = Self>>; |                                              ^^^^^^^^^^^^^ associated type not allowed here error: aborting due to 2 previous errors </ins> <del> For more information about this error, try `rustc --explain E0107`. </del> <ins> Some errors have detailed explanations: E0107, E0229. For more information about an error, try `rustc --explain E0107`. </ins>

Related discussion:
text: I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully: The associated constant does not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list should be flagged as erroneous. Interestingly, if you remove the , the compiler correctly identifies this as an error: . I think is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value). : label T-compiler requires-nightly (it now does) Hence, I am just going to mention its tracking issue: . CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Doesn't need assoc const equality: Let me take a quick stab at this. claim
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): <details<summarystderr (diagnostics & backtrace)</summary</detailsThis only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like (2022-09-21).
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one.
Yeah, I think so, too. I guess I won't bisect this.
This regressed in the last day
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 regressed nightly: nightly-2022-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Code change:
fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

Related discussion:
text: While attempting to build the current bobbin-sdk under Ubuntu 18.04 using rust 1.34.0-nightly ( 2019-02-26) I get a panic in rustc.
cc
Minimal repro: you need both the , a method call , and a method call on the result of that in order to trigger promotion. It seems like is promoted to make a for the call to
Ok, so promotion is indeed screwing up. The MIR is promoting the argument.
triage: P-high. Looks under control.
Just to confirm, this has not made it out to the nightly, correct? As of today I am still seeing the same error when attempting to build bobbin-hz as part of bobbin-sdk.
No, is still open, I'll bump its priority
Code change:
fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

Related discussion:
text: ICE when compiling bash parity-ethereum git:(master) cargo build Compiling ethcore-miner v1.12.0 () thread 'rustc' panicked at 'index out of bounds: the len is 2 but the index is 3', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::continuepanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panicboundscheck at 10: <rustctarget::abi::TyLayout<'a, Ty::field 11: rustcmir::interpret::operand::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::operandfield 12: rustcmir::interpret::operand::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::evalplacetoop 13: rustcmir::interpret::step::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::run 14: rustcmir::consteval::evalbodyusingecx 15: rustcmir::consteval::constevalrawprovider 16: rustc::ty::query::querycompute::constevalraw 17: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::constevalraw<'tcx::compute 18: rustc::depgraph::graph::DepGraph::withtaskimpl 19: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,
Code change:
fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

Related discussion:
text: 'tcx::getquery 20: rustcmir::consteval::constevalprovider 21: rustc::ty::query::querycompute::consteval 22: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::consteval<'tcx::compute 23: rustc::depgraph::graph::DepGraph::withtaskimpl 24: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::getquery 25: rustcmir::consteval::constevalprovider 26: rustc::ty::query::querycompute::consteval 27: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::consteval<'tcx::compute 28: rustc::depgraph::graph::DepGraph::withtaskimpl 29: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::getquery 30: rustcmir::monomorphize::collector::collectitemsrec 31: rustcmir::monomorphize::collector::collectcratemonoitems::{{closure}} 32: rustc::util::common::time 33: rustcmir::monomorphize::collector::collectcratemonoitems 34: rustc::util::common::time 35: rustcmir::monomorphize::partitioning::collectandpartitionmonoitems 36: rustc::ty::query::querycompute::collectandpartitionmonoitems 37: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::collectandpartitionmonoitems<'tcx::compute 38: rustc::depgraph::graph::DepGraph::withtaskimpl 39: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,
Code change:
fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

Related discussion:
text: 'tcx::getquery 40: rustccodegenssa::back::symbolexport::exportedsymbolsproviderlocal 41: rustc::ty::query::querycompute::exportedsymbols 42: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::exportedsymbols<'tcx::compute 43: rustc::depgraph::graph::DepGraph::withtaskimpl 44: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,
Code change:
fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

Related discussion:
text: 'tcx::getquery 45: rustcmetadata::encoder::encodemetadata 46: rustcmetadata::cstoreimpl::<impl rustc::middle::cstore::CrateStore for rustcmetadata::cstore::CStore::encodemetadata 47: rustc::ty::context::TyCtxt::encodemetadata 48: rustccodegenllvm::base::writemetadata 49: rustc::util::common::time 50: rustccodegenssa::base::codegencrate 51: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 52: rustc::util::common::time 53: rustcdriver::driver::phase4codegen 54: rustcdriver::driver::compileinput::{{closure}} 55: <std::thread::local::LocalKey<T::with 56: rustc::ty::context::TyCtxt::createandenter 57: rustcdriver::driver::compileinput 58: rustcdriver::runcompilerwithpool 59: <scopedtls::ScopedKey<T::set 60: rustcdriver::runcompiler 61: syntax::withglobals 62: rustmaybecatchpanic at 63: <F as alloc::boxed::FnBox<A::callbox 64: std::sys::unix::thread::Thread::new::threadstart at at at 65: startthread 66: _clone query stack during panic: [constevalraw] const-evaluating [consteval] const-evaluating + checking [consteval] const-evaluating + checking [collectandpartitionmonoitems] collectandpartitionmonoitems [exportedsymbols] exportedsymbols end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-21) running on x8664-unknown-linux-gnu note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib note: some of the compiler flags provided by cargo are hidden error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed
cc
Is this a regression?
Code change:
fn in_call( cx: &ConstCx<'_, 'tcx>, callee: &Operand<'tcx>, <del> _args: &[Operand<'tcx>], </del> <ins> args: &[Operand<'tcx>], </ins> _return_ty: Ty<'tcx>, ) -> bool { if cx.mode == Mode::Fn {

Related discussion:
text: Did it work with a previous nightly? I'm currently looking through function (the ICE is during the evaluation of a promoted inside that function), but I can't find any promoteds :confused:
I can't debug this right now, because a debugging compiler fails even earlier:
So apparently still causes the ICE, but only inside the crate. If I try to create an MCVE everything compiles just fine... Very confusing.
triage: P-high. Looks to be in good hands.
Thanks, I can verify that it is fixed in
Code change:
} fn is_try_block(&self) -> bool { <del> self.token.is_keyword(kw::Try) && self.look_ahead(1, |t| *t == token::OpenDelim(token::Brace)) && self.token.uninterpolated_span().rust_2018() && // Prevent `while try {} {}`, `if try {} {} else {}`, etc. !self.restrictions.contains(Restrictions::NO_STRUCT_LITERAL) </del> <ins> self.token.is_keyword(kw::Try) && self.look_ahead(1, |t| *t == token::OpenDelim(token::Brace)) && self.token.uninterpolated_span().rust_2018() </ins> } /// Parses an `async move? {...}` expression.

Related discussion:
text: This produces a lint: But removing the parentheses produces an error. This bug was already mentioned in , but that issue is lost in feature-request purgatory since it asks for the version without parentheses to be allowed. I'm opening this issue to track the incorrect lint specifically. (Edit: Fixed the example.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will wait for to get merged before this is fixed though.
Code change:
} fn is_try_block(&self) -> bool { <del> self.token.is_keyword(kw::Try) && self.look_ahead(1, |t| *t == token::OpenDelim(token::Brace)) && self.token.uninterpolated_span().rust_2018() && // Prevent `while try {} {}`, `if try {} {} else {}`, etc. !self.restrictions.contains(Restrictions::NO_STRUCT_LITERAL) </del> <ins> self.token.is_keyword(kw::Try) && self.look_ahead(1, |t| *t == token::OpenDelim(token::Brace)) && self.token.uninterpolated_span().rust_2018() </ins> } /// Parses an `async move? {...}` expression.

Related discussion:
text: The following code fails to compile (): The compiler error is: Adding parentheses or braces, it will compile fine: The same issue happens with other constructs such as:
cc
I believe the error is expected here, the same as with : Which also needs to be to compile. That said, the warning to remove the necessary parens is definitely wrong. EDIT: Hmm, I might be wrong, actually. The following compiles, which surprised me: as does this: So maybe the parser restriction is only for struct literals, not for keyword-introduced expressions.
Yeah I think is the better comparison here so it's probably a bug.
This is exactly what a thought. I didn't know that this:
For , hmmm... well, I can't come up with a truly devastating example, but eliminating the parentheses could hurt diagnostics.
Code change:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/16.0-2023-03-06 </del> <ins> branch = rustc/16.0-2023-04-05 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git

Related discussion:
text: Hi, Building in release mode with a freshly updated nightly fails with a SIGSEGV (or STATUSACCESSVIOLATION on Windows). This doesn't occur on or , or when building with any profile that has . I stumbled upon this while trying to measure the performance impact of , which branches from at and suffers from the same issue. I don't know why, but the problem only appears on (that I'm aware of): fails, while any other crate within the same repo works (provided they don't depend on )? : The same issue arises with the same version of nightly on Windows. <details<summaryBacktrace</summary<p</p</details
Could you check which nightly and PR caused this regression with ?
Additionally, are you able to get a backtrace with a debugger?
Sure, I'll run the bisect tomorrow morning (CET). I'll try, but if the builds don't already have debug symbols, I'm not sure how to have x.py spit them out. No need to reply if they're already in there, but if they aren't, instructions would be appreciated :)
We do ship debug symbols, they may be in a rustup component instead of shipped by default. rustc-dev, I believe?
Thanks, I'll check that out in roughly 8 hours :)
We do always ship symbols in the same binary, but we never ship debuginfo.
Preliminary reduction for :
Minimized:
Upstream fix:
Thank you so much for taking the issue, I did try bisecting, but you had located the issue by the time I made any progress :)
Code change:
/// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_millis(), 5730); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_millis(&self) -> u128 { self.secs as u128 * MILLIS_PER_SEC as u128 + (self.nanos / NANOS_PER_MILLI) as u128

Related discussion:
text: Duration has historically lacked a way to get the actual number of nanoseconds it contained as a normal Rust type because u64 was of insufficient range, and f64 of insufficient precision. The u128 type solves both issues, so I propose adding an as_nanos function to expose the capability. CC:
I still don't understand why Duration is not allowed to be negative. It bugs me that the SystemTime difference returns a Result<Duration,Errorand returns and error if the time from is after the time to. To me, it should just return a negative Duration (Yes, the System Clock can go backwards). I find it odd that Duration does not support a negative amount.
I think it's about the way you think of . If it's a span of time (like described in the documentation) or an interval, then it must be positive. If it's the distance between two time points, it's negative. You're probably thinking of a distance instead of an interval. That's not necessarily a bad thing, but it's different from what the type is today, and it will never change due to compatibility concerns.
Here is what I take issue with: And....DING! DING! DING! know what, now that I've typed out that code, I can't think of any justifiable reason I would actually want that, so, once again, the thoughtfulness of Rust shows itself. You and the designers of Duration were correct. Negative Duration doesn't make sense (even though it feels like it should).
You can use if you want to measure a duration.
Yes, I'm aware. I guess I think there should be another thing called ClockTimeDifference (that can be neg/pos) and there should be methods on SystemTime that don't return Result<Duration,Error, but, instead return ClockTimeDifference. It could be as simple as:
It can, but the return type of will never change, so it's up to you (or a crate) to implement that.
This is the tracking issue for a feature that adds several specific methods to Duration, not a place to debate general concerns about the Duration type. Your discussion is probably better suited for the site.
Why can't as_millis return an i64?
large durations won't fit into that type.
Pardon my ignorance, but why is this unstable?
Code change:
/// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_millis(), 5730); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_millis(&self) -> u128 { self.secs as u128 * MILLIS_PER_SEC as u128 + (self.nanos / NANOS_PER_MILLI) as u128

Related discussion:
text: For my usecase, I probably don't need more than a , and I really only need millis (though the code I'm porting happens to use microseconds). I'd rather have a , but I'm just not sure what to do here for my code which I'm trying to keep as close to fully stable as possible (I want it to be as portable and safe as I can make it). I know (I think?) I can use , but I'd rather not lose the precision and I think I can always use for all my platforms.
is there any reason not to move forward with stabilization on this? correctly observes that it has been unstable for quite a while
The stability of u128 was the blocker previously, but that's now no longer a problem. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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.
I couldn’t find all the details in this issue, grepping through the code shows that this tracking issue is for:
This may be a stupid question, but is available on all platforms that Rust supports?
:bell: This is now entering its final comment period, as per the . :bell:
Yep, it should be available on all platforms.
The final comment period, with a disposition to merge, as per the , is now complete.
Now that final comment period has ended, can these methods be stabilized?
Yes, the next step is a stabilization PR.
Awesome! I've made a PR for stabilization here: Please let me know if it needs any adjustments. I can't wait for this to land! :tada:
Code change:
<ins> // Copyright 2017 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. // Issue 46112: An extern crate pub reexporting libcore was causing // paths rooted from `std` to be misrendered in the diagnostic output. // ignore-windows // aux-build:xcrate_issue_46112_rexport_core.rs extern crate xcrate_issue_46112_rexport_core; fn test(r: Result<Option<()>, &'static str>) { } fn main() { test(Ok(())); } //~^ mismatched types </ins>

Related discussion:
text: On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type. I tried this code: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: I have been trying to further dissect that commit to figure out why it causes the change we observe here. My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...
Hmm. Its something more subtle than a hashmap-related bug.
Code change:
<ins> // Copyright 2017 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. // Issue 46112: An extern crate pub reexporting libcore was causing // paths rooted from `std` to be misrendered in the diagnostic output. // ignore-windows // aux-build:xcrate_issue_46112_rexport_core.rs extern crate xcrate_issue_46112_rexport_core; fn test(r: Result<Option<()>, &'static str>) { } fn main() { test(Ok(())); } //~^ mismatched types </ins>

Related discussion:
text: In particular, I can reproduce the old behavior on master by just linking in the old crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.
is that a regression from the stable channel? While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .