jiebi/CodeConvo huggingface dataset:
Change:
<del> Subproject commit c1cb24969e84dfaded2769ab5575effc8d4f5c30 </del> <ins> Subproject commit 4f6f264c305ea30f1de90ad0c2f341e84d972b2e </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Compiler team triage: marking as P-high, as miri should build. -- any idea what it takes to fix this?
It's already fixed in the Miri repo. Just takes someone to do the PR for rustc. do you want to do that? Also in the past we treated these as P-medium. Ultimately of course this is up to the compiler team, I personally will always treat it as high priority to keep at least the Miri repo itself working.
OK. I think it ought to be high priority to keep things building, personally, but I'm happy to defer to convention for now, as we have too many P-high bugs ultimately.
claim
Change:
error } <del> fn is_self<'tcx>(ty: Ty<'tcx>) -> bool { match ty.sty { ty::TyParam(ref data) => data.space == subst::SelfSpace, _ => false, } } </del>

Discussion:
Attempting to compile the following with my  crate yields an ICE: Output from
Reduced:
I'm able to reproduce this exact same error on stable and nightly today using this 8 line example:
Change:
// (e.g. the `bootimage` crate). for tool in LLVM_TOOLS { let tool_exe = exe(tool, target_compiler.host); <del> builder.copy(&llvm_bin_dir.join(&tool_exe), &libdir_bin.join(&tool_exe)); </del> <ins> let src_path = llvm_bin_dir.join(&tool_exe); // When using `donwload-ci-llvm`, some of the tools // may not exist, so skip trying to copy them. if src_path.exists() { builder.copy(&src_path, &libdir_bin.join(&tool_exe)); } </ins> } } }

Discussion:
I've rebased this morning and I can't build the repo anymore since landed. It seems there are missing tools in the LLVM CI tarball. AFAICT, these are the tools CI copies in the tarball: And these are the tools bootstrap tries to install in : being defined as: As you can see, there are many tools in that are not included in that step shown above. I'm on macOS, and here is the list of tools that I found in the downloaded LLVM CI tarball: Cc who authored .
I think we should disable copying those tools under ci-llvm for now, and then decide if we want to include them in the ci-llvm artifact or not.
makes sense to me!
Actually the problem seems to be bigger, for now I disabled using the LLVM CI tarball locally and it still failed.
What error are you getting with it disabled?
Exactly the same. I restarted the whole build after running , I'll report back once (if) the error reproduces again.
Ah! The compiler profile sets to , my bad, I'll explicitly override that to in my config and the problem will probably go away. I should have noticed I didn't actually rebuild LLVM hah.
I'll open a PR to make copying the tools conditional on LLVM being built locally.
Or just call , like I suggested originally ... I'm not sure why dist is being treated differently from all the other build commands.
Those tools don't exist in the downloaded archive, so won't help here
Change:
<ins> //@ aux-build:block-on.rs </ins> //@ edition: 2021 //@ build-pass #![feature(async_fn_traits)] <ins> extern crate block_on; </ins> use std::ops::AsyncFn; async fn foo() {}

Discussion:
Importantly note that the closure passed to foo is ; does not ICE. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in ()
Change:
<ins> // Copyright 2018 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. const C: *const u8 = &0; fn foo(x: *const u8) { match x { C => {} _ => {} } } const D: *const [u8; 4] = b"abcd"; fn main() { match D { D => {} _ => {} } } </ins>

Discussion:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.
Change:
return inner return decorator <del> @only_on(('linux', 'darwin', 'freebsd', 'openbsd')) </del> <ins> @only_on(['linux', 'darwin', 'freebsd', 'openbsd']) </ins> def check_rlimit_core(): import resource soft, hard = resource.getrlimit(resource.RLIMIT_CORE)

Discussion:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use
Change:
} } <del> (&ty::ty_param(ref a_p), &ty::ty_param(ref b_p)) if a_p.idx == b_p.idx => { </del> <ins> (&ty::ty_param(ref a_p), &ty::ty_param(ref b_p)) if a_p.idx == b_p.idx && a_p.space == b_p.space => { </ins> Ok(a) }

Discussion:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:
Change:
CFG_THIRD_PARTY_OBJECTS_x86_64-pc-windows-gnu := crt2.o dllcrt2.o CFG_INSTALLED_OBJECTS_x86_64-pc-windows-gnu := crt2.o dllcrt2.o rsbegin.o rsend.o CFG_RUSTRT_HAS_STARTUP_OBJS_x86_64-pc-windows-gnu := 1 <del> # FIXME(#31030) - there's not a great reason to disable jemalloc here CFG_DISABLE_JEMALLOC_x86_64-pc-windows-gnu := 1 </del>

Discussion:
As of the time of this writing, we are running jemalloc at the revision which I believe is the 4.0.4 release of jemalloc. Previously we were running which I believe is somewhere in the 3.6 series. We attempted to upgrade jemalloc many times between these two commits eventually that the previous behavior of on Windows is fundamentally racy in jemalloc right now unfortunately. This led to a to where we are today. Unfortunately, however, there is a so we are attempting to downgrade back to 3.6. There were no known problems other than some Windows issues with jemalloc 3.6, so we believe it'll be fine for awhile. In this downgrade, however, it appears that the implementation of is somewhat broken as well, causing the to fail to land. As a result, the downgrade attempt will disable jemalloc on Windows entirely. This issue will track re-enabling it on Windows as well as re-upgrading once the deadlock bug is fixed. As far as I know the only reason to not enable Windows is that lots of locking support was improved in 4.0.*, and the only reason to not upgrade immediately is the deadlock bugs we've encountered.
FWIW one of my Rust projects with CI-every-night has started deadlocking recently, and after some investigation it turned up the exact same stack trace as rustdoc itself, so that's at least another data point for the deadlock in jemalloc.
Change:
/// /// [`shrink_to_fit`]: ../ffi/struct.OsString.html#method.shrink_to_fit /// [`OsString`]: ../ffi/struct.OsString.html <del> #[unstable(feature = "path_buf_capacity", issue = "58234")] </del> <ins> #[stable(feature = "path_buf_capacity", since = "1.44.0")] </ins> pub fn shrink_to_fit(&mut self) { self.inner.shrink_to_fit() }

Discussion:
, should probably not be stabilized before , see
Happy to take this on as a first contribution to rust.
Great! I'd be happy to help you get started, just let me know if you want mentoring/instructions at any level!
are you able to define a list of the methods that need to be implemented as part of this PR?
I think all of these will essentially call the underlying functions on . [ ] [ ] [ ] [ ] [ ] [ ] [ ] -- this one is more of a maybe, since it's unstable on OsString. We can reuse the same tracking issue for this. We'll probably want to add all of these under the same feature gate.
thanks for that. I have the implementation drafted locally. I'm having some difficulty however in running the tests for stdlib - even a is producing errors not related to my changes. Is there any documentation I've missed for best practices on compiling / working on stdlib?
You'll want to use x.py; for your scenario I believe and/or are the commands you want. I'm not sure where the most current documentation is.
describes how to use .
Triage: since has been merged, can this be closed?
No, this is now the tracking issue for the stabilization of those APIs.
Reviewing this since then, I think it may be worth removing these APIs and replacing them with something like and . These aren't really commonly used so hiding them as such seems reasonable and is less heavy.
I'd love to see these stabilized. I have a tool that manipulates lots of paths, so I'd like to avoid needless reallocations. I generate lots of temporary paths in a loop. would work nicely to reuse the buffer. I need to concatenate several components. I know their length, so I could use I want to store lots of paths for later. is a bit smaller than , but if I can't reserve exact capacity, will reallocate.
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] [ ] 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.
reviewed assuming we're only stabilizing capacity + withcapacity + clear + reserve + reserveexact + shrinktofit;&ensp;and shrink_to is being moved to instead.
:bell: This is now entering its final comment period, as per the . :bell:
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.
I've posted a stabilization PR in .
Change:
unsafe{ *self.value.get() } } <del> /// Sets the contained value. /// /// # Examples /// /// ``` /// use std::cell::Cell; /// /// let c = Cell::new(5); /// /// c.set(10); /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub fn set(&self, value: T) { unsafe { *self.value.get() = value; } } </del> /// Returns a reference to the underlying `UnsafeCell`. /// /// # Examples

Discussion:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.
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. // Binding unsized expressions to ref patterns pub fn main() { let ref a = *"abcdef"; assert_eq!(a, "abcdef"); match *"12345" { ref b => { assert_eq!(b, "12345") } } } </ins>

Discussion:
I've tried to write: The line above gives LLVM assertion. I think this must show some syntax error.
Change:
subpattern: pattern, ascription: Ascription { annotation, <del> /// Note that use `Contravariant` here. See the /// `variance` field documentation for details. </del> <ins> // Note that use `Contravariant` here. See the // `variance` field documentation for details. </ins> variance: ty::Variance::Contravariant, }, },

Discussion:
The same warning is produced at other places like statements, expressions, functions etc. For completeness and consistency it should be produced for pattern and expression fields too. No response rustc 1.74.0-nightly ( 2023-09-01) binary: rustc commit-hash: commit-date: 2023-09-01 host: x8664-pc-windows-msvc release: 1.74.0-nightly LLVM version: 17.0.0 rustc version older than 1.74.0 may ICE on this code. The ICE was fixed in 1.74.0 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reason these warnings are not produced is because the lint infrastructure currently exposes no hooks for and , i.e. there are no and methods on (or for that matter). To fix the issue, these methods may have to be here: and then invoked from here: and here: Alternatively, we can emit the warning from the already existing and methods of and not bother with the above changes at all.
Yeah, I would expect this is the best way of doing it.
claim
label -needs-triage
Change:
<ins> // check-pass // Make sure we don't have any false positives here. #![deny(dead_code)] enum X { A { _a: () }, B { _b: () }, } impl X { fn a() -> X { X::A { _a: () } } fn b() -> Self { Self::B { _b: () } } } fn main() { let (_, _) = (X::a(), X::b()); } </ins>

Discussion:
I'm sure that there is a more concise way to generate this error, but this produces a lint warning: () This code instantiates , but the lint disagrees:
Something small-ish-er: If we replace by , then it will change to: which is indeed correct
This is probably the most telling example: This doesn't compile (deadcode), and doesn't lint with clippy (clippy::useself, likely due to rust-lang/rust-clippy). The dead_code problem doesn't manifest if is simple or a newtype ( is OK), it needs to be a struct.
It looks like the erroneous warning arises only for struct-like enum variants that are created only by referencing via . In this example program, the only warning is for : ()
These seem to have been fixed. The above playground link has no warnings.
searched nightlies: from nightly-2020-01-26 to nightly-2020-08-03 regressed nightly: nightly-2020-05-03 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: </detailsHow is that related? But nevertheless: modify labels: E-needs-test
That bisection may be because of a bug in cargo-bisect-rustc that was fixed in the latest release; see rust-lang/cargo-bisect-rustc.
Change:
err.emit(); } <del> fn check_decl_no_pat(decl: &FnDecl, mut report_err: impl FnMut(Span, bool)) { </del> <ins> fn check_decl_no_pat(decl: &FnDecl, mut report_err: impl FnMut(Span, Option<Ident>, bool)) { </ins> for Param { pat, .. } in &decl.inputs { match pat.kind { PatKind::Ident(BindingMode::ByValue(Mutability::Not), _, None) | PatKind::Wild => {} <del> PatKind::Ident(BindingMode::ByValue(Mutability::Mut), _, None) => { report_err(pat.span, true) </del> <ins> PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ident, None) => { report_err(pat.span, Some(ident), true) </ins> } <del> _ => report_err(pat.span, false), </del> <ins> _ => report_err(pat.span, None, false), </ins> } } }

Discussion:
Taken from We should suggest to use an identifier. When possible take that identifier from the pattern, otherwise should work just as well. CC
I'll try it!
Change:
#[test] fn download_ci_llvm() { <ins> if crate::native::is_ci_llvm_modified(&parse("")) { eprintln!("Detected LLVM as non-available: running in CI and modified LLVM in this change"); return; } </ins> let parse_llvm = |s| parse(s).llvm_from_ci; let if_available = parse_llvm("llvm.download-ci-llvm = "if-available"");

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. --rust-num/num-bigint The code prints the output below and exits successfully. The code prints the output below and panics. <!-- 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. --:
Here's some reproduction on Godbolt. The problem seems unrelated to i64 and it's entirely the u64 -f32 conversion that's buggy. The fact that we use the floating point numbers as some sort of address makes it seem like we are loading the value from a lookup table and there might be a bug in Windows' table:
Took me way too long, but I figured it out. The fact that FPU instructions are used means that it runs into problems with the FPU accuracy. By default the control word is set to 0x27f on Windows and 0x37f on Linux. In particular the 0x3 vs 0x2 is the precision control setting of the FPU. 01 = Not used 10 = 53 bits (REAL8) 11 = 64 bits (REAL10) So on Windows it's in 53-bits mode whereas on Linux it's in 64-bits mode. Running the following code therefore fixes the problem on Windows: This probably is an LLVM bug where LLVM assumes the FPU is configured like on Linux instead of like on Windows. MSVC for example just emits a call to instead, which is probably the correct thing to do. (Also it's a little surprising to me the FPU is used at all, when i686 afaik even has SSE2 available by default).
The function that lowers the uint to float cast is in . There's basically a bunch of checks to generate shorter versions if various conditions are met, but all of them fail and it has to resort to using the FPU. There actually is one case in there where they treat Windows differently, I'm guessing something similar can be done to not fall into the FPU default case here as well. In particular because both SSE2 and a builtin function that does exactly this cast exist.
I tested it with some other code and thought it was resolved.
This was patched upstream (thanks icedrocket!)

but it seems like they reverted the patch, as unfortunately it broke Chrome's build: I don't know if it is more profitable to work around this on our end by emitting the relevant call? It looks like there's an intention to use another fix:
A new fix has been commited to upstream: llvm/llvm-project
Change:
break; } } <ins> Ok(None) => break, Err(mut e) => { e.cancel(); break; } </ins> } <del> Err(mut e) => { e.cancel(); } </del> <ins> // The supplied slice is only used for diagnostics, // which are swallowed here anyway. parser.maybe_consume_incorrect_semicolon(&[]); </ins> } // Reset errors so that they won't be reported as compiler bugs when dropping the

Discussion:
We have a Rust-2015 doc test which has an which started failing to build on nightly 2021-11-21 (but passes on stable/2021-11-20). It now fails with
Probably caused by (; no rollup?).
That seems unlikely, is more plausible. doesn't affect doctests.
Oh, I think I got misled by the "rustdoc" bit.
I can't reproduce this. I tried /// extern crate inner; /// and running , but all the tests passed fine. can you link the original code?
The failure is You can see the first failure in CI at
The following seems like a minimal reproduction when used with 2015: /// extern crate mycrate; /// mycrate::foo(); /// Bisected to .
cc , I think it might make sense to revert temporarily unless you already have an idea for a fix.
Change:
//! Everything here is basically just a shim around calling either `rustbook` or //! `rustdoc`. <del> use std::collections::HashSet; </del> use std::fs; use std::io; use std::path::{Path, PathBuf};

Discussion:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild