jiebi/CodeConvo huggingface dataset:
Change:
<ins> // run-rustfix #![allow(unused, nonstandard_style)] mod m { #[macro_export] macro_rules! nu { {} => {}; } pub struct other_item; use ::nu; pub use self::{other_item as _}; //~^ ERROR unresolved import `self::nu` [E0432] //~| HELP a macro with this name exists at the root of the crate } 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. 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: <details<summaryIf the starting order is reversed, the suggestion puts the macro first in the tree</summary</detailsThis is suggesting to change the code to itself It needs to move the import into a tree; the easy way is to make a new statement (and let rustfmt clean that up); the medium way is to find an existing context; the hard way is when a tree root doesn't already exist (or isn't immediately a tree at that point) determine what the code is using and match that. Related: label +D-confusing +D-incorrect
In this case, the ideal solution is actually to write just and get the import from legacy-lexical-macro-scope into the namespace. I originally hit this with just multiple macros in the use tree, and removing the was the correct fix. I "simplified" for the error report to use a second non-macro item here (to reduce the number of diagnostics). So bonus challenge: handle this case properly and only emit a single help: <details
label +D-invalid-suggestion It's not producing invalid code, but it's surely suggesting a fix which will cause an error (the identical one).
Change:
"30", // timeout if cannot connect within 30 seconds "-o", tempfile.to_str().unwrap(), <ins> "--continue-at", "-", </ins> "--retry", "3", "-SRf",

Discussion:
We're passing --retry: but by default that only retries 500 errors, not any error: Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is a regression from when I moved the downloads from python to rust (about a year ago now I think).
Mentoring instructions: Add the option to the invocations, in and This doesn't affect the Windows Powershell fallback, since we already retry on any error. There are many other invocations across the repo, but they seem to not be causing problems.
claim
This is quite new flag shipped with recent versions of curl, which is not supported on many machines/platforms(including our CI runners). We can consider using as I also suggest at
I'd like to take a look at this. Looking through the PR history, we would like basic retry logic written in Rust versus using a curl flag like to retry during the bootstrap process. If it's a 404, then do not retry, but any other errors should be retried. I assume there is a http library already vendored in, so no new dependencies should be .
claim
Thanks! This shouldn't be needed. For now, retrying on "connection refused" () should be fine.
I'm a little confused as to why was closed then. What more is there beyond adding the retry refused connections flag?
I forgot that our CI runners depend on very old curl versions which doesn't support the flag I suggested. Sorry, you are right. As jyn also said() in that PR, we can handle this in Rust
are we ok with adding the dependency to facilitate sending requests to the payload URL? I'm very hesitant to add another crate dependency to the core payload. But without it, we would need to manually built a request via the standard library tcp library. Which is a little awkward. doesn't actually have support for sending requests. I suppose, in the case we decide to use it, another library would need to be as well?
What about using curl arguments to read the status code and handle it in rust logic? It might be a bit ugly, but adding a dependency solely for this purpose seems like overkill to me.
I agree adding a new dep seems extreme.

I can try parsing the curl exit code, great idea.
claim
claim
Hello Is this still relevant?
please don't ping me about rust-lang/ issues. is the current maintainer.
We didn't change any curl flags since then; it should be still relevant.
release-assignment
Change:
"libsync/mpmc_bounded_queue.rs", # BSD "libsync/mpsc_intrusive.rs", # BSD "test/bench/shootout-binarytrees.rs", # BSD <ins> "test/bench/shootout-chameneos-redux.rs", # BSD </ins> "test/bench/shootout-fannkuch-redux.rs", # BSD "test/bench/shootout-k-nucleotide.rs", # BSD "test/bench/shootout-mandelbrot.rs", # BSD

Discussion:
See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial (except artifacts as empty lines): OK OK OK OK OK (MoCo employee) OK OK OK OK (MoCo employee) OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense my contributions to the benchmarks under src/test/bench/ (including shootout-chameneos-) according to the terms of the Computer Language Benchmarks Game license ().
I believe that was a MoCo employee at the time of all his contributions to this benchmark, so we're probably good on that front.
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. // Test for issue #18804, #[linkage] does not propagate thorugh generic // functions. Failure results in a linker error. // ignore-asmjs no weak symbol support // ignore-emscripten no weak symbol support // aux-build:lib.rs extern crate lib; fn main() { lib::foo::<i32>(); } </ins>

Discussion:
For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by
Change:
//     generics.types: //         0  1  2 //       Self T1 T2 <del> // And it can be seen that to move from a substs offset to a // generics offset you just have to offset by the number of regions. </del> <ins> // // And it can be seen that in both cases, to move from a substs // offset to a generics offset you just have to offset by the // number of regions. </ins> let type_param_offset = self.regions.len(); <ins> let has_self = self.has_self && self.parent.is_none(); let is_separated_self = type_param_offset != 0 && idx == 0 && has_self; </ins> if let Some(idx) = (idx as usize).checked_sub(type_param_offset) { <del> assert!(!(self.has_self && idx == 0)); </del> <ins> assert!(!is_separated_self, "found a Self after type_param_offset"); </ins> &self.types[idx] } else { <del> assert!(self.has_self && idx == 0); </del> <ins> assert!(is_separated_self, "non-Self param before type_param_offset"); </ins> &self.types[0] } } else {

Discussion:
When using to build one of my projects, I got the error I tried to minimize my code and got to . : with the command I got the error : : backtrace :
I can reproduce this with:
Change:
match *pointee_ty.kind() { ty::Str | ty::Slice(_) => Some(FatPtrKind::Slice), ty::Dynamic(..) => Some(FatPtrKind::Dyn), <del> ty::Adt(adt_def, _) => { assert!(adt_def.is_struct()); assert!(adt_def.variants.len() == 1); let variant = &adt_def.variants[VariantIdx::from_usize(0)]; assert!(!variant.fields.is_empty()); let last_field_index = variant.fields.len() - 1; </del> <ins> ty::Adt(..) | ty::Tuple(..) if matches!(layout.variants, Variants::Single { .. }) => { let last_field_index = layout.fields.count() - 1; </ins> debug_assert!( (0..last_field_index) .all(|field_index| { !layout.field(cx, field_index).is_unsized() }) ); let unsized_field = layout.field(cx, last_field_index); <del> assert!(unsized_field.is_unsized()); </del> <ins> debug_assert!(unsized_field.is_unsized()); </ins> fat_pointer_kind(cx, unsized_field.ty) } ty::Foreign(_) => {

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. --code 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc It looks like this might be related to
reports that this is regression in (which is indeed in PR ).
reports in zulip that this test case fails at that same injection point when combined with (aka ): ./src/test/run-pass-valgrind/dst-dtor-4.rs : <details<summaryContent of above file</summary</details
Files that reproduce the ice one way or another with : `
Thanks for the bug report, I'll look into it.
Looks like this should be an easy fix. The code just doesn't expect tuples to be unsized (which of course it should).
Change:
<ins> // check-pass // edition: 2018 mod outer { mod inner { pub mod inner2 {} } pub(crate) use inner::{}; pub(crate) use inner::{{}}; pub(crate) use inner::{inner2::{}}; pub(crate) use inner::{inner2::{{}}}; } fn main() {} </ins>

Discussion:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!
Change:
<ins> // build-fail //~^ ERROR cycle detected when computing layout of `Foo<()>` // Regression test for a stack overflow: https://github.com/rust-lang/rust/issues/113197 trait A { type Assoc; } impl A for () { type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() { Foo::<()>(todo!()); } </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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium
Change:
targetflags.extend(builder.lld_flags(target)); cmd.arg("--target-rustcflags").arg(targetflags.join(" ")); <del> cmd.arg("--docck-python").arg(builder.python()); cmd.arg("--lldb-python").arg(builder.python()); </del> <ins> cmd.arg("--python").arg(builder.python()); </ins> if let Some(ref gdb) = builder.config.gdb { cmd.arg("--gdb").arg(gdb);

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:
<del> Subproject commit 19a0de242f442ac7149c511031599aafa35b36dc </del> <ins> Subproject commit 86134e7666a088682f20b76278c3ee096a315218 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 compiler team prioritization.
Change:
Null, } <ins> #[derive(Debug)] </ins> pub enum Stdio { Inherit, Null,

Discussion:
currently only outputs the program and it's arguments. It should also output the environment variables and the current path, as set by , and . This would help with figuring out what's going on :-)
We also currently have no way to extract most of this information without utilizing Debug, so out of tree implementations can't be implemented.
Would/should this be the specific additions to the environment set by , or the actual environment? The most straightforward implementation of this (debug-printing the individual fields of the internal struct) seems to do the latter. That is, this patch (in )— results in program behavior like this (scroll right to see the very bulky output; should be verbose, but how verbose is too verbose??):
I'd be fine with the verbose output. The debug output is only meant for debug purposes and generating the full environment saves us from oh-that's-why-it's-not-working-this-stupid-thing moments
Seems reasonable. I would be ready to consider a PR implementing this.
Triage: no changes here. I've actually wanted this too, but don't have the bandwidth to work on it, personally.
Change:
// ignore-cross-compile <del> // error-pattern:expected identifier, found keyword `let` </del> <ins> // error-pattern:expected expression, found statement (`let`) </ins> #![feature(quote, rustc_private)]

Discussion:
This code isn't valid Rust: We have an okay, but not great, diagnostic here: It might be nice to add a when the keyword found is that mentions that is not an expression, and so cannot be used in this way.
want to work on this? It's a similar task to the other doc comment one, but much simpler since it's a very specific situation.
I'd be happy to help someone :)
So, the parser already has its ways to differentiate keywords from identifiers. All we have to do is find the right place where that error is thrown, check whether it's a and add a note along with the error. The parser has all sorts of code, and adding a note's also around there somewhere :) Code:
I would like to try this. :)
Awesome! Feel free to ask waffles or me for help (you can find us both on IRC on #rust-internals), or ask questions here. (self-assigning since I can't assign to you -- just to mark it as "being taken")
Change:
/// Checks if the value is an ASCII graphic character: /// U+0021 '@' ... U+007E '~'. /// For strings, true if all characters in the string are <del> /// ASCII punctuation. </del> <ins> /// ASCII graphic characters. </ins> /// /// # Note ///

Discussion:
The documentation for is incorrect. Checks if the value is an ASCII graphic character: U+0021 ' ... U+007E '~'. For strings, true if all characters in the string are ASCII punctuation. This seems like an accidental copy-paste error from Also, the isascii_punctuation`, and could be fixed, but that's a minor issue
The quoting issue in the nightly version of the docs.
Change:
<ins> // aux-build:panic-handler.rs // compile-flags: --document-private-items // build-pass // ignore-windows #![no_std] #![no_main] #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { loop {} } </ins>

Discussion:
It seems like fails is there is a dependency that has a and a binary that defines it as well, even if the dependency is never imported. I ran into this issue when I had 1 nostd bin per crate, where one binary had a custom panic_impl and another used that from a dependency. Minimal reproduction: The following works: But this fails (also when specifying target) : label +T-rustdoc
Possibly similar cause:
Seems like this happens even with so not really a good workaround, yuck...
I can't reproduce the bug locally. Do you still have the issue?
Interesting - it looks like it was broken on but working on my current . Probably not worth bisecting, but maybe a regression test would be good if there isn't one?
Agreed, wanna add one? Otherwise I plan to do it in the next hours.
I'm not too familiar with the test patterns for rustdoc, so I'll just leave it to you if you don't mind
No problem!
Change:
} #[test] <ins> fn connect_timeout_unbound() { // bind and drop a socket to track down a "probably unassigned" port let socket = TcpListener::bind("127.0.0.1:0").unwrap(); let addr = socket.local_addr().unwrap(); drop(socket); let timeout = Duration::from_secs(1); let e = TcpStream::connect_timeout(&addr, timeout).unwrap_err(); assert!(e.kind() == io::ErrorKind::ConnectionRefused || e.kind() == io::ErrorKind::TimedOut || e.kind() == io::ErrorKind::Other, "bad error: {} {:?}", e, e.kind()); } #[test] </ins> fn connect_timeout_valid() { let listener = TcpListener::bind("127.0.0.1:0").unwrap(); let addr = listener.local_addr().unwrap();

Discussion:
This program succeeds on Linux, even though it shouldn't (assuming you don't have a listener on 1234). Trying to do anything with the socket produces .
Interestingly it does behave as expected on macOS.
Works under WSL as well. Native linux it fails spectacularly.
From an strace, it looks like Linux sets all of , , and at once. We treat as success, but it seems like we should be checking for instead:
Fix here:
Change:
<ins> // revisions: public private // [private]compile-flags: --document-private-items // check-pass // There are 4 cases here: // 1. public item  -> public type:  no warning // 2. public item  -> private type: warning, if --document-private-items is not passed // 3. private item -> public type:  no warning // 4. private item -> private type: no warning // All 4 cases are tested with and without --document-private-items. // // Case 4 without --document-private-items is the one described in issue #74134. struct PrivateType; pub struct PublicType; pub struct Public { /// [`PublicType`] /// [`PrivateType`] //[public]~^ WARNING public documentation for `public_item` links to a private pub public_item: u32, /// [`PublicType`] /// [`PrivateType`] private_item: u32, } // The following cases are identical to the ones above, except that they are in a private // module. Thus they all fall into cases 3 and 4 and should not produce a warning. mod private { pub struct Public { /// [`super::PublicType`] /// [`super::PrivateType`] pub public_item: u32, /// [`super::PublicType`] /// [`super::PrivateType`] private_item: u32, } } </ins>

Discussion:
With merged (current nightly, e.g. ) , the following code now produces a warning: This triggers : But rustdoc never actually generates any links to , because it wasn't run with . In my opinion it shouldn't emit warning in this case, because documenting the internals can be very useful to contributors or even future me when is used. There has already been some discussion at the end of , which is where I asked first about whether this change was intentional.
modify labels: T-rustdoc A-intra-doc-links
Assuming the consensus is that rustdoc shouldn't warn in this case, would an additional check against the 's visibility be correct? Like: That certainly gets rid of the warning in my case, but I'm unsure about the other variants of and all the other kinds of things can refer to.
That looks reasonable to me. Could you make a PR with that change and a few test cases?
Wouldn't the check like I changed it then only catch cases like this: But that already triggers anyway:
the link is entirely separate from the type of the field. You could have in which case there would be no error but the warning should still be generated.
Ah, yes of course, thanks for pointing that out :) I'll open a PR then.
Change:
- name: x86_64-gnu-llvm-12 <<: *job-linux-xl - name: x86_64-gnu-tools env: CI_ONLY_WHEN_SUBMODULES_CHANGED: 1

Discussion:
Similar to , we expect contributors to run this frequently, so it should be tested in CI. suggested using the defaults in but I'm a little hesitant to do that because some of them are very wrong for CI (e.g. ) and others shouldn't affect tests but make the compiler slower (e.g. ). I do agree we should enable incremental for these tests, though. Not sure which builder to add these to - adding it to mingw-check would make it significantly slower, and I don't know which of the full builders has spare capacity. do you have suggestions? Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
To be clear, I was mistakenly under the impression that only stage1 tests were ran for PR CI. But I could see how that may be an issue for tests (though, is it easy to only run those in stage2?).
ah yeah no, we currently run in PR CI. I think it might make sense to only run now that you mention it though! would be a lot faster and in practice there are very few tests that only fail in stage 2. not currently, no - I think it wouldn't be impossible to add to compiletest though, it already does filtering and parses the headers, so it should be possible to combine the two. That would mean we have to build the stage 2 compiler though, so if we switch to stage 1 I think it would be ok to only run those in a full bors merge, not in PR CI.
just add another builder, we have capacity for that.
If we do get another builder, can we have incremental enabled on it (or rather, whichever dev profile enables that)? Some codegen tests haven't been passing for a short while because of the difference, and might be good to be tracking something that strongly resembles local workflows.
Error: Parsing assign command in failed: ...'bot assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
What is the correct course of action here? Adding another builder?
Yes, adding another builder is enough.

I want to investigate running --stage 1 in PR CI instead of --stage 2 long term, but that's harder and shouldn't block testing this.
This would have caught , I assume?
Yes, despite not being filed as an issue, that's exactly the kind of test failure I was referencing in (it does require that we do enable incremental, not just test at stage 1).