jiebi/CodeConvo huggingface dataset:
Change:
// In the algorithm above, we can change // cast(relative_tag) + niche_variants.start() // into <del> // cast(tag) + (niche_variants.start() - niche_start) </del> <ins> // cast(tag + (niche_variants.start() - niche_start)) </ins> // if either the casted type is no larger than the original // type, or if the niche values are contiguous (in either the // signed or unsigned sense). <del> let can_incr_after_cast = cast_smaller || niches_ule || niches_sle; </del> <ins> let can_incr = cast_smaller || niches_ule || niches_sle; </ins> let data_for_boundary_niche = || -> Option<(IntPredicate, u128)> { <del> if !can_incr_after_cast { </del> <ins> if !can_incr { </ins> None } else if niche_start == low_unsigned { Some((IntPredicate::IntULE, niche_end))

Discussion:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign
Change:
<ins> error: cannot determine resolution for the import --> $DIR/shadow-glob-module-resolution-4.rs:13:5 | LL | use b::C as e; |     ^^^^^^^^^ error: cannot determine resolution for the import --> $DIR/shadow-glob-module-resolution-4.rs:13:5 | LL | use b::C as e; |     ^^^^^^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0432]: unresolved import `b::C` --> $DIR/shadow-glob-module-resolution-4.rs:13:5 | LL | use b::C as e; |     ^^^^^^^^^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0432`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: inconsistent resolution for an import', 'error: internal compiler error: inconsistent resolution for an import' 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: [resolverforlowering_raw] getting the resolver for lowering --
Isn't this example identical to EDIT: oh I see, the PR that closes doesn't actually have this test, so it's possible this is a different ICE.
This one has an additional which indeed causes the ICE to trigger again :laughing:
Regression in nightly-2020-11-09 commit[0] 2020-11-07: Auto merge of - Mark-Simulacrum:debug-asserts, r=pietroalbini commit[1] 2020-11-07: Auto merge of - Mark-Simulacrum:revert-, r=petrochenkov commit[2] 2020-11-08: Auto merge of - petrochenkov:mergetarg, r=Mark-Simulacrum commit[3] 2020-11-08: Auto merge of - lcnr:revert75443, r=nikomatsakis commit[4] 2020-11-08: Auto merge of - m-ou-se:rollup-3jp1ijj, r=m-ou-se commit[5] 2020-11-08: Auto merge of - petrochenkov:visitok, r=Aaron1011

<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' 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: [resolverforloweringraw] getting the resolver for lowering --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc as this looks 99% like and you fixed that one recently ^^
claim. I will investigate it in my spare time.
Change:
&mut self, bugs: impl IntoIterator<Item = Diagnostic>, explanation: impl Into<DiagnosticMessage> + Copy, <ins> panic_with: impl Any + Send + 'static, </ins> ) { let mut no_bugs = true; for mut bug in bugs {

Discussion:
With beta but nightly does not show backtraces: edits this is with prioritize
can you share your example code, as it doesn't seem that all ICEs are missing backtraces: on the same nightly and beta, and which has a backtrace on both. (if you have the time to do so and a master checkout, it'd be interesting to know whether ThinLTO could be involved like in ; bisection would also be worthwhile)
Hmm interesting, maybe its' something that only happens with :thinking: does not show a backtrace for me ! I also can't force it with or anything :(
This backtrace was removed on purpose in because it's useless. It just points at the place in the error machinery where delayed bugs get flushed, which is either just noise or misleading at worse.
This also affects explicit calls too -- these should be restored in . Regarding s backtraces being useless, see .
Change:
<ins> error[E0308]: mismatched types --> $DIR/suggest-ref-macro.rs:8:1 | LL | #[hello] | ^^^^^^^^ expected `&mut i32`, found integer | = note: this error originates in the attribute macro `hello` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0308]: mismatched types --> $DIR/suggest-ref-macro.rs:15:11 | LL |         x(123); |           ^^^ |           | |           expected `&mut i32`, found integer |           help: consider mutably borrowing here: `&mut 123` ... LL |     bla!(); |     ------- in this macro invocation | = note: this error originates in the macro `bla` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0308]: mismatched types --> $DIR/suggest-ref-macro.rs:26:10 | LL |     bla!(456); |          ^^^ |          | |          expected `&mut i32`, found integer |          help: consider mutably borrowing here: `&mut 456` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
The tokens generated by procmacro (e.g. from ) use , which makes some suggestions produce invalid output: It's a bit tricky, because this callsite span does point into the current crate (to ), so this situaiton isn't detected in the same way as external .
Looks like should be used in more places. That one detects this span by checking if is a dummy or imported.
I'm working on a fix specifically for these typeck/borrowing suggestions. Not sure how many other suggestions have the same problem.
this is a prevalent problem. We need to add metadata to spans to distinguish call sites explicitly in an easy way and always ignore suggestions in them.
Change:
| note: required by a bound in `File::open` --> $SRC_DIR/std/src/fs.rs:LL:COL <ins> help: consider removing this method call, as the receiver has type `&Path` and `&Path: AsRef<Path>` trivially holds | LL -             let mut f = File::open(path.to_str())?; LL +             let mut f = File::open(path)?; | </ins> error: aborting due to 1 previous error

Discussion:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment
Change:
} else { curl.arg("--progress-bar"); } <ins> // --retry-all-errors was added in 7.71.0, don't use it if curl is old. if curl_version() >= semver::Version::new(7, 71, 0) { curl.arg("--retry-all-errors"); } </ins> curl.arg(url); if !self.check_run(&mut curl) { if self.build.contains("windows-msvc") {

Discussion:
We're passing --retry: but by default that only retries 500 errors, not any error: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is a regression from when I moved the downloads from python to rust (about a year ago now I think).
Mentoring instructions: Add the option to the invocations, in and This doesn't affect the Windows Powershell fallback, since we already retry on any error. There are many other invocations across the repo, but they seem to not be causing problems.
claim
This is quite new flag shipped with recent versions of curl, which is not supported on many machines/platforms(including our CI runners). We can consider using as I also suggest at
I'd like to take a look at this. Looking through the PR history, we would like basic retry logic written in Rust versus using a curl flag like to retry during the bootstrap process. If it's a 404, then do not retry, but any other errors should be retried. I assume there is a http library already vendored in, so no new dependencies should be .
claim
Thanks! This shouldn't be needed. For now, retrying on "connection refused" () should be fine.
I'm a little confused as to why was closed then. What more is there beyond adding the retry refused connections flag?
I forgot that our CI runners depend on very old curl versions which doesn't support the flag I suggested. Sorry, you are right. As jyn also said() in that PR, we can handle this in Rust
are we ok with adding the dependency to facilitate sending requests to the payload URL? I'm very hesitant to add another crate dependency to the core payload. But without it, we would need to manually built a request via the standard library tcp library. Which is a little awkward. doesn't actually have support for sending requests. I suppose, in the case we decide to use it, another library would need to be as well?
What about using curl arguments to read the status code and handle it in rust logic? It might be a bit ugly, but adding a dependency solely for this purpose seems like overkill to me.
I agree adding a new dep seems extreme.

I can try parsing the curl exit code, great idea.
claim
claim
Hello Is this still relevant?
please don't ping me about rust-lang/ issues. is the current maintainer.
We didn't change any curl flags since then; it should be still relevant.
release-assignment
Change:
BinOp(token::Or) => IsInFollow::Yes, Ident(name, false) if name == kw::As || name == kw::Where => IsInFollow::Yes, <del> _ => IsInFollow::No(tokens), </del> <ins> _ => IsInFollow::No(TOKENS), </ins> }, TokenTree::MetaVarDecl(_, _, frag) if frag.name == sym::block => IsInFollow::Yes, <del> _ => IsInFollow::No(tokens), </del> <ins> _ => IsInFollow::No(TOKENS), </ins> } }, "ident" | "lifetime" => {

Discussion:
E.g. in a vec is created, only to be thrown away if the macro actually works out. I think we can just turn most places into an early return in the happy path and then only allocate in the error path. Do not work on this issue before is merged. Also, hasn't had its docs updated to reflect the source changes.
Are there any reasons to not use constant/static slices and convert them to vecs on demand? Or maybe even convert to something like so there's no need to allocate vecs (In all cases) anymore?
That's a great idea! I haven't checked whether it'll work everywhere, but I think it should.
Change:
<ins> // Regression test for https://github.com/rust-lang/rust/issues/56445#issuecomment-629426939 // check-pass #![crate_type = "lib"] use std::marker::PhantomData; pub struct S<'a> { pub m1: PhantomData<&'a u8>, pub m2: [u8; S::size()], } impl<'a> S<'a> { pub const fn size() -> usize { 1 } pub fn new() -> Self { Self { m1: PhantomData, m2: [0; Self::size()], } } } </ins>

Discussion:
ICE message: <details<summaryBacktrace</summary</summary
This should be erroring in exhaustiveness checking; shouldn't be allowed there. cc
It should be erroring earlier, when trying to create a pattern out of the constant. And it should also not be considered structural-match type-wise.
Triage: This is no longer ICE, seems that it's fixed by , marking as E-needs-test.

gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

I got an internal compiler error at commit . I dont know how to minimize it. Relevant code is: If I remove the const field and directly put the array size like below, the ICE goes away and I get the expected compilation error that [u8; 68] is not . <details<summaryBacktrace:</summary</details<details<summaryVersion info</summary</details
The ICE also goes away if I change to
Ok. I minimized it to just: It ICEs on latest nightly:
triage: P-high, assiging to self, removing nomination label
Following example fails to compile: <details<summaryError</summary</detailsEven if I add , still issue: or <details<summaryError</summary</detailsBut this works:
Also just got this; no idea how to minimize it and the trace doesn't seem useful:-
If this is referring to the field , it's defined as where is defined inside the impl as .
Inlining resolves the error, ie changing buffer's definition to .
no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.
Change:
Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. <del> Last change is for: https://github.com/rust-lang/rust/pull/129116 </del> <ins> Last change is for: https://github.com/rust-lang/rust/pull/129788 </ins>

Discussion:
Trying to run fails right now: It works fine in other checkouts though. The error is correct, there is no such file -- so I guess some other part of bootstrap failed to create that file? fails with the same error. I am on commit , is clean. Reverting back to fixes this, so seems like is the cause of the problem. Cc
I think that this is the issue: as bootstrap probably uses an old version in your checkout. Can you configure the remote? Otherwise you might be using an old/weird version of anyway, regardless of the new error.
The remote is configured. The warning just can't deal with worktrees (). But I think that's orthogonal as I got the warning already before that most recent PR. I don't think also affects fetching the right LLVM version.
Ah, I see, it's the worktree issue. Well, it is orthogonal in a way, but the issue is that bootstrap now assumes that you have a recent-ish archive, because we have some config file to it that is now being checked by bootstrap. Since in your case, bootstrap can't detect the master commit, is is probably also unable to download the correct (recent) ci-llvm archive. Therefore, it probably uses some old archive that misses the config file, and that causes bootstrap to fail. When implementing the config checking, we assumed that if you are on a commit that includes the new checks, then you also have to use a recent ci-llvm. But if git detection is somehow not working, then it's possible to be on a new commit that performs the check, but also to have an old ci-llvm archive at the same time.
Bootstrap can detect the master commit just fine I think. ci-llvm has worked perfectly fine in worktrees for years. The warning has its own logic for checking whether the master commit is outdated, and only that logic is faulty.
Sorry, then I got it wrong, it was a red herring. I actually just checked that it also doesn't work for me (nor anyone else, probably). Let's quickly revert then.
That said, something also changed with remote branch logic recently that broke it in worktrees -- did the right thing on worktrees for years, but now it formats 5k files.
How exactly can we reproduce this? Running on a fresh build works for me.

I assume you have the old directory where it was unpacked with old bootstrap logic.
I see. It works when you newly extract , but not with an already extracted directory. So removing the directory (or just doing ) is a workaround.
suffices and avoids having to re-download and re-build everything.
Change:
<ins> // Test for #95898: The trait suggestion had an extra `:` after the trait. // edition:2021 fn foo<T:>(t: T) { t.clone(); //~^ ERROR no method named `clone` found for type parameter `T` in the current scope } fn main() {} </ins>

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Note: The bound is treated incorrectly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
You mean that does not handle correctly, right?
Correct, the suggestion reads which is not syntactical. The fix would be to detect this case and correctly suggest
It's my first time contributing and i was taking a look at and didn't find a way to detect . So i ended up adding a flag to , setting it in and checking the flag in to handle the case. Does that seem reasonable?
Adding a new flag to seems a bit heavy. I was thinking you could one of the methods on  to detect if there is a colon following the generic param. Also hmm... I think was also looking at ... I opened up this issue before he said that he was trying to , though I'm not sure if in general or just a specific case in something he was working on (i.e. another suggestion). Perhaps he could comment to see if he's already solved this, in order to deduplicate work?
So. I was fixing the same problem in and I just got a working fix! My solution is to use in order to find the span of . It may be hacky, but I think it's good enough for diagnostics. It seems like my fix doesn't fix this issue, because this suggestion is created using different API (), but it should be easy to extend it to this case too. For example could use internally ( produces better suggestions anyway :D). I'll try to clean my fix & create a PR today.
I took a look at your PR, that's way better than my solution. I will use the method you to to fix this issue if you aren't working on it as well.
Change:
self.get_crate_data(cnum).get_proc_macro_quoted_span(id, sess) } <ins> /// Decodes all traits in the crate (for rustdoc). </ins> pub fn traits_in_crate_untracked(&self, cnum: CrateNum) -> impl Iterator<Item = DefId> + '_ { self.get_crate_data(cnum).get_traits() } <ins> /// Decodes all trait impls in the crate (for rustdoc). </ins> pub fn trait_impls_in_crate_untracked( &self, cnum: CrateNum, ) -> impl Iterator<Item = (DefId, DefId, Option<SimplifiedType>)> + '_ { self.get_crate_data(cnum).get_trait_impls() } <ins> /// Decodes all inherent impls in the crate (for rustdoc). pub fn inherent_impls_in_crate_untracked( &self, cnum: CrateNum, ) -> impl Iterator<Item = (DefId, DefId)> + '_ { self.get_crate_data(cnum).get_inherent_impls() } </ins> } impl CrateStore for CStore {

Discussion:
Running on nightly causes an ICE. Judging by my for PRs this broken between 2 and 4 days ago (26th-28th Jan). See attached minified project: . Essentially, this is: <details<summary<strongBacktrace</strong</summary<p</p</details
I see the same on Docs build fine with latest stable (1.58.1), but I get the same error with
This is probably a duplicate of , right? The fix for that () isn't in yesterday's (2022-01-29) nightly yet, but should be in today's.
I get the same error with , which does include .
works for me on aarch64-apple-darwin, but not on
There are definitely three crates still hitting this ICE on (at least based on message, and backtrace in 2 cases, but I couldn't reproduce on when testing locally) in
You can use () in your code to figure out what change caused this regression.
Not so surprisingly bisection reveals as the cause.
I'm not sure if this is helpful, but this is the stack I get when attempting to run rustdoc with nightly (which is the most recent nightly available on macOS). I also get the same build failure in CI with . This error comes from building the docs on
Fixed in
Assigning same priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
It seems this issue has regressed recently? Hitting the same ICE on . <details<summary<strongBacktrace</strong</summary<p</p</details
The recent regression should be fixed by , most likely.
Change:
<ins> // ignore-android // ignore-cloudabi // ignore-emscripten // ignore-sgx </ins> #![feature(rustc_private)] fn main() {

Discussion:
With the change in function shouldrunsuccessfully() of commit : RunPass =true, Ui == Some(PassMode::Run), RunPass | Ui =self.effectivepass_mode() == Some(PassMode::Run), The test cases under run-pass directory are tested for building only, the compiled test cases are not running any more. Does it work as design?
Oh. This is bad. Will fix today. cc (on vacation)
Fixed in
Change:
# x86_64-unknown-linux-gnu configuration CC_x86_64-unknown-linux-gnu=$(CC) <del> LINK_x86_64-unknown-linux-gnu=cc </del> CXX_x86_64-unknown-linux-gnu=$(CXX) CPP_x86_64-unknown-linux-gnu=$(CPP) AR_x86_64-unknown-linux-gnu=$(AR)

Discussion:
Appears like: Essentially, 'LINK_foo' is empty. Heres a list:
I think this is your issue. (I ran into it myself while doing a build)
Dup of , apparently.
I believe this will be fixed by
Closing as a duplicate.