jiebi/CodeConvo huggingface dataset:
Code change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> use Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use Trait::C; //~^ ERROR `C` is not directly importable </ins> use Foo::new; //~^ ERROR unresolved import `Foo::new`. Not a module `Foo` <ins> use Foo::C2; //~^ ERROR unresolved import `Foo::C2`. Not a module `Foo` </ins> pub trait Trait { fn foo(); <ins> type Assoc; const C: u32; </ins> } struct Foo; impl Foo { fn new() {} <ins> const C2: u32 = 0; </ins> } fn main() {}

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:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> use Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use Trait::C; //~^ ERROR `C` is not directly importable </ins> use Foo::new; //~^ ERROR unresolved import `Foo::new`. Not a module `Foo` <ins> use Foo::C2; //~^ ERROR unresolved import `Foo::C2`. Not a module `Foo` </ins> pub trait Trait { fn foo(); <ins> type Assoc; const C: u32; </ins> } struct Foo; impl Foo { fn new() {} <ins> const C2: u32 = 0; </ins> } fn main() {}

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:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> use Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use Trait::C; //~^ ERROR `C` is not directly importable </ins> use Foo::new; //~^ ERROR unresolved import `Foo::new`. Not a module `Foo` <ins> use Foo::C2; //~^ ERROR unresolved import `Foo::C2`. Not a module `Foo` </ins> pub trait Trait { fn foo(); <ins> type Assoc; const C: u32; </ins> } struct Foo; impl Foo { fn new() {} <ins> const C2: u32 = 0; </ins> } fn main() {}

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:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> use Trait::foo; //~^ ERROR `foo` is not directly importable <ins> use Trait::Assoc; //~^ ERROR `Assoc` is not directly importable use Trait::C; //~^ ERROR `C` is not directly importable </ins> use Foo::new; //~^ ERROR unresolved import `Foo::new`. Not a module `Foo` <ins> use Foo::C2; //~^ ERROR unresolved import `Foo::C2`. Not a module `Foo` </ins> pub trait Trait { fn foo(); <ins> type Assoc; const C: u32; </ins> } struct Foo; impl Foo { fn new() {} <ins> const C2: u32 = 0; </ins> } fn main() {}

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:
<ins> error[E0425]: cannot find value `a_variable_longer_name` in this scope --> $DIR/issue-66968-suggest-sorted-words.rs:3:20 | LL |     println!("{}", a_variable_longer_name); |                    ^^^^^^^^^^^^^^^^^^^^^^ help: a local variable with a similar name exists: `a_longer_variable_name` error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Related discussion:
text: On identifiers that have more than one word, it is relatively common to write them in the wrong order ( → ). These are normally not found by Levenshtein distance checks, but we could do a basic "split on ``, sort and join before comparison" so that we could suggest the right identifier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to try to work on this. As is short enough to be caught by the Levenstein distance, I wrote for testing: claim
I'm thinking about the priority of the different possible matches. I tend to think that a match found by levenstein distance should have a greater priority, but what do you think?
it's tricky. I feel that your instinct might be right but we'd only know when looking at real world usage. The nice thing is that the lev distance check by its very nature it is limited, so doing the swapped words check as a fallback should work out ok in practice.
Releasing my assignment, as I am not sure to be able to commit. In case someone want to take on this, here is the function that should be modified. release-assignment
(I think this is appropriate, please tell me if it isn't) modify labels to +E-Easy
I can take a stab at this, seems reasonable with previous comments. claim
Code change:
let archive = ArchiveRO::open(&path).expect("wanted an rlib"); debug!("reading {}", name); <del> let bc = time(sess.time_passes(), format!("read {}.bc", name), (), |_| archive.read(format!("{}.bc", name))); let bc = bc.expect("missing bytecode in archive!"); </del> <ins> let bc = time(sess.time_passes(), format!("read {}.bc.deflate", name), (), |_| archive.read(format!("{}.bc.deflate", name))); let bc = bc.expect("missing compressed bytecode in archive!"); </ins> let bc = time(sess.time_passes(), format!("inflate {}.bc", name), (), |_| flate::inflate_bytes(bc)); let ptr = bc.as_slice().as_ptr();

Related discussion:
text: Passing rustc the flag and passing may produce different files (that is, outputs). This is true of rust-core (see below), though was not the case for a simpler ("Hello, world!") test file. Test script: Diff output indicates binary files differ. Tested with , rust-core on . rustc compiled from master on Arch Linux. If this is, in fact, expected behavior- sorry for the trouble, unexpected to me.
Can you provide a diff between the outputs? This is likely a known issue, but I would like to be sure.
.bc is a binary format, so just gives "Binary files and differ" as its output. On my machine, is 19K and is 62K. I'm not familiar enough with the format to extract much more data.
I note the difference persists when the second line is (two separate flags), though both produce both artifacts.
Can you pass and diff those outputs?
With emit flags as and respectively, there is no difference in and (according to diff.)
It seems that every bytecode is invalid only when a rlib is produced. It stopped working between rust-git-0.9.1301 and 1362 (shortly before 2014-02-23 15:37:05 -0800). Going back thorugh the log, I found I believe that creates deflated bytecode. Perhaps should be stored with extension or .
Code change:
} fn main() { <del> unsafe { printf(); } //~ ERROR E0060 </del> <ins> unsafe { printf(); } //~^ ERROR E0060 //~| NOTE expected at least 1 parameter //~| NOTE the following parameter type was expected </ins> }

Related discussion:
text: From: src/test/compile- Error E0061 needs a span_label, updating it from: To: Bonus: the types could be incorporated into the label rather than a note (though we may want to avoid types with long names in the label)
Planning on tackling the bonus here. Is there a prefered max length for output on the console. In the case it would exceed this should i truncate the typename or just not include?
- great point. If you want to work on truncation, feel free to add it, too. I'm not sure if the term crate will tell you the current terminal size, but it may.
I'm fixing and I noticed that it and this issue currently share the same code for generating this error, and adding code to add a to the message in would fix both.
Did you do the bonus as well? I can tackle that if you haven't.
I haven't yet - I can fix the issue (currently testing/fixing unit tests) and you can take on the bonus part of the issue.
Sounds great to me! Thanks.
- I opened up issue to track the bonus portion of the work for you.
Code change:
tcx: TyCtxt<'tcx>, fn_sig: ty::PolyFnSig<'tcx>, ) -> Result<bool, &'tcx LayoutError<'tcx>> { <del> let mut ret_ty = fn_sig.output().skip_binder(); </del> <ins> // this type is only used for layout computation, which does not rely on regions let fn_sig = tcx.instantiate_bound_regions_with_erased(fn_sig); let mut ret_ty = fn_sig.output(); </ins> let layout = tcx.layout_of(ParamEnv::reveal_all().and(ret_ty))?; let size = layout.layout.size().bytes();

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'', 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'' 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: [issizedraw] computing whether is [layoutof] computing layout of -- label +F-impltraitinassoctype +F-inherentassociated_types
ah lol this regressed in cc
Code change:
<ins> // Regression test for #61315 // // `dyn T:` is lowered to `dyn T: ReEmpty` - check that we don't ICE in NLL for // the unexpected region. // compile-pass trait T {} fn f() where dyn T: {} fn main() {} </ins>

Related discussion:
text: Found as a byproduct of work on backtrace: Compiles on stable 1.35.0.
triage: Looks like matthewjasper is on top of this. Marking P-high just so I don't have to think about it further right now. Removing nomination tag.
Code change:
<ins> // Regression test for #61315 // // `dyn T:` is lowered to `dyn T: ReEmpty` - check that we don't ICE in NLL for // the unexpected region. // compile-pass trait T {} fn f() where dyn T: {} fn main() {} </ins>

Related discussion:
text: Happens on stable 1.34.2, 1.35.0 and current nightly (2019-05-28). . Results in:
Reduced:
Compiles fine on 1.34.0; haven't tested 1.34.1.
both my repro and your reduced one do ICE on (and ) for me, can you verify that again?
Happens all the way back to 1.30.0 (with ) for me, as long as is passed to rustc.
Ah of course! is needed for NLL on older versions... :) I forgot that godbolt doesn't have that by default.
Code change:
} else if attr.check_name(sym::thread_local) { codegen_fn_attrs.flags |= CodegenFnAttrFlags::THREAD_LOCAL; } else if attr.check_name(sym::track_caller) { <del> if tcx.fn_sig(id).abi() != abi::Abi::Rust { </del> <ins> if tcx.is_closure(id) || tcx.fn_sig(id).abi() != abi::Abi::Rust { </ins> struct_span_err!(tcx.sess, attr.span, E0737, "`#[track_caller]` requires Rust ABI") .emit(); }

Related discussion:
text: This code () Produces ICE on any channel
This is the same issue as , attributes on expressions are not converted into HIR properly.
I checked on latest nightly - isn't produced anymore while this one still throws ICE.
could you reopen this issue?
triage: P-high. Removing nomination.
Reduced somewhat:
Code change:
<del> <pre class="rust item-decl"><code>pub fn create( ) -&gt; <a class="struct" href="struct.Padding00000000000000000000000000000000000000000000000000000000000000000000000000000000.html" title="struct decl_line_wrapping_empty_arg_list::Padding00000000000000000000000000000000000000000000000000000000000000000000000000000000">Padding00000000000000000000000000000000000000000000000000000000000000000000000000000000</a></code></pre> </del>  No newline at end of file <ins> <pre class="rust item-decl"><code>pub fn create() -&gt; <a class="struct" href="struct.Padding00000000000000000000000000000000000000000000000000000000000000000000000000000000.html" title="struct decl_line_wrapping_empty_arg_list::Padding00000000000000000000000000000000000000000000000000000000000000000000000000000000">Padding00000000000000000000000000000000000000000000000000000000000000000000000000000000</a></code></pre> </ins>  No newline at end of file

Related discussion:
text: Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
<ins> // check-pass trait MyCmp { fn cmp(&self) {} } impl MyCmp for f32 {} fn main() { // Ensure that `impl<F: FnPtr> Ord for F` is never considered for int and float infer vars. 0.0.cmp(); } </ins>

Related discussion:
text: Note: the below reduction originally came from a + in the wild. I haven't found a way to demonstrate this outside of the "float inference vars + method" combo, but: works on stable () and beta (), and errors on nightly with: Even though it doesn't show the source for candidate , I'm almost certain it's this: from (cc On the original PR I left comments like , trying to rectify the issues with the original approach, but they didn't go anywhere and the version that one in the end is the (arguably) more fragile original one, that uses blanket s and works around their unwanted interactions. It's possible in this case all it takes is checking for "float inference vars" and making sure they can never be considered to implement , but I'm worried there might be other edge cases lurking in the shadows. Also, did both of those PRs skip crater? I feel like this shouldn't be that hard to hit in the wild.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
"URL": "struct.ZyxwvutMethodDisambiguation.html#method.method_impl_disambiguation-1" }, ENDS_WITH) assert: "section:target" <ins> // Checks that, if a type has two methods with the same name, // and if it has multiple inherent impl blocks, that the numeric // impl block's disambiguator is also acted upon. go-to: "file://" + |DOC_PATH| + "/lib2/index.html?search=MultiImplBlockStruct->bool" wait-for: "#search-tabs" assert-count: ("a.result-method", 1) assert-attribute: ("a.result-method", { "href": "../lib2/another_mod/struct.MultiImplBlockStruct.html#impl-MultiImplBlockStruct/method.second_fn" }) click: "a.result-method" wait-for: "details:has(summary > #impl-MultiImplBlockStruct-1) > div section[id='method.second_fn']:target" go-to: "file://" + |DOC_PATH| + "/lib2/index.html?search=MultiImplBlockStruct->u32" wait-for: "#search-tabs" assert-count: ("a.result-method", 1) assert-attribute: ("a.result-method", { "href": "../lib2/another_mod/struct.MultiImplBlockStruct.html#impl-MultiImplBlockTrait-for-MultiImplBlockStruct/method.second_fn" }) click: "a.result-method" wait-for: "details:has(summary > #impl-MultiImplBlockTrait-for-MultiImplBlockStruct) > div section[id='method.second_fn-1']:target" </ins>

Related discussion:
text: I spotted this in : the result links to ' which is not a valid link. Cc
cc -- I think these are supposed to be autoredirected in JS?
Okay... This happens because there's more than one and the one we want is currently named . The URL escaping is fine; the -35 is the problem.
Code change:
- checkout: self fetchDepth: 2 <ins> # Spawn a background process to collect CPU usage statistics which we'll upload # at the end of the build. See the comments in the script here for more # information. - bash: python src/ci/cpu-usage-over-time.py &> cpu-usage.csv & displayName: "Collect CPU-usage statistics in the background" </ins> - bash: printenv | sort displayName: Show environment variables

Related discussion:
text: One of the easiest ways to make CI faster is to make things parallel and simply use the hardware we have available to us. Unfortunately though we don't have a lot of data about how parallel our build is. Are there steps we think are parallel but actually aren't? Are we pegged to one core for long durations when there's other work we could be doing? The general idea here is that we'd spin up a daemon at the very start of the build which would sample CPU utilization every so often. This daemon would then update a file that's either displayed or uploaded at the end of the build. Hopefully we could then use these logs to get a better view into how the builders are working during the build, diagnose non-parallel portions of the build, and implement fixes to use all the cpus we've got. cc
On Windows this can be done by taking advantage of job objects. If the entire build is wrapped in a job object then we can call with to get a bunch of useful data.
I made script that will print output into the travis log every 30 seconds , . Some findings: Cloning submodules jemalloc, libcompilerbuildtins and liblibc alone takes 30 seconds. While building bootstrap, compiling serdederive, serdejson and bootstrap crates seems to take 30 seconds (total build time: 47 seconds). stage0: Compiling tidy crate seems to take around 30 seconds. Compiling rustcerrors takes at least 2 minutes, only one codegen-unit is used Compiling syntaxext takes 9 minutes, only one CGU used stage0 codegen artifacts: Compiling rustcllvm takes 1,5 minutes, one CGU During stage1, rustcerrors and syntaxext builds are approximately as slow as during stage0, rustc_plugins 2 minutes, one CGU. stage2: rustdoc took 2 minutes to build, one CGU compiletest suite=run-make mode=run-make: It looks like there is a single test that takes around 3 minutes to complete and has no parallelization. Testing alloc stage1: building liballoc takes around a minute Testing syntax stage1: building syntax takes 1.5 minutes, one CGU Notes: When the load average dropped towards 1, I assumed only one codegen unit was active.
Code change:
- checkout: self fetchDepth: 2 <ins> # Spawn a background process to collect CPU usage statistics which we'll upload # at the end of the build. See the comments in the script here for more # information. - bash: python src/ci/cpu-usage-over-time.py &> cpu-usage.csv & displayName: "Collect CPU-usage statistics in the background" </ins> - bash: printenv | sort displayName: Show environment variables

Related discussion:
text: The script was only applied to the default pullrequest travis-ci configuration.
As shown in , the CPUs assigned to each job may have some performance difference: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz The clock-rate 2.4 GHz vs 2.5 GHz shouldn't make any noticeable difference though (this would at most slow down by 7.2 minutes out of 3 hours if everything is CPU-bound). It is not enough to explain the timeout in .
I was working on recently for this where it periodically prints out the CPU usage as a percentage for the whole system (aka 1 core on a 4 core machine is 25%). I only got Linux/OSX working though and was unable to figure out a good way to do it on Windows. My thinking for how we'd do this is probably download a binary near the beginning of the build (or set up some script). We'd then run just before we run . That way we could correlate the two timestamps of each log (the main log and the to similar moments in time. Initially I was also thinking we'd just at the end of the build and scrape it later if need be.
Code change:
modified: Option<SystemTime>, } <del> #[derive(Copy, Clone, PartialEq, Eq, Hash, Debug)] </del> <ins> #[derive(Copy, Clone, Eq, Debug)] </ins> pub struct FileType { mode: mode_t, } <ins> impl PartialEq for FileType { fn eq(&self, other: &Self) -> bool { self.masked() == other.masked() } } impl core::hash::Hash for FileType { fn hash<H: core::hash::Hasher>(&self, state: &mut H) { self.masked().hash(state); } } </ins> #[derive(Debug)] pub struct DirBuilder { mode: mode_t,

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: This currently fails, even though no symlinks are involved. This is because on Unix are currently compared on the totality of their contained unix , which are bitflags of the form (in octal) where is a Unix permission mode and the actual file type. As of now, depending on how the is built, may be either (from ) or set to the actual file permission mode (if built from ). (This bug was co-investigated with <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label: +T-libs-api + Libs-Small
Error: Parsing relabel command in failed: ...'libs-api +' ' Libs-Smal'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
label: +T-libs-api +Libs-Small
Error: Label Libs-Small can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
label: +T-libs-api
Code change:
#[no_mangle] fn __rustc_plugin_registrar(reg: &mut Registry) { reg.lint_store.register_lints(&[&TEST_LINT]); <del> reg.lint_store.register_early_pass(|| box Pass); </del> <ins> reg.lint_store.register_early_pass(|| Box::new(Pass)); </ins> } ```

Related discussion:
text: There is no such thing as boxsyntax anymore :D <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
does the same.
It probably makes sense to search across the repository (including submodules) any references to this removed feature and remove them
claim