jiebi/CodeConvo huggingface dataset:
Change:
use rustc::lint; use rustc::mir::{Field, BorrowKind, Mutability}; use rustc::mir::{UserTypeProjection}; <del> use rustc::mir::interpret::{GlobalId, ConstValue, sign_extend, AllocId, Pointer}; </del> <ins> use rustc::mir::interpret::{GlobalId, ConstValue, get_slice_bytes, sign_extend}; </ins> use rustc::traits::{ObligationCause, PredicateObligation}; use rustc::ty::{self, Region, TyCtxt, AdtDef, Ty, UserType, DefIdTree}; use rustc::ty::{CanonicalUserType, CanonicalUserTypeAnnotation, CanonicalUserTypeAnnotations}; use rustc::ty::subst::{SubstsRef, GenericArg}; <del> use rustc::ty::layout::{VariantIdx, Size}; </del> <ins> use rustc::ty::layout::VariantIdx; </ins> use rustc::hir::{self, RangeEnd}; use rustc::hir::def::{CtorOf, Res, DefKind, CtorKind}; use rustc::hir::pat_util::EnumerateAndAdjustIterator;

Discussion:
Results in cc
modify labels: I-ICE C-Bug T-compiler A-const-generics
I'm looking into this currently.
Partially as a note to myself and partially as an update to anyone interested The root cause of this bug seems to be the fact that we currently don't explicitly handle slice const values in , and therefore we always say they cannot match. This error eventually bubbles up to to produce all three errors.
Change:
var OUTPUT_DATA = 1; var params = getQueryStringParams(); <del> // Set the crate filter from saved storage, if the current page has the saved crate filter. // // If not, ignore the crate filter -- we want to support filtering for crates on sites like // doc.rust-lang.org where the crates may differ from page to page while on the same domain. var savedCrate = getCurrentValue("rustdoc-saved-filter-crate"); if (savedCrate !== null) { onEachLazy(document.getElementById("crate-search").getElementsByTagName("option"), function(e) { if (e.value === savedCrate) { document.getElementById("crate-search").value = e.value; return true; } }); } </del> // Populate search bar with query string search term when provided, // but only if the input bar is empty. This avoid the obnoxious issue // where you start trying to do a search, and the index loads, and

Discussion:
Right now it is allowed to select whether we want to search within all crates or in the specific ones (e.g. core, std, etc). It would be really useful to remember the selected option, because in most cases we want to search in the std crate only. cc
Good idea!
Does not work, neither in stable nor nightly. Go to Choose the "std" option. Type Option, click on it We still see the "All crates" on the , and if we try to search something else, results will be from all sources anyway.
Indeed, will take a look quickly.
Works perfectly now. Thanks!
Change:
<del> error: expected `{`, found `<-` </del> <ins> error: unexpected token: `<-` </ins> --> $DIR/placement-syntax.rs:3:9 | LL |     if x<-1 { <del> |     --  ^^ expected `{` |     | |     this `if` statement has a condition, but no block </del> <ins> |         ^^ help: if you meant to write a comparison against a negative value, add a space in between `<` and `-` | LL |     if x< -1 { |         ^^^ </ins> error: aborting due to previous error

Discussion:
produces: It would be nice if it produced a suggestion to split it up: (This , but was broken in a previous change.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi I'd like to try this one. Just found the removed suggestion.
claim
assign Hmm, triagebot is not well...
It doesn't look like you're still working on this. Is it ok if I take over?
Sure. Thanks for your help.
Change:
} } <ins> struct RawPtrDerivingVisitor<'a> { cx: &'a Context<'a> } impl<'a> Visitor<()> for RawPtrDerivingVisitor<'a> { fn visit_ty(&mut self, ty: &ast::Ty, _: ()) { static MSG: &'static str = "use of `#[deriving]` with a raw pointer"; match ty.node { ast::TyPtr(..) => self.cx.span_lint(RawPointerDeriving, ty.span, MSG), _ => {} } visit::walk_ty(self, ty, ()); } // explicit override to a no-op to reduce code bloat fn visit_expr(&mut self, _: &ast::Expr, _: ()) {} fn visit_block(&mut self, _: &ast::Block, _: ()) {} } fn check_raw_ptr_deriving(cx: &Context, item: &ast::Item) { if !attr::contains_name(item.attrs.as_slice(), "deriving") { return } match item.node { ast::ItemStruct(..) | ast::ItemEnum(..) => { let mut visitor = RawPtrDerivingVisitor { cx: cx }; visit::walk_item(&mut visitor, item, ()); } _ => {} } } </ins> static crate_attrs: &'static [&'static str] = &[ "crate_type", "feature", "no_start", "no_main", "no_std", "crate_id", "desc", "comment", "license", "copyright", // not used in rustc now

Discussion:
In the following, the does the wrong thing: it shallow copies the pointer when the semantics mean it should be making a new allocation and copying the data; there's no indication of this until runtime double-frees/segfaults. Some possible resolutions: do nothing: unsafe code is unsafe have lints for + unsafe pointers have completely disabled on unsafe pointers remove the trait impls for raw pointers
I favor a lint.
(I'm happy to mentor this.)
I'm interested in doing this. I'll find on IRC.
Change:
let span = self.tcx.def_span(generator_did); // Do not ICE on closure typeck (#66868). <del> if let None = self.tcx.hir().as_local_hir_id(generator_did) { </del> <ins> if self.tcx.hir().as_local_hir_id(generator_did).is_none() { </ins> return false; }

Discussion:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test
Change:
let span = self.tcx.def_span(generator_did); // Do not ICE on closure typeck (#66868). <del> if let None = self.tcx.hir().as_local_hir_id(generator_did) { </del> <ins> if self.tcx.hir().as_local_hir_id(generator_did).is_none() { </ins> return false; }

Discussion:
paniked when I tried to use GAT, I didn't know does not support it then. Anyway I think it is not supposed to panic. I have confirmed with version 1.39 on Windows, my PC version 1.36 on Linux. It said,
Seems a duplicate of , I did not noticed it when I was opening this issue, sorry. There is also a small difference that I did not turn on
cc &
This should be fixed in the next nightly

This is a toy example I made in order to later make tests which run for with . This is the error I get: Error notes: - compiler flags: I don't know if this kind of pattern is intended as part of the feature or in its future, but if not, I think it can be satisfied by using a procedural macro so that's probably alright. The point of the pattern, as I mentioned at the beginning of the post, is to be able to test a particular generic type's implementation up to an arbitrary range of numeric constants. While implementing another project to help test the feature, I stumbled upon the problem of wanting to test hundreds of different constants, but having no way of doing so with say, a loop over a range of constants. This is one way I thought of making it work. Am I making the right decisions here? How should I go about testing hundreds of constants? Thanks :)
Note: another example that also panics. I know, yes, expressions aren't yet supported as const parameters. But it has the same panic, which is WEIRD! When I wrote this one, I thought "okay maybe inside a statement, the compiler won't try things like because the case when is is already covered... and with exhaustiveness check it should know that N = 0 won't enter the second branch". But I must be wrong there, or otherwise how did it panic? Error:
Minified: I'm pretty sure that I saw this ICE before, but I can't find it ;/
This is just a result of having an expression () as a const generic argument. I don't actually think there's a canonical issue, though many of the issues are essentially the same. is the best tracking issue.
No longer ICEs on the latest nightly
Oh, the new output is interesting. It probably needs to be monomorphized so that the compiler detects the infinite recursion. And then we could also write one that doesn't have infinite recursion :3 In order to force an error, a test function should suffice right?
What do you mean?
I mean that I imagined it might detect that the function recurses infinitely onto itself. But I guess it reads it lazily, and lets monomorphization do the job of recursing the function? which would make a lot of sense to me.
Change:
padding: 15px 0; } <del> .content.source pre.rust { </del> <ins> .source .content pre.rust { </ins> white-space: pre; overflow: auto; padding-left: 0;

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:
/// dependencies. This is largely just a wrapper around `cargo doc`. pub fn rustc(build: &Build, stage: u32, target: &str, out: &Path) { println!("Documenting stage{} compiler ({})", stage, target); <ins> t!(fs::create_dir_all(out)); </ins> let compiler = Compiler::new(stage, &build.config.build); let out_dir = build.stage_out(&compiler, Mode::Librustc) .join(target).join("doc"); let rustdoc = build.rustdoc(&compiler); <del> if !up_to_date(&rustdoc, &out_dir.join("rustc/index.html")) { </del> <ins> if !up_to_date(&rustdoc, &out_dir.join("rustc/index.html")) && out_dir.exists() { </ins> t!(fs::remove_dir_all(&out_dir)); } let mut cargo = build.cargo(&compiler, Mode::Librustc, target, "doc");

Discussion:
fails with: Note that there is no directory in Creating that directory fixes this problem but leads to another problem: This is because there is no directory in , which the tool tries to (checked with ). Creating that directory fixes the problem. Note that for stage 2, all directories starting at needed to be created.
Oh dear yeah this isn't tested very well so I wouldn't be surprised if it breaks every now and then, thanks for the report!
oops
Yeah, I expected that (the not very well tested) so when I needed to build the compiler docs I decided to try using rust build by that. By the way, I'm a little confused by the following: The rustbuild configuration includes a key, which is also present in the struct as , however the field .
Oh there should probably be a line in which adds that target to a dependency of the target, probably just got lost along the way somewhere by accident :(
Change:
<ins> // Reproduce the issue with vec pub struct NoDerives; fn fun1(foo: &mut Vec<NoDerives>, bar: &[NoDerives]) { foo.extend_from_slice(bar); //~ ERROR } // Reproduce the issue with vec // and demonstrate that other derives are ignored in the suggested output #[derive(Default, PartialEq)] pub struct SomeDerives; fn fun2(foo: &mut Vec<SomeDerives>, bar: &[SomeDerives]) { foo.extend_from_slice(bar); //~ ERROR } // Try and fail to reproduce the issue without vec. // No idea why it doesnt reproduce the issue but its still a useful test case. struct Object<T, A>(T, A); impl<T: Clone, A: Default> Object<T, A> { fn use_clone(&self) {} } fn fun3(foo: Object<NoDerives, SomeDerives>) { foo.use_clone(); //~ ERROR } fn main() {} </ins>

Discussion:
Given the following code: The current output is: Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
error: expected one of `,`, `::`, `as`, or `}`, found `.` <del> --> $DIR/similar-tokens.rs:11:10 </del> <ins> --> $DIR/similar-tokens.rs:9:10 </ins> | LL | use x::{A. B}; |          ^

Discussion:
Was reported here : but still occurring. <!-- 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
Simpler repro: ()
I assume this repros for any non-ascii character, right? I tried with ü, ß, and , and I was able to repro.
Correct :) é was just the character my big fingers typed when I found that bug!
Assigning and removing as .20.E2.80.A6) in the prioritization working group.
This is a regression since modify labels: +regression-from-stable-to-stable
Change:
} #[naked] <del> fn naked(x: usize, y: usize) { zzz(); // #break </del> <ins> extern "C" fn naked(x: usize, y: usize) { unsafe { asm!("ret"); } // #break </ins> } <del> fn zzz() { () } </del>

Discussion:
The test is failing on AArch64's CI:
ping arm
Hey ARM Group! This bug has been identified as a good "ARM candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Just like with every LLVM update it might fix itself or get worse after
The test is causing an infinite loop due to the link register being updated during the call to zzz, that call is causing the link register to be the ret instruction after that call, the ret instruction then returns to the link register causing an infinite loop. Normally before the call the link register would be saved and then restored after the call, however due to this being a naked function that isn't happening. The emitted LLVM IR is just calling the function and that call isn't preserving anything so this could change in a future version of LLVM I suppose. Although with c++ and clang that code would fail to compile as you can only use asm inside a naked function. suggests it's a bug in rustc for allowing the code to compile, is that still your understanding? I also suspect it's why this was raised. I can get the test to pass, but I'm wondering if the test is actually correct in it's current state. EDIT: It's probably worth pointing out that the code in that test will segfault on x86_64
The test is definitely incorrect. Using anything other than inline asm in a naked function is UB.
Change:
checksum = "56dee185309b50d1f11bfedef0fe6d036842e3fb77413abef29f8f8d1c5d4c1c" [[package]] <ins> name = "ui_test" version = "0.1.0" dependencies = [ "colored", "crossbeam", "lazy_static", "pretty_assertions 1.2.1", "regex", "rustc_version", ] [[package]] </ins> name = "unic-char-property" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.
Change:
use rustc_middle::ty::{self, GenericParamDefKind, InferConst, Ty, TyCtxt}; use rustc_middle::ty::{ConstVid, FloatVid, IntVid, TyVid}; use rustc_span::symbol::Symbol; <del> use rustc_span::Span; </del> <ins> use rustc_span::{Span, DUMMY_SP}; </ins> use std::cell::{Cell, Ref, RefCell}; use std::fmt;

Discussion:
should be to guarantee that we emit an error when that flag is set. This is already done for of other types in rustc. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
renamed to to keep consistent.
Change:
<ins> // edition:2018 async fn free(); //~ ERROR without a body struct A; impl A { async fn inherent(); //~ ERROR without body } trait B { async fn associated(); //~^ ERROR cannot be declared `async` } impl B for A { async fn associated(); //~ ERROR without body //~^ ERROR cannot be declared `async` //~| ERROR incompatible type for trait } fn main() {} </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from cargo-bisect-rustc: searched nightlies: from nightly-2020-03-09 to nightly-2020-04-03 regressed nightly: nightly-2020-03-16 searched commits: from to regressed commit:
Maybe due to cc
Fixed by
Change:
}); buf.push_str(&part.snippet); let cur_hi = sm.lookup_char_pos(part.span.hi()); <del> if prev_hi.line == cur_lo.line { </del> <ins> if prev_hi.line == cur_lo.line && cur_hi.line == cur_lo.line { </ins> // Account for the difference between the width of the current code and the // snippet being suggested, so that the *later* suggestions are correctly // aligned on the screen.

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. --Rebase over , then run . I think this is the test. cc but I think this is an issue with rustcerrors, not clippy itself. <!-- 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 is from a diagnostic constructed in a pre-expansion pass. Maybe this has something to do with the ICE
I'm able to reproduce this by running with the following contents: And it needs .
I thought this had been solved by a recent PR :(
No, I just avoided a malformed span that was hitting the same ICE The ICE itself will occur for any multi line span where the end is to the left of the start:
Change:
tcx.interpret_interner.intern_at_reserved(alloc_id, allocation); if let Some(glob) = Option::<DefId>::decode(self)? { <ins> trace!("connecting alloc {:?} with {:?}", alloc_id, glob); </ins> tcx.interpret_interner.cache(glob, alloc_id); }

Discussion:
It's not clear yet whether mir interpretation is the culprit or some changes that crept into the same PR. Perf data: cc [ ] tuple-stress max: 109.4% clean-incremental is a 100% hit! The rest are small. [ ] tuple-stress-opt max: 109.1% same, clean-incremental is a 100% hit! [ ] encoding-opt max: 97.6% clean incremental-opt patched incremental: println-opt [ ] encoding max: 94.9% clean is ~ 20%, as is baseline incremental incremental cases are almost 100% [ ] coercions-opt max: 74.6% pretty universally bad, though incremental hurts worse [ ] coercions max: 66.6% pretty universally bad, though incremental hurts worse [ ] html5ever-opt max: 41.3% incremental [ ] inflate max: 40.4% universally bad, though incremental hurts worse [ ] regex-opt max: 4.7% patched incremental: byte frequencies-opt [ ] script-servo-opt max: 12.1% clean incremental-opt [ ] script-servo max: 11.6% clean incremental [ ] inflate-opt max: 11.6% incremental cases primarily
I'm going to start with ...
It would be good to dig into those use cases -- in particular, if you open them, we can see which of them are incremental use cases and which are not.
I just updated the tracking issue with that information. Most of them are incremental cases.
OK, for it's pretty clear: 58% of the execution time are spent in called from . Does that ring a bell, I haven't had time yet to really look at the code in question.
We might simply be encoding more constants now (that were previously encoded as HIR). I'll have to look at the exact logs (rustcmir::interpret::consteval=debug to just get the entry points). I'll check tomorrow morning
Ok. I found the issue. We don't seem to be loading constants from the cache. So the enormous regressions are from recomputing all constants, even if nothing changed in the code at all. That should be easy enough to fix
Only the incremental regressions were fixed. I'll investigate the others, too New perf data:
There have been a lot of perf optimizations for const eval over the last year. I think we're good now
Change:
<ins> // run-pass #![allow(dead_code)] trait Range { const FIRST: u8; const LAST: u8; } struct OneDigit; impl Range for OneDigit { const FIRST: u8 = 0; const LAST: u8 = 9; } struct TwoDigits; impl Range for TwoDigits { const FIRST: u8 = 10; const LAST: u8 = 99; } struct ThreeDigits; impl Range for ThreeDigits { const FIRST: u8 = 100; const LAST: u8 = 255; } fn digits(x: u8) -> u32 { match x { OneDigit::FIRST...OneDigit::LAST => 1, TwoDigits::FIRST...TwoDigits::LAST => 2, ThreeDigits::FIRST...ThreeDigits::LAST => 3, _ => unreachable!(), } } fn main() { assert_eq!(digits(100), 3); } </ins>

Discussion:
This code demonstrates the problem (): With stable-1.32.0 it prints . With beta-1.33.0 it wrongly prints . Beta also produces these wrong warnings: It seems that Rustc decides, that the first arm covers the whole range of a and optimizes out the other arms before they even reach MIR. The code is very similar to this . But the testcase does not test that the other arms can be reached. I was able to bisect the regression to . (This issue seems similar to , but the reduced testcase there does not use any associated consts)
Not the same as
triage: P-high, A-NLL, NLL-complete, assigning to self.
cc
I have confirmed that the bug appears to be specifically injected by commit (I've skimmed over that commit several times and still can't see the problem, but I'm going to try again now. Maybe the actual issue is that we are miscompiling downstream, but that pattern is not sufficiently exercised elsewhere in the compiler today...)
Well this is making my spidey-sense tingle: but even when that returns false, it seems like that would only imply that we fall through to presumably more general purpose code here: (still looking. Going to add a bit of instrumentation to these parts of the compiler.)
I don't mean to step on any toes, but I looked into this a little as an earlier PR of mine introduced it. I've got a fix up at but if that's not the approach we want to take then I can leave this to you.