jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: expected one of `,`, `.`, `?`, or an operator, found `some` --> $DIR/assert-trailing-junk.rs:6:18 | LL |     assert!(true some extra junk, "whatever"); |                  ^^^^ expected one of `,`, `.`, `?`, or an operator here error: expected one of `,`, `.`, `?`, or an operator, found `some` --> $DIR/assert-trailing-junk.rs:9:18 | LL |     assert!(true some extra junk); |                  ^^^^ expected one of `,`, `.`, `?`, or an operator here error: no rules expected the token `blah` --> $DIR/assert-trailing-junk.rs:12:30 | LL |     assert!(true, "whatever" blah); |                             -^^^^ no rules expected this token in macro call |                             | |                             help: missing comma here warning: unexpected string literal --> $DIR/assert-trailing-junk.rs:15:18 | LL |     assert!(true "whatever" blah); |                 -^^^^^^^^^^ |                 | |                 help: try adding a comma | = note: this is going to be an error in the future error: no rules expected the token `blah` --> $DIR/assert-trailing-junk.rs:15:29 | LL |     assert!(true "whatever" blah); |                            -^^^^ no rules expected this token in macro call |                            | |                            help: missing comma here warning: macro requires an expression as an argument --> $DIR/assert-trailing-junk.rs:19:5 | LL |     assert!(true;); |     ^^^^^^^^^^^^-^^ |                 | |                 help: try removing semicolon | = note: this is going to be an error in the future warning: unexpected string literal --> $DIR/assert-trailing-junk.rs:22:27 | LL |     assert!(false || true "error message"); |                          -^^^^^^^^^^^^^^^ |                          | |                          help: try adding a comma | = note: this is going to be an error in the future error: aborting due to 4 previous errors </ins>

Discussion:
() Output: Version: 1.34.0 1.35.0 2019-04-15 nightly () Expected: Original report:
26.0 is the first version that accepts this. 1.25.0 rejects it with:
(not really a regression since more code now compiles)
Adding T-compiler since is a built-in.
Opened —it should fix the issue.
triage: P-medium. I'm going to assume we don't need any future-compat machinery for a bug of this nature, unless the crater run on PR indicates that there are occurrences of this mis-use of in the wild.
Change:
<ins> // Test for ICE: mir_const_qualif: index out of bounds: the len is 0 but the index is 0 // https://github.com/rust-lang/rust/issues/125837 use std::fmt::Debug; trait Foo<Item> {} impl<Item, D: Debug + Clone> Foo for D { //~^ ERROR missing generics for trait `Foo` fn foo<'a>(&'a self) -> impl Debug { //~^ ERROR method `foo` is not a member of trait `Foo` const { return } //~^ ERROR return statement outside of function body } } pub fn main() {} </ins>

Discussion:
Similar to but different query stack <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' 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: [mirbuilt] building MIR for [mirconstqualif] const checking --
ICE introduced in . No longer ICEs after , which was a partial revert of
Change:
/// # Examples /// /// ``` <del> /// #![feature(vecdeque_rotate)] /// </del> /// use std::collections::VecDeque; /// /// let mut buf: VecDeque<_> = (0..10).collect();

Discussion:
Currently if you want to rotate a VecDeque n elements to the left or right, you'd have to write something like this: I wonder if it would be possible to add 2 functions: rotateleft(mid: usize) rotateright(mid: usize) You then only have to write: This would be equal to slice's and . It could probably be implemented on a lower level than with pop's and pushes for a little more efficiency.
Ooh, I like this -- is a circular buffer internally, so it should be doable with at most two . EDIT: PR
PR is r+'d, so I turned this into a tracking issue.
I've since the feature replaced any code that used the pop - push technique with the rotate methods. This was fairly easy to do. It's been a few months now, are there any issue's preventing this from landing stable?
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
Is "left" or "right" the word we want to use here? Previously we have deprecated () of in favor of and so that we do not assume the string is laid out from left to right. Here we seem to assume is to while is to ? Are we able to use some words that express the and without assuming a left-to-right layout?
As discussed here, we have to use those names to stay consistent with the slice rotate_{left |right} methods
, sorry I missed that. That makes sense.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
PatternKind::Range { lo, hi, ref end } => { match constructor_covered_by_range( <ins> cx.tcx, </ins> constructor, &lo.val, &hi.val, end.clone(), lo.ty, ) { Ok(true) => Some(vec![]),

Discussion:
The previous version of the crate fails to compile with the error (see the build log). No error nor warning was present in the 1.25 release. Since is actually , the error is wrong and should be fixed. regressed from stable to beta () cc
cc -- initial git log dive notes that this could be related to miri transition? Not sure.
Jup it's a regression. :
Not yet fixed on beta, this needs a backport.
Backported to beta! Thanks!
Change:
<ins> warning: the feature `inline_const_pat` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/pat-match-fndef.rs:1:12 | LL | #![feature(inline_const_pat)] |            ^^^^^^^^^^^^^^^^ | = note: see issue #76001 <https://github.com/rust-lang/rust/issues/76001> for more information = note: `#[warn(incomplete_features)]` on by default error: `fn() {uwu}` cannot be used in patterns --> $DIR/pat-match-fndef.rs:9:9 | LL |         const { uwu } => {} |         ^^^^^^^^^^^^^ error: aborting due to previous error; 1 warning emitted </ins>

Discussion:
(note: this is very similar to but it does appear to be a different ICE) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label +requires-nightly +F-inlineconstpat +requires-incomplete-features

<!-- 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 label +requires-nightly +F-inlineconstpat +requires-incomplete-features
Change:
"src/tools/rls", "src/tools/rust-installer", "src/tools/rustfmt", <ins> // Filter RLS output directories "target/rls", </ins> ]; skip.iter().any(|p| path.ends_with(p)) }

Discussion:
tidy should skip RLS files or even more, it should probably skip untracked files.
This is a regression; it was originally reported at and fixed in .
Hm so to be clear it is currently broken but was previously already fixed? We probably just need to re-add target to the filter_dirs list .
This was changed in by I guess there may be good reasons to remove all these directories, I'd say that we need to skip things that are listed on .gitignore :).
I assumed was only created next to the top level so it could not be visited by tidy anyway. If that's not the case, please feel free to re-add it (with a comment, if possible).
Change:
let mut scope_var_ids = self.guard_bindings.pop().expect("should have pushed at least one earlier"); for var_id in scope_var_ids.drain(..) { <del> assert!( self.guard_bindings_set.remove(&var_id), "variable should be placed in scope earlier" ); </del> <ins> self.guard_bindings_set.remove(&var_id); </ins> } } self.visit_expr(body);

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. --From <!-- 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. --It fails at version: It worked before at version: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Sorry there's no code, but I've narrowed it to somewhere between (working) and (broken).
Likely cause: cc
MCVE: The ICE occurs (inside async blocks or functions) if you're using a match guard and binding the same variable name in both sides of an "or" in a match pattern.
finds a regression in which does correspond to
Assigning .
This ICE is caused here: According to the docs: As we're using a set and a vec in parallel, the ID is pushed twice but stored "only once". Then, we remove it once, and it still exists in the vec but not in the set:
Change:
)); try!(self.pclose()); } <ins> try!(self.print_where_clause(generics)); </ins> try!(word(&mut self.s, ";")); try!(self.end()); self.end() // close the outer-box } else { <ins> try!(self.print_where_clause(generics)); </ins> try!(self.nbsp()); try!(self.bopen()); try!(self.hardbreak_if_not_bol());

Discussion:
(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.
Change:
<ins> #![feature(staged_api)] #![stable(feature = "private_general", since = "1.0.0")] #[unstable(feature = "private_trait", issue = "none")] pub trait Bar {} #[stable(feature = "private_general", since = "1.0.0")] pub struct Foo { // nothing } impl Foo { #[stable(feature = "private_general", since = "1.0.0")] pub fn stable_impl() {} } impl Foo { #[unstable(feature = "private_trait", issue = "none")] pub fn bar() {} #[stable(feature = "private_general", since = "1.0.0")] pub fn bar2() {} } #[stable(feature = "private_general", since = "1.0.0")] impl Bar for Foo {} </ins>

Discussion:
e.g., is missing the file/line/column method docs which are present in beta cc
Removing as this is issue.
Why?
A quick test indicates that copying the source of std::panic::Location out into a no_std crate doesn't fix the problem
Oh wait I don't have the latest nightly
As mentioned in , I'm not sure this should be prioritized under t-compiler's wg-prioritization. If this label is useful for the rustdoc team as well, we could tweak triagebot not to notify on Zulip.
Yeah it seems like it would be useful for us
Hmm so I am unable to reproduce this bug on a self contained no-core file that contains the exact code of aside for changes in the body
Regression range .. Auto merge of - Manishearth:rollup-9gxn4od, r=Manishearth Auto merge of - marmeladema:duration-consts-2, r=oli-obk Auto merge of - oli-obk:mir_const, r=RalfJung Auto merge of - Manishearth:rollup-i7iueu8, r=Manishearth Auto merge of - Manishearth:rollup-10vbpdh, r=Manishearth
Works in Regressing PR is
Rustdoc PRs in that rollup Rollup merge of - Manishearth:re-spotlight, r=GuillaumeGomez Rollup merge of - lzutao:rustdoc-tostring, r=GuillaumeGomez Rollup merge of - GuillaumeGomez:focus-source-file-sidebar, r=kinnison Rollup merge of - GuillaumeGomez:doc-alias-check, r=Manishearth Rollup merge of - euclio:rustdoc-highlighting, r=ollie27,GuillaumeGomez Rollup merge of - alexcrichton:ignore-unstable, r=estebank,GuillaumeGomez Rollup merge of - jyn514:name-resolve-first, r=eddyb
Confirmed, (try build from ) is the culprit
What's happening is that that code erroneously checks the stability of the impl, which apparently is "unstable if it contains unstable items". The "foreign item" check applies to libstd reexporting libcore. It shouldn't.

The minimal reproduction is two crates, one using stability attrs such that an impl has at least one unstable item, and the second crate reexporting the type.
I'm going to take a stab at fixing this.
Change:
#[link(name = "kernel32")] extern "system" { <del> // Functions forbidden when targeting UWP pub fn ReadConsoleW( hConsoleInput: HANDLE, lpBuffer: LPVOID, nNumberOfCharsToRead: DWORD, lpNumberOfCharsRead: LPDWORD, pInputControl: PCONSOLE_READCONSOLE_CONTROL, ) -> BOOL; pub fn WriteConsoleW( hConsoleOutput: HANDLE, lpBuffer: LPCVOID, nNumberOfCharsToWrite: DWORD, lpNumberOfCharsWritten: LPDWORD, lpReserved: LPVOID, ) -> BOOL; pub fn GetConsoleMode(hConsoleHandle: HANDLE, lpMode: LPDWORD) -> BOOL; </del> // Allowed but unused by UWP pub fn GetFileInformationByHandle( hFile: HANDLE,

Discussion:
<!-- 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. --Building std library (-Zbuild-std) with nightly for uwp-windows-msvc targets has been failing with compile errors since around after 17/10/22 I expected to see this happen: Last successeful build on 16/10: Instead, this happened: Lastest failed build: It most recently worked on: rustc 1.66.0-nightly ( 2022-10-14) : <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Hey, is anyone looking into this because ALXR ci (uwp) builds are failing for over a week. Should this issue be posted in another repo?
This is the right repo, but it fell through the cracks for whatever reason. I can get to it this weekend.
Thank you :)
Oh, sorry I missed this! Since 10.0. console functions are available on UWP (see ). So I think the thing to do here is to simply stop making the function conditionally imported.
Change:
ret; } <ins> let lib = c.libdir; let bin = c.bindir; </ins> let target = c.opts.free[2u]; // FIXME: needs stronger pattern matching <ins> // FIXME: needs to uninstall from a specified location in a cache instead // of looking for it (binaries can be uninstalled by name only) </ins> if is_uuid(target) { <del> for os::list_dir(c.libdir).each { |file| </del> <ins> for os::list_dir(lib).each { |file| </ins> alt str::find_str(file, "-" + target + "-") { some(idx) { <del> let full = path::normalize(path::connect(c.libdir, file)); </del> <ins> let full = path::normalize(path::connect(lib, file)); </ins> if os::remove_file(full) { info("uninstalled: '" + full + "'"); } else {

Discussion:
We should be publishing a "default" local- file on rust- (or, at minimum, our github repo for now). When you run cargo for the first time it should fetch this if it hasn't got a local- file, and there should be a "cargo init" command or something that re-fetches this default.
handles this.
Looks like it doesn't auto-fetch yet.
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:issue-27362.rs // ignore-cross-compile extern crate issue_27362; pub use issue_27362 as quux; // @matches issue_27362/quux/fn.foo.html '//pre' "pub const fn foo()" // @matches issue_27362/quux/fn.bar.html '//pre' "pub const unsafe fn bar()" // @matches issue_27362/quux/struct.Foo.html '//code' "const unsafe fn baz()" </ins>

Discussion:
Doc inclusion / doc reexport does not show properly (example: std::cell::Cell::new). Reexport metabug: rustdoc: Pain points of reexports const fn tracker:
Change:
#![feature(const_trait_impl)] #![feature(const_type_id)] #![feature(const_type_name)] <del> #![feature(const_unreachable_unchecked)] </del> #![feature(const_default_impls)] #![feature(duration_consts_2)] #![feature(ptr_metadata)]

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
/// Component directory that Cargo will produce output into (e.g. /// release/debug) fn cargo_dir(&self) -> &'static str { <del> if self.config.rust_optimize { "release" } else { "debug" } </del> <ins> if self.config.rust_optimize.is_release() { "release" } else { "debug" } </ins> } fn tools_dir(&self, compiler: Compiler) -> PathBuf {

Discussion:
It would be nice if we could speed up stage1 library builds by building it with less opts and no debuginfo. had the idea to control this with something like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i'm going to use as a separate more broad issue for - i'll repurpose this to just be for (which is a lot simpler to add)
mentoring instructions: add this option to the struct, then around , set
Can we confirm before we land this support that this is actually a significant win in practice? I recall historically having issues with optimize = false equivalents where the net effect is broken and slower tests - I would prefer to avoid landing support we don't want to actually support :)
this is especially useful in combination with - optimizing only rustc and not std should be a speedup even if we include the time taken for tests.
claim
Maybe we should just generalize the config value to a number/boolean, instead of adding a new attribute?
Change:
}) => self.check_id(closure_id), _ => {} } <ins> lint_callback!(self, check_expr_post, e); </ins> } fn visit_generic_arg(&mut self, arg: &'a ast::GenericArg) {

Discussion:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: But with the suggestion applied the compiler displays an error with a different suggestion: <!-- The following is not always necessary. --Ideally the compiler should not output a warning and treat and as identical. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. -- label D-incorrect A-suggestion-diagnostics <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think it's relate with and
It would be great if it could give since parenthesizing the expression instead avoids the potential "is that a tuple?" confusion of .
Duplicate of .
Change:
<ins> // Test that `download-rustc` doesn't put duplicate copies of libc in the sysroot. // check-pass #![crate_type = "lib"] #![no_std] #![feature(rustc_private)] extern crate libc; </ins>

Discussion:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.