jiebi/CodeConvo huggingface dataset:
Change:
| = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `usize` <ins> = note: `usize` does not have a fixed maximum value, so a wildcard `_` is necessary to match exhaustively = help: add `#![feature(precise_pointer_size_matching)]` to the crate attributes to enable precise `usize` matching </ins> error[E0004]: non-exhaustive patterns: `_` not covered --> $DIR/feature-gate-precise_pointer_size_matching.rs:10:11

Discussion:
Gives:
Fairly sure this is intentional for
From the pull I've seen a part that I didn't see/remember: An unstable feature precisepointersizematching will be to permit matching exactly on pointer-size integer types. So you're right, this isn't a new bug, it's a known unfinished part. I hope to see that precisepointersizematching implemented.
It already exists.
I see, then what do I have to hope to see? :-)
I'm not sure the feature is ever going to be stabilised, because there are concerns that this isn't a desirable feature. But hopefully the diagnostics will at least be improved in
Do you have a link to such concerns? (Or are you willing to summarize them?) (I value your work on the compiler a lot varkor :-) )
I think the relevant concerns arose in the (from this comment up). The overview is that we ought not to make assumptions about pointer sizes on the target platform, because they're not guaranteed to be fixed, so this could cause compatibility issues.
Change:
/// Parse a generic argument in a path segment. /// This does not include constraints, e.g., `Item = u8`, which is handled in `parse_angle_arg`. <del> fn parse_generic_arg(&mut self) -> PResult<'a, Option<GenericArg>> { </del> <ins> pub(super) fn parse_generic_arg(&mut self) -> PResult<'a, Option<GenericArg>> { </ins> let start = self.token.span; let arg = if self.check_lifetime() && self.look_ahead(1, |t| !t.is_like_plus()) { // Parse lifetime argument.

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: Ideally the output should mention that the user needs to use a turbofish here: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
the help message seems to only be missing if there are 2 const arguments: using type parameters or just one const param causes a useful help message
claim
It turns out 's repro is different than the original repro. My PR fixes 's examples but not the original one. I'll update it to fix the original one too.
All fixed.
Change:
extern "system" { pub fn GetCurrentProcessId() -> DWORD; <ins> 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; </ins> pub fn GetSystemDirectoryW(lpBuffer: LPWSTR, uSize: UINT) -> UINT; pub fn RemoveDirectoryW(lpPathName: LPCWSTR) -> BOOL; pub fn SetFileAttributesW(lpFileName: LPCWSTR, dwFileAttributes: DWORD) -> BOOL;

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:
let vtable = infcx.drain_fulfillment_cx_or_panic(&mut fulfill_cx, &vtable); info!("Cache miss: {:?} => {:?}", trait_ref, vtable); <del> vtable </del> <ins> Some(vtable) </ins> }) }

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
This regressed in .
cc
triage: already has fix in pipeline. P-high. removing nomination label.
Change:
<ins> // check-pass struct Value { values: &'static [&'static Value], } // This `static` recursively points to itself through a promoted (the slice). static VALUE: Value = Value { values: &[&VALUE], }; fn main() {} </ins>

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 tried this code: I expected to see this happen: compile fine, with the static containing a slice that references . Instead, this happened: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: <!-- Provide the version you are using that has the regression. --:
searched nightlies: from nightly-2024-02-10 to nightly-2024-02-11 regressed nightly: nightly-2024-02-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: cc
Context for how I found this: I use this technique in in code generation for benchmarks of generic functions. The simple example I gave is just a minimal reproduction of the issue.
Hm, that is very strange. Not sure if there is a good way to get the backtrace of where in the code the cyclic queries are made? My first guess is that it is the new call to here: But... surely we can ask for the type of a static while evaluating that very static, that can't be cyclic?
Ah no, probably it is related to the fact that we now recursively validate when a constant points to a static. Previously we stopped there. I guess we should not do that for promoteds.
WG-prioritization assigning priority (). label -I-prioritize +P-high -E-needs-bisection +T-compiler
Change:
<ins> warning: unexpected `cfg` condition name: `value` --> $DIR/cfg-value-for-cfg-name-duplicate.rs:8:7 | LL | #[cfg(value)] |       ^^^^^ | = help: expected names are: `bar`, `bee`, `cow`, `debug_assertions`, `doc`, `doctest`, `foo`, `miri`, `overflow_checks`, `panic`, `proc_macro`, `relocation_model`, `sanitize`, `sanitizer_cfi_generalize_pointers`, `sanitizer_cfi_normalize_integers`, `target_abi`, `target_arch`, `target_endian`, `target_env`, `target_family`, `target_feature`, `target_has_atomic`, `target_has_atomic_equal_alignment`, `target_has_atomic_load_store`, `target_os`, `target_pointer_width`, `target_thread_local`, `target_vendor`, `test`, `unix`, `windows` = help: to expect this configuration use `--check-cfg=cfg(value)` = note: see <https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html> for more information about checking conditional configuration = note: `#[warn(unexpected_cfgs)]` on by default warning: 1 warning emitted </ins>

Discussion:
The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_derive(AddImpl)] pub fn derive(input: TokenStream) -> TokenStream { "use std::cmp::Ordering; impl<T> Ord for PriorityQueue<T> { fn cmp(&self, other: &Self) -> Ordering { self.0.cmp(&self.height) } } " .parse() .unwrap() } </ins>

Discussion:
Given the following code: current output is: The last part of the suggestion is not valid Rust code and therefore should not be suggested like this. This problem occurs on the Playground on both stable and nightly with basically identical error messages. serde v1.0.147 requires such that will be . Otherwise the problem does not seem serde specific. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
do you know how to create a minimal case without ? so we may add it to unit testing. I give a fix and verified it's OK with my local testing, but I'm struggle to construct a minimal case without to reproduce it.
I assume this reproduces when using the same setup of derive macro implementing a trait while the implementation is missing bounds. I don't know if it is relevant that the derive macro produces a trait. Something along these lines, with the proc macro crate omitted.
yes, it's caused by derive macro.
emmmet this error
Change:
<ins> FROM ubuntu:16.04 RUN apt-get update && apt-get install -y --no-install-recommends  g++-multilib  make  file  curl  ca-certificates  python2.7  git  cmake  xz-utils  sudo  gdb  patch  libssl-dev  pkg-config WORKDIR /build/ COPY musl-libunwind-patch.patch build-musl.sh /build/ RUN sh /build/build-musl.sh && rm -rf /build RUN curl -OL https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64.deb &&  dpkg -i dumb-init_*.deb &&  rm dumb-init_*.deb ENTRYPOINT ["/usr/bin/dumb-init", "--"] RUN curl -o /usr/local/bin/sccache  https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-02-25-sccache-x86_64-unknown-linux-musl &&  chmod +x /usr/local/bin/sccache ENV RUST_CONFIGURE_ARGS  --target=i686-unknown-linux-musl,i586-unknown-linux-gnu  --musl-root-i686=/musl-i686 # Newer binutils broke things on some vms/distros (i.e., linking against # unknown relocs disabled by the following flag), so we need to go out of our # way to produce "super compatible" binaries. # # See: https://github.com/rust-lang/rust/issues/34978 ENV CFLAGS_i686_unknown_linux_musl=-Wa,-mrelax-relocations=no ENV SCRIPT  python2.7 ../x.py test  --target i686-unknown-linux-musl  --target i586-unknown-linux-gnu  &&  python2.7 ../x.py dist  --target i686-unknown-linux-musl  --target i586-unknown-linux-gnu </ins>

Discussion:
Causing our builds to fail. I have no idea why ;_;
According to https://travis- We have 30GB of disk space 23 of which is available on the start of a build: ` At the end of the build, the dir is 23 GB: And such, we're filling up.
cc
According to https://travis- we start out with 5/30GB taken up
Word from travis is that we can't increase disk size right now.
According to the run-pass output directory is 17GB
"Hello world" for musl is 3.5 MB. With 2.8k tests and three separate targets being tested, that's ~30GB. That's where the space is going.
1MB of that 3.5 is debuginfo
Change:
<ins> error[E0277]: `&T` is not an iterator --> $DIR/hir-wf-check-erase-regions.rs:7:5 | LL |     type IntoIter = std::iter::Flatten<std::slice::Iter<'a, T>>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `&T` is not an iterator | ::: $SRC_DIR/core/src/iter/adapters/flatten.rs:LL:COL | LL | pub struct Flatten<I: Iterator<Item: IntoIterator>> { |                                      ------------ required by this bound in `Flatten` | = help: the trait `Iterator` is not implemented for `&T` = note: required because of the requirements on the impl of `IntoIterator` for `&T` error[E0277]: `&T` is not an iterator --> $DIR/hir-wf-check-erase-regions.rs:10:27 | LL |     fn into_iter(self) -> Self::IntoIter { |                           ^^^^^^^^^^^^^^ `&T` is not an iterator | ::: $SRC_DIR/core/src/iter/adapters/flatten.rs:LL:COL | LL | pub struct Flatten<I: Iterator<Item: IntoIterator>> { |                                      ------------ required by this bound in `Flatten` | = help: the trait `Iterator` is not implemented for `&T` = note: required because of the requirements on the impl of `IntoIterator` for `&T` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </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. --When trying to compile this incorrect code using cargo, nightly rustc panics. When compiling using rustc directly without further arguments (or using the same command cargo calls with removed), it outputs an error message instead. I also noticed that changing to will also result in an error message instead of a panic. <!-- 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
I seem to have run into the same issue with this code: <details<summaryBacktrace</summary</details
I believe these ICEs trigger because of / are made visible by cc
I'm not able to repro this with rustc 1.56.0-nightly ( 2021-08-02): Could you verify that you see it with a recent nightly? There have been significant changes in this area recently. Edit: ah! with enabled I see it:
I am able to reproduce my issue and the other one on by simply running :
Change:
WellFormedLoc::Ty(_) => match hir.get(hir_id) { hir::Node::ImplItem(item) => match item.kind { hir::ImplItemKind::TyAlias(ty) => Some(ty), <ins> hir::ImplItemKind::Const(ty, _) => Some(ty), </ins> ref item => bug!("Unexpected ImplItem {:?}", item), }, hir::Node::TraitItem(item) => match item.kind { hir::TraitItemKind::Type(_, ty) => ty, <ins> hir::TraitItemKind::Const(ty, _) => Some(ty), </ins> ref item => bug!("Unexpected TraitItem {:?}", item), }, hir::Node::Item(item) => match item.kind {

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
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly
Change:
self.check_rustdoc_test_option(proc_res); } else { let root = self.config.find_rust_src_root().unwrap(); <del> let mut cmd = Command::new(&self.config.docck_python); </del> <ins> let mut cmd = Command::new(&self.config.python); </ins> cmd.arg(root.join("src/etc/htmldocck.py")).arg(&out_dir).arg(&self.testpaths.file); if self.config.bless { cmd.arg("--bless");

Discussion:
Compiletest currently has two different arguments telling it which python to use. Since , both are always the same. We should change it to just one argument to simplify things. Mentoring instructions: Change to be a single argument, then change to use the updated arguments. are you interested in tackling this one too? :) label +A-rustbuild +A-testsuite +E-easy +E-mentor Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
error[E0364]: `foo` is private, and cannot be re-exported <del> --> $DIR/reexports.rs:6:17 </del> <ins> --> $DIR/reexports.rs:8:17 </ins> | LL |         pub use super::foo; |                 ^^^^^^^^^^ | note: consider marking `foo` as `pub` in the imported module <del> --> $DIR/reexports.rs:6:17 </del> <ins> --> $DIR/reexports.rs:8:17 </ins> | LL |         pub use super::foo; |                 ^^^^^^^^^^ <del> error: A non-empty glob must import something with the glob's visibility --> $DIR/reexports.rs:7:17 | LL |         pub use super::*; |                 ^^^^^^^^ </del> error[E0603]: module `foo` is private <del> --> $DIR/reexports.rs:28:15 </del> <ins> --> $DIR/reexports.rs:33:15 </ins> | LL |     use b::a::foo::S; |               ^^^ error[E0603]: module `foo` is private <del> --> $DIR/reexports.rs:29:15 </del> <ins> --> $DIR/reexports.rs:34:15 </ins> | LL |     use b::b::foo::S as T; |               ^^^ <del> error: aborting due to 4 previous errors </del> <ins> warning: glob import doesn't reexport anything because no candidate is public enough --> $DIR/reexports.rs:9:17 | LL |         pub use super::*; |                 ^^^^^^^^ | note: lint level defined here --> $DIR/reexports.rs:1:9 | LL | #![warn(unused_imports)] |         ^^^^^^^^^^^^^^ error: aborting due to 3 previous errors </ins> Some errors have detailed explanations: E0364, E0603. For more information about an error, try `rustc --explain E0364`.

Discussion:
Consider the following three examples: A and C are accepted and B has a compilation error. However, the message reported in B looks more like a lint than a compilation error. A consequence of this error is that adding a non-public function to a module (e.g. the in B) may break code that imports from that module. This causes surprises when refactoring. Shouldn't "A non-empty glob must import something with the glob's visibility" be a lint? The original discussion is here:
The error was introduced in as a part of import modularization, and discussed in one of the related issues, but I can't find where exactly. The error was introduced by analogy with errors for single imports (and just to be conservative): The error is not technically necessary, and we should be able to report it as a lint for glob imports while keeping it an error for single imports.
Would this be a "good first issue" or is it complex to fix?
No, not complex. Find where "non-empty glob must import something" is reported. Replace with .
I want to do this issue but the problem I have is with a test (ui/imports/reexports) that checks for this error, I don't know the compiler structure so I don't know when compiling this file the lint will not be reported because of the other errors or not. Else I changed the to
Change:
fn main() { println!("cargo:rerun-if-changed=build.rs"); println!("cargo:rerun-if-env-changed=RUSTC"); <del> println!("cargo:rerun-if-env-changed=PATH"); </del> println!("cargo:rustc-env=BUILD_TRIPLE={}", env::var("HOST").unwrap()); // This may not be a canonicalized path. let mut rustc = PathBuf::from(env::var_os("RUSTC").unwrap()); if rustc.is_relative() { <ins> println!("cargo:rerun-if-env-changed=PATH"); </ins> for dir in env::split_paths(&env::var_os("PATH").unwrap_or_default()) { let absolute = dir.join(&rustc); if absolute.exists() {

Discussion:
When is invoked both by vscode and from the terminal directly, "bootstrap" is rebuilt each time. I think in the end this is due to that line: Indeed is almost certainly different between the two environments. (vscode lives inside a sandbox, it just runs too many untrusted things to be granted access to my files and keys.) Rebuilding on every change seems excessive, is that truly needed? Cc
We could probably move that into this if: I think that would still be fine and maybe enough to avoid trouble in practice? That if is the reason we it in the first place.
is unset for me (in both environments, unless vscode sets it itself), so that would help for my particular case I think.
RUSTC is likely set for you -- this is a build script environment, where it should be set to something. IIRC, I had some trouble assuming it was an absolute path in all cases which is why this ad-hoc canonicalization logic was .
is set by x.py:
The fix in seems wrong to me - if bootstrap isn't rerun when changes, it will still break moving the directory, even if the path is absolute. If you want to fix it properly, you'd probably have to remove this handling from the build script altogether and into rustbuild instead.
I'm not sure I follow your logic -- bootstrap is still rerun when RUSTC changes, just not when it is a relative path. My assumption (perhaps wrong, happy to be corrected) there is that a relative path is only encountered when we're being invoked with a more global rustc (e.g., /usr/bin/rustc, which is in PATH normally).
Nothing changed about rebuilds when changes. The PR only changes things about rebuilds when changes but stays the same. Put differently: we still emit for every env var we actually read. If we had build script helpers for that do the automatically, then they would behave like the post- code.
ah, I missed that only was changed and not . Yes, that fix seems right to me then. Probably you can rerun even less, right, only when it's a lookup () and not when it's a relative path ()? Maybe that's not happening in practice though.
It checks for and not for a lookup.
Change:
pub fn target() -> Target { let mut base = super::freebsd_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.pre_link_args.push("-m64".to_string()); Target {

Discussion:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"
Change:
fn sched_yield() -> libc::c_int; #[cfg(not(target_os = "macos"), not(target_os = "android"))] fn pthread_yield() -> libc::c_int; <ins> // This appears to be glibc specific #[cfg(target_os = "linux")] fn __pthread_get_minstack(attr: *libc::pthread_attr_t) -> libc::size_t; </ins> } }

Discussion:
Linking with certain external libraries can inflate the required amount of thread local storage to astronomical proportions. When the Rust runtime tries to create its threads, it requests a stack size independent of the TLS size, which can lead to pthreadcreate() failing with EINVAL when the stack size is smaller than the TLS size. This was apparently an issue for the Go runtime as well (). A potential workaround is to add statictls_size (+ possibly a guard page) to the requested stack size, but it's arguably a bug in glibc that TLS comes out of the requested stack, instead of being to it. This solution is also admittedly not very pleasing...
I made a mistake. The workaround should actually be to add _pthreadgetminstack(&attr) to the requested size in It's still not very pleasing.
This is the bug in glibc
Still relevant, but it's an upstream bug. Removing E-easy
Triage: we still call without adjusting for so I assume that the work-around hasn't been implemented, and the upstream bug is still open (and without activity for more than 3 months).
Triage: still a bug even with the pure Rust runtime. With it crashes with: and without that it runs fine. I'll attempt to fix it now.
(The above crash appears to not happen on Mac OSX; I'm on Linux.) I opened ; but I don't think that work-around is complete enough to close this.
My patch caused people linking errors ( is apparently not in all versions of glibc (works in 2.17, fails with 2.13), being a private function), so I'm reverting it in .