jiebi/CodeConvo huggingface dataset:
Change:
let sm = self.tcx.sess.source_map(); let def_id = match outer_res { <del> Res::SelfTyParam { .. } | Res::SelfCtor(_) => { </del> <ins> Res::SelfTyParam { .. } => { </ins> err.span_label(span, "can't use `Self` here"); return err; }

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. --I made a blank cargo project (ran in an empty directory), and dependencies to my like so: Originally when I went to run , I was in nightly, and got a compile error (full error below). Then, when i switched to stable, there was no error and everything built fine! <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.69 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- 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 -- modify labels: +regression-from-stable-to-nightly -regression-untriaged
searched nightlies: from nightly-2023-02-15 to nightly-2023-05-13 regressed nightly: nightly-2023-05-05 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsrollup it didn't want to bisect the perf builds for some reason but i guess or could be at fault? haven't looked into the actual issue in detail, since it's behind a macro you probably know something about this anyways even if it may not be your fault
its not that is genericconstexprs only code
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler
Change:
.. }) if ct.hir_id == hir_id => tcx.type_of(tcx.hir().local_def_id(param_hir_id)), <del> x => tcx.ty_error_with_message( </del> <ins> x => tcx.ty_error_with_message( </ins> DUMMY_SP, &format!("unexpected const parent in type_of(): {x:?}"), ),

Discussion:
The following code produces several ICEs on both beta and nightly (no necessary). <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details label F-genericassociatedtypes A-const-generics
This regressed in the last day...
Wait wrong issue
As GATs are stable on beta but not on stable, similar to : label regression-from-stable-to-beta
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
}, _, ), <del> ) => { let byte_str = self .tcx() .global_alloc(ptr.alloc_id) .unwrap_memory() .get_bytes(&self.tcx(), ptr, Size::from_bytes(*data)) .unwrap(); p!(pretty_print_byte_str(byte_str)); } </del> <ins> ) => match self.tcx().get_global_alloc(ptr.alloc_id) { Some(GlobalAlloc::Memory(alloc)) => { if let Ok(byte_str) = alloc.get_bytes(&self.tcx(), ptr, Size::from_bytes(*data)) { p!(pretty_print_byte_str(byte_str)) } else { p!(write("<too short allocation>")) } } // FIXME: for statics and functions, we could in principle print more detail. Some(GlobalAlloc::Static(def_id)) => p!(write("<static({:?})>", def_id)), Some(GlobalAlloc::Function(_)) => p!(write("<function>")), None => p!(write("<dangling pointer>")), }, </ins> // Bool (Scalar::Raw { data: 0, .. }, ty::Bool) => p!(write("false")), (Scalar::Raw { data: 1, .. }, ty::Bool) => p!(write("true")),

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. --Command: This code is 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. --: The compiler is at revision <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This , too. Cc
This happens on stable, too. Not very surprising imo since the original corresponding tickets ( , ) are only ~2 weeks old.
Those tickets report different ICEs, from what I can see. Same source code, but different assertion hit in the compiler.
Reduced: when I use an underscore binding instead of , the ICE no longer occurs:
The same ICE also triggers on this file in the miri submodule: (with --emit mir) I'm guessing it's so we need to match on the result of the and print different output depending on it
PR to fix this is up at
I'm getting a similar ice when checking with . I'm wondering if that's fixed as well.
That's a bit hard to tell based on a backtrace without line numbers. But with my patch, there is no more in that entire file, so I'd say -- probably. There's still an though, so I suspect there are still ICEs when a function pointer points to a non-function...
Btw it would be great if someone could review that PR. :) Looks like is pretty busy.
Can confirm this fixed the ICE :+1: :)
Change:
return self.expect(&token::Semi).map(drop); } else if !sm.is_multiline(self.prev_token.span.until(self.token.span)) { // The current token is in the same line as the prior token, not recoverable. <ins> } else if [token::Comma, token::Colon].contains(&self.token.kind) && &self.prev_token.kind == &token::CloseDelim(token::Paren) { // Likely typo: The current token is on a new line and is expected to be // `.`, `;`, `?`, or an operator after a close delimiter token. // // let a = std::process::Command::new("echo") //         .arg("1") //         ,arg("2") //         ^ // https://github.com/rust-lang/rust/issues/72253 self.expect(&token::Semi)?; return Ok(()); </ins> } else if self.look_ahead(1, |t| { t == &token::CloseDelim(token::Brace) || t.can_begin_expr() && t.kind != token::Colon }) && [token::Comma, token::Colon].contains(&self.token.kind)

Discussion:
In an obscure situation with a typo (where there is a comma instead of a period), rustc will suggest replacing the comma with a semicolon, which will fail to compile. Produces the following error and suggestion: Some observations: This must be a let binding. The method calls must be on separate lines (all on one line gives a different error). I would expect this to provide the same error if it is all on one line ("expected one of , , , or an operator"), possibly with a "maybe incorrect" suggestion to replace it with a period (maybe only if the following character is not whitespace?). Note: Feel free to close this. This is really obscure, and I suspect it is not trivial to change, and it is fairly obvious what is wrong. I just thought it was strange, and I was doubly puzzled that the indentation mattered. rustc 1.45.0-nightly ( 2020-05-10) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is because the error recovery tries to figure out if you typoed something when trying to write ; to end an expression. This is probably easy to fix.
claim
Thoughts about the better approach?: vs.
I would prefer something closer to what we already see in other syntax errors: We are not afraid of using vertical space to make errors clearer, but that vertical space still comes at a premium, as does verbosity. We try to lean towards the tersest possible output that can still convey the concept to the broadest set of people.
Merged. Thanks for a good learning issue And thanks for mentoring it I really appreciate your time!
Change:
}; } <ins> let test_threads = match matches.opt_str("test-threads") { Some(n_str) => match n_str.parse::<usize>() { Ok(n) => Some(n), Err(e) => return Some(Err(format!("argument for --test-threads must be a number > 0  (error: {})", e))) }, None => None, }; </ins> let color = match matches.opt_str("color").as_ref().map(|s| &**s) { Some("auto") | None => AutoColor, Some("always") => AlwaysColor,

Discussion:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.
Change:
<ins> // revisions: nn ny yn yy // check-pass #![feature(const_trait_impl, associated_type_defaults, const_mut_refs)] #[cfg_attr(any(yn, yy), const_trait)] pub trait Index { type Output; } #[cfg_attr(any(ny, yy), const_trait)] pub trait IndexMut where Self: Index { const C: <Self as Index>::Output; type Assoc = <Self as Index>::Output; fn foo(&mut self, x: <Self as Index>::Output) -> <Self as Index>::Output; } impl Index for () { type Output = (); } impl const IndexMut for <() as Index>::Output { const C: <Self as Index>::Output = (); type Assoc = <Self as Index>::Output; fn foo(&mut self, x: <Self as Index>::Output) -> <Self as Index>::Output where <Self as Index>::Output:, {} } const C: <() as Index>::Output = (); fn main() {} </ins>

Discussion:
Found in : https://crater- Looking briefly into the code it's doing something pretty weird (e.g., transmutes ), but at the very least this diagnostic seems unfortunate.
searched nightlies: from nightly-2022-04-01 to nightly-2022-08-11 regressed nightly: nightly-2022-07-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThis regressed in cc
Maybe "regressed" is better here, maybe it's a legitimate reason to fail. Haven't looked into it.
I'm going to look into this later, but it seems like a case of wf checks requiring const bounds.
Repro:
Just to be sure I understood: is the regression about code that should compile in the next Rust 1.64 or is that code now invalid code and the regression is just a bad diagnostic? thanks!
The code is valid. It should compile in the next Rust 1.64. Hope that helps.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
cargo.rustdocflag("-Zcrate-attr=warn(rust_2018_idioms)"); <del> // If the rustc output is piped to e.g. `head -n1` we want the process to be // killed, rather than having an error bubble up and cause a panic. cargo.rustflag("-Zon-broken-pipe=kill"); </del> if builder.config.llvm_enzyme { cargo.rustflag("-l").rustflag("Enzyme-19"); }

Discussion:
After I noticed that whenever I modify tests (on Windows), stage 1 cargo gets unnecessary rebuilt which also triggers rebuilds for other tools like stage 0 rustdoc. I'm pretty sure something in my implementation is wrong w.r.t. to properly caching, but I didn't invest time in figuring out why yet, hence opening this bug to track it. The build sequence is something like stage 0 std -stage 1 rustc -stage 1 std -stage 1 tool cargo -stage 0 compiletest / run-make-support / rustdoc. Example repro steps: Run -make sure stage 1 cargo is already built. Modify a test. Observe that stage 1 cargo gets rebuilt even though I didn't modify it.
EDIT: oh, is it because in run-make-support or rustdoc we use or something that is a different staged cargo compared to the one we built with stage 1 rustc...
Actually unassigning because I don't know how to cleanly fix this just yet. EDIT: opened thread https://rust-
Running twice is enough to reproduce cargo rebuild issue. Probably some rustflags invalidating the build cache.
Reopening because we need to revert in favor of a different approach.
Change:
"ssse30", "tbm0", "lzcnt0", "popcnt0", "sse4a0", "rdrnd0", "rdseed0", "fma0", "xsave0", "xsaveopt0", "xsavec0", <del> "xsaves0", </del> <ins> "xsaves0", "aes0", </ins> "avx512bw0", "avx512cd0", "avx512dq0", "avx512er0", "avx512f0", "avx512ifma0",

Discussion:
I would like to use them in the project for conditional compilation. So if there is no particular reason against including them, it would be nice to have them. This code currently does not work as intended: Related:
cc and
Seems plausible to me!
Change:
GlobalKind, }; use rustc_middle::dep_graph; <del> use rustc_middle::middle::cstore::EncodedMetadata; </del> use rustc_middle::middle::exported_symbols; use rustc_middle::ty::TyCtxt; use rustc_middle::mir::mono::Linkage;

Discussion:
The following code from the manual fails with rustboot .
How embarrassing. Thanks for the report, I'll look into it.
Fix mem op= mem bug in (via not terribly good fix). Closed by .
Change:
} } <ins> impl Visitor<'tcx> for ProhibitOpaqueVisitor<'tcx> { type Map = rustc_middle::hir::map::Map<'tcx>; fn nested_visit_map(&mut self) -> hir::intravisit::NestedVisitorMap<Self::Map> { hir::intravisit::NestedVisitorMap::OnlyBodies(self.tcx.hir()) } fn visit_ty(&mut self, arg: &'tcx hir::Ty<'tcx>) { match arg.kind { hir::TyKind::Path(hir::QPath::Resolved(None, path)) => match &path.segments { [PathSegment { res: Some(Res::SelfTy(_, impl_ref)), .. }] => { let impl_ty_name = impl_ref.map(|(def_id, _)| self.tcx.def_path_str(def_id)); self.selftys.push((path.span, impl_ty_name)); } _ => {} }, _ => {} } hir::intravisit::walk_ty(self, arg); } } </ins> if let ItemKind::OpaqueTy(hir::OpaqueTy { origin: hir::OpaqueTyOrigin::AsyncFn | hir::OpaqueTyOrigin::FnReturn, ..

Discussion:
Following the improvement for the diagnostic of the error reported in this issue , it would be nice (depending on how is prioritized) to have the same error message when instead of returning the function returns . When is returned I get a nice error message (on rustc 1.47): But if is used I get: with no suggestion to spell the type.
remove-assignment feel free to re-claim if you are working on this.
Change:
<del> Subproject commit 2ed0b3bfa05c796c6645ed1814cd372e73f45c66 </del> <ins> Subproject commit fc96aa036884183ddc68d2659f4633e6f138b4e0 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
I was wondering why I got even though I compiled rust with in , however I got no errors during any compile&install step.
Well, I'm still getting with this : I basically used the following to compile: ok, a more up to date one:
ah looks like it's my bad for using which apparently is required for to have any effect, now I get which is a lot better! I gotta admit, I didn't expect it to be so from reading this:
Change:
CTEST_DISABLE_debuginfo = "gdb on darwing needs root" endif <ins> # CTEST_DISABLE_NONSELFHOST_$(TEST_GROUP), if set, will cause that # test group to be disabled *unless* the target is able to build a # compiler (i.e. when the target triple is in the set of of host # triples).  The associated message will be printed as a warning # during attempts to run those tests. CTEST_DISABLE_NONSELFHOST_rpass-full = "run-pass-full suite is unavailable when cross-compiling." </ins> define DEF_CTEST_VARS # All the per-stage build rules you might want to call from the

Discussion:
Original title: "compiletest has implicit dependency on libnative" compiletest has implicit dependency on libnative When I tried to do , I get the following: says this is because, despite 's continued use of , there is an implicit attempt to link in unless one puts in a attribute into the crate attributes. I plan to try to fix this pronto. After fixing the above, I get: So there's another separate problem blocking from working.
Still working on this, there was a new problem that came up (run-pass-fulldeps needs libsyntax to have been rebuilt), so I've updated the description and the title to reflect the more general issue here.
Change:
print("pre-installed rustc not detected: {}".format(e)) print("falling back to auto-detect") <del> required = sys.platform != 'win32' </del> <ins> required = not platform_is_win32() </ins> ostype = require(["uname", "-s"], exit=required) cputype = require(['uname', '-m'], exit=required)

Discussion:
I tried this: I expected to see this happen: Bootstrap rebuilds the compiler. Instead, this happened: <!-- 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. --is
In particular, this happens when rust-analyzer is running in the background and you have this config set: We currently recommend that config in https://rustc-dev-
This would be fixed by having a "public" and "private" sysroot: https://rust-
This happens because Windows doesn't allow deleting a running executable/DLL. The way forward would be to special-case it as it is already the case with the file and ignore failures, or to make a double sysroot as you proposed.
You can usually rename a running executable so it may be possible to simulate a delete by moving it within the same filesystem. However, having a public and a private sysroot seems like a more generally useful solution.
I'm happy with both solutions. I think special casing proc-macro-server in the short term seems fine, but if we do that, we should open another issue for the public and private sysroot.
Change:
} } <ins> #[derive(Clone, Debug, Encodable, Decodable, HashStable)] pub struct NativeLib { pub kind: NativeLibKind, pub name: Option<Symbol>, pub cfg: Option<ast::MetaItem>, } impl From<&cstore::NativeLib> for NativeLib { fn from(lib: &cstore::NativeLib) -> Self { NativeLib { kind: lib.kind.clone(), name: lib.name.clone(), cfg: lib.cfg.clone() } } } </ins> /// Misc info we load from metadata to persist beyond the tcx. /// /// Note: though `CrateNum` is only meaningful within the same tcx, information within `CrateInfo`

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. --I tried this command: I expected to see this happen: An file is generated. Instead, this happened: <!-- 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. --: Originally posted by in cc (original implementer of
PR changed the encode/decode method of . When was implemented, the encode/decode of was purposely crafted to avoid calling the encode/decode method of . The most straightforward fix is to implement / for to allow it be serialized outside of metadata. After that, may be now it is the time to re-think the way we store data in the file. What do you think ?
I think should completely be avoided in the input of the linker function. One of the uses if in it's field. This field doesn't seem to be used by the linking code.
Good suggestion, let me look into it.
are you still working on this?
Thank you for reminding and apologize for the delay. I did create a prototype but haven't got a chance polish it yet. I'll create the PR this week.
Sorry again about the delay. I've created PR , which fixes this issue.
Change:
<ins> #![crate_name = "foo"] // @has 'foo/index.html' // There should be only `type A`. // @count - '//*[@class="item-table"]//*[@class="item-name"]' 1 // @has - '//*[@class="item-name"]/a[@href="type.A.html"]' 'A' mod foo { pub struct S; } use foo::S; pub type A = S; // @has 'foo/type.A.html' // @has - '//*[@id="method.default"]/h4' 'fn default() -> Self' impl Default for A { fn default() -> Self { S } } // @has - '//*[@id="method.a"]/h4' 'pub fn a(&self)' impl A { pub fn a(&self) {} } </ins>

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. --I tried this code: I expected the documentation for the type alias to show the method and the implementation of . Instead, the type alias does not show the method . It does however show the implementation of . ! By publicly exposing through , the documentation of on the alias is documented as I expected, but then is publicly reachable, which in my case is unwanted due to being an internal implementation detail. This also works when making the statement , which gets the docs to look like I expected them to. ! <!-- 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. --: Thanks for helping me figure out why what I was expecting wasn't happening though it looked like it should.
I think it's ok to document an impl on a reexported if the reexported item is not doc hidden. I'll send a fix in the next weeks.
Change:
<ins> // Copyright 2013-2014 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. // This is a regression test against an ICE that used to occur // on malformed attributes for a custom MultiModifier. // aux-build:macro_crate_test.rs // ignore-stage1 #![feature(plugin)] #![plugin(macro_crate_test)] #[noop_attribute"x"] //~ ERROR expected one of fn night() { } #[noop_attribute("hi"), rank = 2] //~ ERROR unexpected token fn knight() { } #[noop_attribute("/user", data= = "<user")] //~ ERROR literal or identifier fn nite() { } fn main() {} </ins>

Discussion:
Hi! I'm trying to compile my Rocket/Diesel/R2d2 task management project, which has previously successfully compiled, and when I add the newest piece which relies on macros in some new/different way (sorry for vague, I'm new to rust) it starts failing to compile. Looking at the backtrace, the error seems to be in MacroExpander::expandinvoc. I expect it to have the same behavior as the simpler version of the route: which warns about unused query result on compile but successfully runs, builds the NewTask struct from url components, and inserts it into the database. it fails to compile during cargo run, and the same exact error shows during cargo check. I've pasted the whole command with outputs here: Check out my project's for the exact code where I get the bug. Check out my project's master branch at commit to see the functional version (requires a local postgresql instance and a DATABASEURL env variable in a env file).
I minimized down to nothing but 14 looping macros in order to squarely place the blame on a single culprit once and for all: A function that just loops surely cannot be responsible for dropping a , so the must be a bug in rustc. (I still rather doubt it is in though, but rather, in a function that gets inlined into it)
So... I mentioned in the other issue how terrifying of a concept I thought was. For the uninitiated, is a type alias for a with a in its variant, which acts like a ticking timebomb; it explodes if the error is ever dropped. Simply put, has some methods that you must never call on a . Do you see it? :wink:
Ha! Thank you for the digging That stray is really cheeky, ain't it?
I'll probably submit a PR; I'm just browsing around the existing test cases for plugins trying to glean "best practices." (I'm also trying to see if there's any test case that causes the other in the branch to blow up. I don't think there is since it appears that the full attribute gets parsed before it tries to expand .)