jiebi/CodeConvo huggingface dataset:
Change:
/// /// When all of these conditions are met the build will lift artifacts from /// the previous stage forward. <del> fn force_use_stage1(&self, compiler: Compiler, target: TargetSelection) -> bool { </del> <ins> fn force_use_stage1(&self, stage: u32, target: TargetSelection) -> bool { </ins> !self.config.full_bootstrap <del> && compiler.stage >= 2 </del> <ins> && !self.config.download_rustc() && stage >= 2 </ins> && (self.hosts.iter().any(|h| *h == target) || target == self.build) } /// Checks whether the `compiler` compiling for `target` should be forced to /// use a stage2 compiler instead. /// <del> /// When we download the pre-compiled version of rustc it should be forced to /// use a stage2 compiler. fn force_use_stage2(&self) -> bool { self.config.download_rustc() </del> <ins> /// When we download the pre-compiled version of rustc and compiler stage is >= 2, /// it should be forced to use a stage2 compiler. fn force_use_stage2(&self, stage: u32) -> bool { self.config.download_rustc() && stage >= 2 </ins> } /// Given `num` in the form "a.b.c" return a "release string" which

Discussion:
With , and a empty folder, and running , I get the following error On , x86-64, linux. <details<summaryFull Log </summaryCC </detailsCC
is this a recent regression? are you able to bisect it?
off the top of my head, looks very fishy, that should never happem
I've locally bisected to , which contains this PR that sounds relevant:
Change:
<ins> //~ ERROR overflow // A regression test for #111729 checking that we correctly // track recursion depth for obligations returned by confirmation. use std::panic::RefUnwindSafe; trait Database { type Storage; } trait Query<DB> { type Data; } struct ParseQuery; struct RootDatabase { _runtime: Runtime<RootDatabase>, } impl<T: RefUnwindSafe> Database for T { type Storage = SalsaStorage; } impl Database for RootDatabase { type Storage = SalsaStorage; } struct Runtime<DB: Database> { _storage: Box<DB::Storage>, } struct SalsaStorage { _parse: <ParseQuery as Query<RootDatabase>>::Data, } impl<DB: Database> Query<DB> for ParseQuery { type Data = RootDatabase; } fn main() {} </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: This is modification of with the difference being ` Rust OOM'd here after eating at least 20 gb of memory :sweat_smile: I expected to see this happen: explanation NO OOM, maybe an error Instead, this happened: explanation OOM <!-- 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. --:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
let (ext, res) = self.smart_resolve_macro_path(path, kind, parent_scope, force)?; let span = invoc.span(); <del> invoc.expansion_data.id.set_expn_data( ext.expn_data(parent_scope.expansion, span, fast_print_path(path)) ); </del> <ins> invoc_id.set_expn_data(ext.expn_data(parent_scope.expansion, span, fast_print_path(path))); </ins> if let Res::Def(_, def_id) = res { if after_derive { self.session.span_err(span, "macro attributes must be placed before `#[derive]`"); } <del> self.macro_defs.insert(invoc.expansion_data.id, def_id); let normal_module_def_id = self.macro_def_scope(invoc.expansion_data.id).normal_ancestor_id; self.definitions.add_parent_module_of_macro_def(invoc.expansion_data.id, normal_module_def_id); </del> <ins> self.macro_defs.insert(invoc_id, def_id); let normal_module_def_id = self.macro_def_scope(invoc_id).normal_ancestor_id; self.definitions.add_parent_module_of_macro_def(invoc_id, normal_module_def_id); </ins> } Ok(Some(ext))

Discussion:
This code ([playpen]) compiles on stable but not on nightly and beta: [playpen]: Standard Error Edit: Removed macro Originally posted by in
modify labels: A-macros A-resolve C-bug T-compiler
I updated the snippet to remove the module.
This is a regression from (cc Slightly more minimized reproduction will look like this: performs eager expansion on its arguments and hygienic context of produced by such expansion looks like it was produced by the opaque for some reason, so it's resolved at ' definition site. It maybe either some issue with hygiene infra interacting with eager expansion, but it also may be caused by incorrect spans produced by .
(I'm currently looking into the details.) UPD: I have a fix locally, will submit tomorrow.
Fixed in

() Errors: If either the recursion () or the is removed (), this compiles exactly as expected. Additionally, if I explicitly name my crate, it works as expected, but would be vulnerable to crate renames in user code (can't reproduce in playground because it doesn't build a library).
If you try and build Rustup, you get a similar failure, but without recursion or . Seems that just using another macro and is enough in some circumstances
cc for the hygiene macro in
This code () compiles on stable but not on nightly and beta:
Please, file a separate issue for the regression, I'll prioritize it over pre-existing issues (which the original issue seems to be).
Thanks, I filed it in
Fixed in
Thanks for your work on this!
Change:
first: Some(wfd), }) } else { <del> Err(Error::last_os_error()) </del> <ins> // The status `ERROR_FILE_NOT_FOUND` is returned by the `FindFirstFileW` function // if no matching files can be found, but not necessarily that the path to find the // files in does not exist. // // Hence, a check for whether the path to search in exists is added when the last // os error returned by Windows is `ERROR_FILE_NOT_FOUND` to handle this scenario. // If that is the case, an empty `ReadDir` iterator is returned as it returns `None` // in the initial `.next()` invocation because `ERROR_NO_MORE_FILES` would have been // returned by the `FindNextFileW` function. // // See issue #120040: https://github.com/rust-lang/rust/issues/120040. let last_error = api::get_last_error(); if last_error.code == c::ERROR_FILE_NOT_FOUND { return Ok(ReadDir { handle: FindNextFileHandle(find_handle), root: Arc::new(root), first: None, }); } // Just return the error constructed from the raw OS error if the above is not the case. // // Note: `ERROR_PATH_NOT_FOUND` would have been returned by the `FindFirstFileW` function // when the path to search in does not exist in the first place. Err(Error::from_raw_os_error(last_error.code as i32)) </ins> } } }

Discussion:
This was reported on discord by who pointed out that the C++ STL has a similar issue. Example: prints: It should return success but the returned iterator will have no items. Basically if you use on a completely empty volume then it will return . Rust should interpret this as being an empty iteration and not return an error to the user. Note that empty directories do not return an error so this behaviour was overlooked. We need to add some extra logic to this : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
This is fixed in C++ STL after this PR:
Change:
use rustc_middle::ty; use rustc_span::{Span, DUMMY_SP}; <ins> use crate::traits::query::evaluate_obligation::InferCtxtExt; </ins> use crate::traits::ObligationCtxt; #[derive(Debug)]

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 have a full repro in , but the short version is, it seems like some cases of code that look_ like an omitted type should be inferrable: while certain dependencies, leading to , are in the compile pathway (I could only get it to reproduce via a weird dependency chain via a workspace and a couple of public crates), can lead to an overflow: If the dependency chain is altered in any way that I could divine, the expected error is output: <!-- 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. --I've reproduced this bug both in and in . :
Bisects to nightly-2023-10-07. In nightly-2023-10-06, we get "the expected error" shown above.
Looks like , because reproduces the issue, but the previous commit on master () does not.
Minimal:
I'll put up a fix in a sec
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
#![doc(html_root_url = "https://doc.rust-lang.org/nightly/")] #![feature(staged_api)] <del> #![unstable(feature = "rustc_plugin", issue = "29597")] </del> <ins> #![unstable(feature = "rustc_private", issue = "27812")] </ins> #![rustc_deprecated(since = "1.38.0", reason = " import this through `rustc_driver::plugin` instead to make TLS work correctly.  See https://github.com/rust-lang/rust/issues/62717")]

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.
should fix this
Change:
/// ### Example /// /// ```rust,compile_fail <del> /// # #![feature(type_privacy_lints)] </del> /// # #![allow(unused)] /// #![deny(unnameable_types)] /// mod m {

Discussion:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables
Change:
Kind::Install => describe!( install::Docs, install::Std, <ins> // During the Rust compiler (rustc) installation process, we copy the entire sysroot binary // path (build/host/stage2/bin). Since the building tools also make their copy in the sysroot // binary path, we must install rustc before the tools. Otherwise, the rust-installer will // install the same binaries twice for each tool, leaving backup files (*.old) as a result. install::Rustc, </ins> install::Cargo, install::RustAnalyzer, install::Rustfmt,

Discussion:
In a fresh install of 1.72.0 there are some files: The same thing happens with 1.71.1.
Performed a test on 1.72.0 and was able to reproduce the problem. With HEAD: , it is no longer present(most probably fixed on the cargo side since it doesn't have anything to do with bootstrapping). If you encounter the problem again, please feel free to re-open the issue.
I'm still hitting this with 1.73.0.
Perhaps it's related to my setting. I'll do more experiments tomorrow and report back...
Still happens with 1.74.0. The terminal output of (I've removed the lines):
Would be nice if you can share your Last time I tried I couldn't reproduce it.
I think I see the same with Rust 1.76:
Are you building multiple targets?
No. I just set following in : and .
should handle this problem.
Change:
Some(def @ Def::Const(..)) | Some(def @ Def::AssociatedConst(..)) => { FoundConst(def, ident.unhygienic_name) } <del> Some(Def::Static(..)) => { resolve_error(self, span, ResolutionError::StaticVariableReference); </del> <ins> Some(Def::Static(did, _)) => { resolve_error(self, span, ResolutionError::StaticVariableReference( did, Some(ident.unhygienic_name))); </ins> BareIdentifierPatternUnresolved } _ => BareIdentifierPatternUnresolved,

Discussion:
Rustc version: rustc 1.0.0-nightly ( 2015-03-22) (built 2015-03-23)
Hmm, I am not sure if this is a bug or not. I can see it both ways.
As I understand, this error is related to the situation like this
Change:
<ins> // Copyright 2017 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. type Guilty = bool; type FineDollars = u32; struct Verdict(Guilty, Option<FineDollars>); fn main() { let justice = Verdict(true, Some(2718)); let _condemned = justice.00; //~^ ERROR invalid tuple or struct index let _punishment = justice.001; //~^ ERROR invalid tuple or struct index } </ins>

Discussion:
The following compiles, but I think it shouldn't?
The field name is converted to a number too eagerly. This doesn't happen in struct expressions and patterns.
Change:
<ins> // ignore-tidy-linelength // aux-build:realcore.rs // aux-build:real_gimli.rs // Ensure unstably exported traits have their Implementors sections. #![crate_name = "foo"] #![feature(extremely_unstable_foo)] extern crate realcore; extern crate real_gimli; // issue #74672 // @!has foo/trait.Deref.html '//*[@id="impl-Deref-for-EndianSlice"]//code' 'impl Deref for EndianSlice' pub use realcore::Deref; // @has foo/trait.Join.html '//*[@id="impl-Join-for-Foo"]//code' 'impl Join for Foo' pub use realcore::Join; </ins>

Discussion:
Missing Implementors for [][1] trait. Current output: ! While rustdoc displays [][2] trait implementors. Expected: Display Implementors for Join trait: : 1.47.0-nightly ( 2020-08-15) [1]: [2]: modify labels: T-rustdoc
This is a regression from stable-to-nightly: and beta one has Implementors section. cc
It has made it way to beta. Pattern trait is also affected: modify labels: I-prioritize
(Btw I think you can use as a shorthand)
The Borrow trait still has , I am not sure if this bug affect crates in ecosystem.
So I think this bug shouldn't affect stable traits, just most unstable traits I saw are affected.
There is high change that causing the regression, but I cannot prove that.
This is more likely to be than the refactor I think.
Yeah, I suspect that given it might make sense to revert anyway, since it doesn't actually accomplish the goal. Or someone more experienced with rustdoc may be able to suggest/implement a better patch.
New discovery: So far only trait exported to std affected. For example with Join trait, in alloc it is normal:
Oh right, I have MCVE, it needs two dummy crates. <details<summarydummy crate "unstabled"</summary</detailsCrate to run : modify labels: -E-needs-mcve
searched nightlies: from nightly-2020-06-04 to nightly-2020-07-17 regressed nightly: nightly-2020-07-17 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
That rollup includes both and ; of the two I think is the more likely culprit.
Marking as P-high .

appears on the current nightly's, even though it's not part of the (public) standard libraries. This appears to be , so maybe related to , cc Noticed by (assuming they use the same handle here and discord, if not, sorry :flushed:)
Relevant PRs (backtrace isn't really to blame here): ,
Maybe this should also skip the impl if there is no 'stability' attribute? ,
This is the default for everything not in the standard library. So it seems like the standard library needs special casing here. Maybe as simple as ?
Doesn't gimli get everything marked as unstable behind the rustc_private feature gate through a rustc flag?
MCVE: It doesn't require any external deps, just dummy crates included. The outermost crate is a fake std, realcore is fake core, gimli is fake gimli.
Change:
<ins> error[E0109]: const arguments are not allowed for this type --> $DIR/usize-generic-argument-parent.rs:2:18 | LL |     let x: usize<foo>; |                  ^^^ const argument not allowed error: aborting due to previous error For more information about this error, try `rustc --explain E0109`. </ins>

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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Reduced:
This doesn't ICE on 1.46. modify labels: +regression-from-stable-to-stable
We decided to label this as it's unlikely to be hit, it used to be an error in a previous release. Also, it's very esoteric code.
Line triggered the ICE: Regressed in , cc fyi Note that the snippet doesn't have to contain : <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Will look into this in a few weeks so I am claiming this for now so I don't forget. claim If anyone else wants to work on this before that feel free to do so, don't have much time rn
The solution might be as simple as merging the linked match arm with the previous error one, making this a delayspanbug and ignoring it.
I just saw this issue and thought the same thing. I'm testing the fix now.
Change:
// except according to those terms. // xfail-test Can't use syntax crate here <del> #[feature(quote_stmt)]; </del> <ins> #[feature(quote)]; </ins> extern mod extra; extern mod syntax;

Discussion:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .
Change:
#![feature(cfg_target_vendor)] #![feature(char_error_internals)] #![feature(compiler_builtins_lib)] <ins> #![feature(concat_idents)] </ins> #![feature(const_int_ops)] #![feature(const_ip)] #![feature(const_raw_ptr_deref)]

Discussion:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.