jiebi/CodeConvo huggingface dataset:
Code change:
use use_from_trait_xc::Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use use_from_trait_xc::Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use use_from_trait_xc::Trait::CONST; //~^ ERROR `CONST` is not directly importable </ins> use use_from_trait_xc::Foo::new; //~^ ERROR `new` is not directly importable <ins> use use_from_trait_xc::Foo::C; //~^ ERROR unresolved import `use_from_trait_xc::Foo::C` </ins> use use_from_trait_xc::Bar::new as bnew; //~^ ERROR `bnew` is not directly importable

Related discussion:
text: with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13:
Code change:
use use_from_trait_xc::Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use use_from_trait_xc::Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use use_from_trait_xc::Trait::CONST; //~^ ERROR `CONST` is not directly importable </ins> use use_from_trait_xc::Foo::new; //~^ ERROR `new` is not directly importable <ins> use use_from_trait_xc::Foo::C; //~^ ERROR unresolved import `use_from_trait_xc::Foo::C` </ins> use use_from_trait_xc::Bar::new as bnew; //~^ ERROR `bnew` is not directly importable

Related discussion:
text: 0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure.
Code change:
use use_from_trait_xc::Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use use_from_trait_xc::Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use use_from_trait_xc::Trait::CONST; //~^ ERROR `CONST` is not directly importable </ins> use use_from_trait_xc::Foo::new; //~^ ERROR `new` is not directly importable <ins> use use_from_trait_xc::Foo::C; //~^ ERROR unresolved import `use_from_trait_xc::Foo::C` </ins> use use_from_trait_xc::Bar::new as bnew; //~^ ERROR `bnew` is not directly importable

Related discussion:
text: 22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code.
Code change:
use use_from_trait_xc::Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use use_from_trait_xc::Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use use_from_trait_xc::Trait::CONST; //~^ ERROR `CONST` is not directly importable </ins> use use_from_trait_xc::Foo::new; //~^ ERROR `new` is not directly importable <ins> use use_from_trait_xc::Foo::C; //~^ ERROR unresolved import `use_from_trait_xc::Foo::C` </ins> use use_from_trait_xc::Bar::new as bnew; //~^ ERROR `bnew` is not directly importable

Related discussion:
text: Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:
Code change:
pub fn run_silent(cmd: &mut Command) { let status = match cmd.status() { Ok(status) => status, <del> Err(e) => fail(&format!("failed to execute command: {}", e)), </del> <ins> Err(e) => fail(&format!("failed to execute command: {:?}nerror: {}", cmd, e)), </ins> }; if !status.success() { fail(&format!("command did not execute successfully: {:?}n

Related discussion:
text: Rustbuild now prints which is very not helpful.
I've hit this one too: When there's a stale in Rust's root directory, bootstrap reads paths from there and tries to convert them into windows format using (which it, of course, can't find since we are not running in msys shell). The error message comes from in buildhelper (called from ).
Code change:
/// /// # Examples /// ``` <del> /// #![feature(div_duration)] </del> /// use std::time::Duration; /// /// let dur1 = Duration::new(2, 700_000_000); /// let dur2 = Duration::new(5, 400_000_000); /// assert_eq!(dur1.div_duration_f64(dur2), 0.5); /// ``` <del> #[unstable(feature = "div_duration", issue = "63139")] </del> <ins> #[stable(feature = "div_duration", since = "CURRENT_RUSTC_VERSION")] </ins> #[must_use = "this returns the result of the operation,  without modifying the original"] #[inline] #[rustc_const_unstable(feature = "duration_consts_float", issue = "72440")] pub const fn div_duration_f64(self, rhs: Duration) -> f64 { <del> self.as_secs_f64() / rhs.as_secs_f64() </del> <ins> let self_nanos = (self.secs as f64) * (NANOS_PER_SEC as f64) + (self.nanos.0 as f64); let rhs_nanos = (rhs.secs as f64) * (NANOS_PER_SEC as f64) + (rhs.nanos.0 as f64); self_nanos / rhs_nanos </ins> } /// Divide `Duration` by `Duration` and return `f32`. /// /// # Examples /// ``` <del> /// #![feature(div_duration)] </del> /// use std::time::Duration; /// /// let dur1 = Duration::new(2, 700_000_000); /// let dur2 = Duration::new(5, 400_000_000); /// assert_eq!(dur1.div_duration_f32(dur2), 0.5); /// ``` <del> #[unstable(feature = "div_duration", issue = "63139")] </del> <ins> #[stable(feature = "div_duration", since = "CURRENT_RUSTC_VERSION")] </ins> #[must_use = "this returns the result of the operation,  without modifying the original"] #[inline] #[rustc_const_unstable(feature = "duration_consts_float", issue = "72440")] pub const fn div_duration_f32(self, rhs: Duration) -> f32 { <del> self.as_secs_f32() / rhs.as_secs_f32() </del> <ins> let self_nanos = (self.secs as f32) * (NANOS_PER_SEC as f32) + (self.nanos.0 as f32); let rhs_nanos = (rhs.secs as f32) * (NANOS_PER_SEC as f32) + (rhs.nanos.0 as f32); self_nanos / rhs_nanos </ins> } }

Related discussion:
text: Rust PR: This feature adds the following methods to : -
Anything in particular holding up the stabilization here? The implementation is trivial and docs lgtm.
I would like to add methods that return an exact , but that can wait.
These methods are a little odd, but seem reasonable to me following the example given:
Given how straightforward these methods are, I don't think there's any problem stabilising them?
They're straightforward in implementation, but conceptually tricky at a glance. I think the docs will need some fleshing out before stabilizing but I don't have any other concerns if somebody wants to write a PR!
This needs more testing with various interesting values that could produce interesting floating point numbers, and should not be stabilized without such.
tests were in this PR
Code change:
<ins> // https://github.com/rust-lang/rust/issues/116796 struct X<const FN: fn() = { || {} }>; //~^ ERROR using function pointers as const generic parameters is forbidden fn main() {} </ins>

Related discussion:
text: 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
really need to add auto-bisection to icemaker reports... Regression in nightly-2021-04-26 found 9 bors merge commits in the specified range commit[0] 2021-04-24: Auto merge of - davidhewitt:revert-, r=GuillaumeGomez commit[1] 2021-04-24: Auto merge of - RalfJung:const-fn-feature-flags, r=oli-obk commit[2] 2021-04-25: Auto merge of - jyn514:no-span, r=GuillaumeGomez commit[3] 2021-04-25: Auto merge of - CDirkx:rt, r=m-ou-se commit[4] 2021-04-25: Auto merge of - cuviper:array-method-dispatch, r=nikomatsakis,m-ou-se commit[5] 2021-04-25: Auto merge of - RalfJung:black-box, r=Mark-Simulacrum commit[6] 2021-04-25: Auto merge of - lcnr:const-generics-defaults-name-res, r=varkor commit[7] 2021-04-25: Auto merge of - RalfJung:miri, r=RalfJung commit[8] 2021-04-25: Auto merge of - jsha:ephemeral-collapse, r=GuillaumeGomez maybe ?
hm, with , this crashes like this:
Hmm, I'm confused by the result of the bisection, I expected it to find a relatively recent commit since the reproducer doesn't ICE on stable (1.73) (while it does ICE on beta and nightly):
Doesn't ICE if is enabled.
this feature fixing an ice instead of causing one, that's a first...
This errors cleanly since beta 1.76.
Code change:
use rustc_middle::ty::{self, GenericArgKind, Ty, TyCtxt, TypeVisitableExt}; use rustc_span::def_id::DefIdSet; use rustc_span::symbol::{kw, sym, Ident}; <del> use rustc_span::Symbol; </del> use rustc_span::{edit_distance, ExpnKind, FileName, MacroKind, Span}; <ins> use rustc_span::{Symbol, DUMMY_SP}; </ins> use rustc_trait_selection::infer::InferCtxtExt; use rustc_trait_selection::traits::error_reporting::on_unimplemented::OnUnimplementedNote; use rustc_trait_selection::traits::error_reporting::on_unimplemented::TypeErrCtxtExt as _;

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'', 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'' File: --auto-reduced (treereduce-rust): original: Version information ` Command:
thanks for the stack trace for this class of ICEs, it's just the right thing that I need. Minimal:
Code change:
def.variant_descr(), self.tcx.def_path_str(def.did) ) <del> .span_label(span, "private field") </del> <ins> .span_label(span, label) </ins> .emit(); } }

Related discussion:
text: In a recent PR I made a change to unify the wording of multiple privacy errors, but : used to be This one change needs to be reversed while keeping the rest.
Hi! Could I give this issue a shot?
I am sorry I forgot to claim the issue
No worries :-)
Code change:
let rty = ccx.tcx.node_id_to_type(id); let fcx = FnCtxt::new(&inh, ty::FnConverging(rty), e.id); let declty = fcx.tcx.lookup_item_type(ccx.tcx.map.local_def_id(id)).ty; <ins> fcx.require_type_is_sized(declty, e.span, traits::ConstSized); </ins> fcx.check_const_with_ty(sp, e, declty); }); }

Related discussion:
text: This looks unintentional, and has been broken in all cases, until a few releases ago, AFAICT. Should this be covered by WF rules? cc Unsized constants cause an ICE, in both old trans and MIR trans: Unsized statics appear to work, but only in old trans: I believe this is possible because a constant DST lvalue in old trans is merely the fat pointer. It seems useful to allow an unsized , but IMO it should require a sized RHS instead, i.e.: And, of course, this should all go through the RFC process, to figure out all the finer details.
Should it be ? I don't think A needs to be an lvalue.
It makes more sense for constants, but I gave the example with because that's the only one that works today (although by accident).
Hmm? I mean the static is desugared into a const. works today.
The idea being that a static and a const reference both give access to one lvalue.
No, has different semantics: it allows an somewhere within and is guaranteed not to be duplicated.
Hmm? Both of these gives me a "error: cannot borrow a constant which contains interior mutability, create a static instead". This is what I'd suspect as the lvalue from the promoted has nothing to do with being a or a .
Let me rewrite my desugaring to account for that, oops.
Oh and my confusion really just stemmed from forgetting about the constants referring to statics rule. [Kind of a funny rule when works, but this is an orthogonal issue.]
I think in the meantime unsized statics should probably error, perhaps dependent on a crater run, though I doubt there's many people relying on said bug. It's much easier to relax restrictions than tighten them.
Will prepare a patch to turn this into an error, hopefully nobody has been abusing it.
Code change:
<del> // no-prefer-dynamic </del> #![feature(unsized_tuple_coercion)] static mut DROP_RAN: bool = false;

Related discussion:
text: Right now on our bots we're basically in a state where if valgrind rpass tests are compiled dynamically they will all fail, but when compiled statically they will pass. I'm not really sure what's going on unfortunately, but this is either a bug in valgrind or a bug with us, and we should know precisely what it is to ensure something more sinister isn't lurking. Some links: - first pass at linking tests statically, fixed - another pass at linking all tests statically
All the failures seem to be within platform’s dynamic loader. Here’s a few things to try: updating kernel+glibc to the most recent versions (4.4-ish and 2.23-ish, respectively) help? downgrading kernel+glibc to some older version help? non-linux/non-glibc work correctly?
Any news/changes on this one ?
Code change:
names } <ins> /// Returns a scope, plus `true` if that's a type scope for "class" methods, /// otherwise `false` for plain namespace scopes. </ins> fn get_containing_scope<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>, instance: Instance<'tcx>, <del> ) -> &'ll DIScope { </del> <ins> ) -> (&'ll DIScope, bool) { </ins> // First, let's see if this is a method within an inherent impl. Because // if yes, we want to make the result subroutine DIE a child of the // subroutine's self-type. <del> let self_type = cx.tcx.impl_of_method(instance.def_id()).and_then(|impl_def_id| { </del> <ins> if let Some(impl_def_id) = cx.tcx.impl_of_method(instance.def_id()) { </ins> // If the method does *not* belong to a trait, proceed if cx.tcx.trait_id_of_impl(impl_def_id).is_none() { let impl_self_ty = cx.tcx.subst_and_normalize_erasing_regions(

Related discussion:
text: If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim
Code change:
names } <ins> /// Returns a scope, plus `true` if that's a type scope for "class" methods, /// otherwise `false` for plain namespace scopes. </ins> fn get_containing_scope<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>, instance: Instance<'tcx>, <del> ) -> &'ll DIScope { </del> <ins> ) -> (&'ll DIScope, bool) { </ins> // First, let's see if this is a method within an inherent impl. Because // if yes, we want to make the result subroutine DIE a child of the // subroutine's self-type. <del> let self_type = cx.tcx.impl_of_method(instance.def_id()).and_then(|impl_def_id| { </del> <ins> if let Some(impl_def_id) = cx.tcx.impl_of_method(instance.def_id()) { </ins> // If the method does *not* belong to a trait, proceed if cx.tcx.trait_id_of_impl(impl_def_id).is_none() { let impl_self_ty = cx.tcx.subst_and_normalize_erasing_regions(

Related discussion:
text: <!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet.
Code change:
names } <ins> /// Returns a scope, plus `true` if that's a type scope for "class" methods, /// otherwise `false` for plain namespace scopes. </ins> fn get_containing_scope<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>, instance: Instance<'tcx>, <del> ) -> &'ll DIScope { </del> <ins> ) -> (&'ll DIScope, bool) { </ins> // First, let's see if this is a method within an inherent impl. Because // if yes, we want to make the result subroutine DIE a child of the // subroutine's self-type. <del> let self_type = cx.tcx.impl_of_method(instance.def_id()).and_then(|impl_def_id| { </del> <ins> if let Some(impl_def_id) = cx.tcx.impl_of_method(instance.def_id()) { </ins> // If the method does *not* belong to a trait, proceed if cx.tcx.trait_id_of_impl(impl_def_id).is_none() { let impl_self_ty = cx.tcx.subst_and_normalize_erasing_regions(

Related discussion:
text: Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim
Code change:
name_was_remapped: bool, unmapped_path: FileName, mut src: String, <del> start_pos: BytePos) -> SourceFile { </del> <ins> start_pos: BytePos) -> Result<SourceFile, OffsetOverflowError> { </ins> remove_bom(&mut src); let src_hash = {

Related discussion:
text: I know that having huge literal in source is a bad idea, but it should not cause ICE :( It looks like something overflowed. Version: Command, output and backtrace: Here is the generator of the source:
cc
Took a quick look. We certainly have a restriction that any file can't be that large, because we use u32 for indexing. And looks like we never try to enforce it anywhere. I think the place to do that would be . Do we have any way to panic without this being marked as ICE? I don't want to thread to each , and this seems like a marginal error where it's totally OK to panic. This is even OK in the IDE context I think: IDE should enforce reasonable max size of the file (something like 10mb, not 4gb) at the virtual file system layer. The "just panic" fix is here:
Do we have any way to panic without this being marked as ICE? or if the context is available.
I tried to compile the same thing in gcc and clang: With gcc: With clang: EDIT: Opened
Code change:
<ins> error[E0658]: associated const equality is incomplete --> $DIR/dont-ice-on-assoc-projection.rs:15:32 | LL | impl<T> Foo for T where T: Bar<ASSOC = 0> {} |                                ^^^^^^^^^ | = note: see issue #92827 <https://github.com/rust-lang/rust/issues/92827> for more information = help: add `#![feature(associated_const_equality)]` to the crate attributes to enable error[E0119]: conflicting implementations of trait `Foo` for type `()` --> $DIR/dont-ice-on-assoc-projection.rs:15:1 | LL | impl Foo for () {} | --------------- first implementation here LL | impl<T> Foo for T where T: Bar<ASSOC = 0> {} | ^^^^^^^^^^^^^^^^^ conflicting implementation for `()` error: aborting due to 2 previous errors Some errors have detailed explanations: E0119, E0658. For more information about an error, try `rustc --explain E0119`. </ins>

Related discussion:
text: <!-- 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