jiebi/CodeConvo huggingface dataset:
Code change:
() Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

Related discussion:
text: } #[derive(Diagnostic)] <del> #[diag(ast_passes_const_and_async)] pub(crate) struct ConstAndAsync { </del> <ins> #[diag(ast_passes_const_and_coroutine)] pub(crate) struct ConstAndCoroutine { </ins> #[primary_span] pub spans: Vec<Span>, #[label(ast_passes_const)] <del> pub cspan: Span, #[label(ast_passes_async)] pub aspan: Span, </del> <ins> pub const_span: Span, #[label(ast_passes_coroutine)] pub coroutine_span: Span, </ins> #[label] pub span: Span, <ins> pub coroutine_kind: &'static str, </ins> } #[derive(Diagnostic)]
Code change:
() Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

Related discussion:
text: ) => { eq_closure_binder(lb, rb) && lc == rc <del> && la.map_or(false, CoroutineKind::is_async) == ra.map_or(false, CoroutineKind::is_async) </del> <ins> && eq_coroutine_kind(*la, *ra) </ins> && lm == rm && eq_fn_decl(lf, rf) && eq_expr(le, re)
Code change:
() Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

Related discussion:
text: } } <ins> fn eq_coroutine_kind(a: Option<CoroutineKind>, b: Option<CoroutineKind>) -> bool { match (a, b) { (Some(CoroutineKind::Async { .. }), Some(CoroutineKind::Async { .. })) | (Some(CoroutineKind::Gen { .. }), Some(CoroutineKind::Gen { .. })) | (Some(CoroutineKind::AsyncGen { .. }), Some(CoroutineKind::AsyncGen { .. })) | (None, None) => true, _ => false, } } </ins> pub fn eq_field(l: &ExprField, r: &ExprField) -> bool { l.is_placeholder == r.is_placeholder && eq_id(l.ident, r.ident)
Code change:
() Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

Related discussion:
text: <ins> //@ edition:2024 //@ compile-flags: -Zunstable-options #![feature(gen_blocks)] const gen fn a() {} //~^ ERROR functions cannot be both `const` and `gen` const async gen fn b() {} //~^ ERROR functions cannot be both `const` and `async gen` fn main() {} </ins>
Code change:
() Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

Related discussion:
text: <ins> error: functions cannot be both `const` and `gen` --> $DIR/const_gen_fn.rs:6:1 | LL | const gen fn a() {} | ^^^^^-^^^---------- | |     | | |     `gen` because of this | `const` because of this error: functions cannot be both `const` and `async gen` --> $DIR/const_gen_fn.rs:9:1 | LL | const async gen fn b() {} | ^^^^^-^^^^^^^^^---------- | |     | | |     `async gen` because of this | `const` because of this error: aborting due to 2 previous errors </ins>
Code change:
The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)

Related discussion:
text: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Foo { fn bar(&mut self, other: &mut Foo); } struct Baz; impl Foo for Baz { fn bar(&mut self, other: &Foo) {} //~^ ERROR method `bar` has an incompatible type for trait: values differ in mutability [E0053] } fn main() {} </ins>
Code change:
The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)

Related discussion:
text: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(overloaded_calls)] use std::{fmt, ops}; struct Shower<T> { x: T } impl<T: fmt::Show> ops::Fn<(), ()> for Shower<T> { fn call(&self, _args: ()) { //~^ ERROR `call` has an incompatible type for trait: expected "rust-call" fn but found "Rust" fn println!("{}", self.x); } } fn make_shower<T>(x: T) -> Shower<T> { Shower { x: x } } pub fn main() { let show3 = make_shower(3i); show3(); } </ins>
Code change:
The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)

Related discussion:
text: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. enum Foo { A = 1i64, //~^ ERROR mismatched types: expected `int` but found `i64` B = 2u8 //~^ ERROR mismatched types: expected `int` but found `u8` } fn main() {} </ins>
Code change:
The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)

Related discussion:
text: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { if true { return } match () { () => { static MAGIC: uint = 0; } } } </ins>
Code change:
upstream/master:
Does that build include the fix in
Yes, include. 6:45 "Huon Wilson" notifications
Thanks for confirming. cc
Reproduced on revision . Note that I'm using win 8.1 with non-english locale which probably causes issues. Quick investigation: then convert the code into string. It seems that failed with .
So the issue is broken into two parts: 1. why rustdoc failed and called ? 2. why failed?

Related discussion:
text: buf.len() as DWORD, ptr::null()); if res == 0 { <del> fail!("[{}] FormatMessage failure", errno()); </del> <ins> // Sometimes FormatMessageW can fail e.g. system doesn't like langId, let fm_err = errno(); return format!("OS Error {} (FormatMessageW() returned error {})", err, fm_err); </ins> } <del> str::from_utf16(str::truncate_utf16_at_nul(buf)) .expect("FormatMessageW returned invalid UTF-16") </del> <ins> let msg = str::from_utf16(str::truncate_utf16_at_nul(buf)); match msg { Some(msg) => format!("OS Error {}: {}", err, msg), None => format!("OS Error {} (FormatMessageW() returned invalid UTF-16)", err), } </ins> } }
Code change:
The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.

Related discussion:
text: } else { cmd = Command::new(&output_file); if doctest.is_multiple_tests { <del> cmd.arg("*doctest-bin-path"); cmd.arg(&output_file); </del> <ins> cmd.env("RUSTDOC_DOCTEST_BIN_PATH", &output_file); </ins> } } if let Some(run_directory) = &rustdoc_options.test_run_directory {
Code change:
The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.

Related discussion:
text: use std::path::PathBuf; pub static BINARY_PATH: OnceLock<PathBuf> = OnceLock::new(); <del> pub const RUN_OPTION: &str = "*doctest-inner-test"; pub const BIN_OPTION: &str = "*doctest-bin-path"; </del> <ins> pub const RUN_OPTION: &str = "RUSTDOC_DOCTEST_RUN_NB_TEST"; </ins> #[allow(unused)] pub fn doctest_path() -> Option<&'static PathBuf> {{
Code change:
The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.

Related discussion:
text: #[allow(unused)] pub fn doctest_runner(bin: &std::path::Path, test_nb: usize) -> Result<(), String> {{ let out = std::process::Command::new(bin) <del> .arg(self::RUN_OPTION) .arg(test_nb.to_string()) </del> <ins> .env(self::RUN_OPTION, test_nb.to_string()) .args(std::env::args().skip(1).collect::<Vec<_>>()) </ins> .output() .expect("failed to run command"); if !out.status.success() {{
Code change:
The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.

Related discussion:
text: #[rustc_main] fn main() -> std::process::ExitCode {{ const TESTS: [test::TestDescAndFn; {nb_tests}] = [{ids}]; <del> let bin_marker = std::ffi::OsStr::new(__doctest_mod::BIN_OPTION); </del> let test_marker = std::ffi::OsStr::new(__doctest_mod::RUN_OPTION); let test_args = &[{test_args}]; <ins> const ENV_BIN: &'static str = "RUSTDOC_DOCTEST_BIN_PATH"; </ins> <del> let mut args = std::env::args_os().skip(1); while let Some(arg) = args.next() {{ if arg == bin_marker {{ let Some(binary) = args.next() else {{ panic!("missing argument after `{{}}`", __doctest_mod::BIN_OPTION); }}; if crate::__doctest_mod::BINARY_PATH.set(binary.into()).is_err() {{ panic!("`{{}}` option was used more than once", bin_marker.to_string_lossy()); }} return std::process::Termination::report(test::test_main(test_args, Vec::from(TESTS), None)); }} else if arg == test_marker {{ let Some(nb_test) = args.next() else {{ panic!("missing argument after `{{}}`", __doctest_mod::RUN_OPTION); }}; if let Some(nb_test) = nb_test.to_str().and_then(|nb| nb.parse::<usize>().ok()) {{ if let Some(test) = TESTS.get(nb_test) {{ if let test::StaticTestFn(f) = test.testfn {{ return std::process::Termination::report(f()); }} </del> <ins> if let Ok(binary) = std::env::var(ENV_BIN) {{ let _ = crate::__doctest_mod::BINARY_PATH.set(binary.into()); unsafe {{ std::env::remove_var(ENV_BIN); }} return std::process::Termination::report(test::test_main(test_args, Vec::from(TESTS), None)); }} else if let Ok(nb_test) = std::env::var(__doctest_mod::RUN_OPTION) {{ if let Ok(nb_test) = nb_test.parse::<usize>() {{ if let Some(test) = TESTS.get(nb_test) {{ if let test::StaticTestFn(f) = test.testfn {{ return std::process::Termination::report(f()); </ins> }} }} <del> panic!("Unexpected value after `{{}}`", __doctest_mod::RUN_OPTION); </del> }} <ins> panic!("Unexpected value for `{{}}`", __doctest_mod::RUN_OPTION); </ins> }} <del> eprintln!("WARNING: No argument provided so doctests will be run in the same process"); </del> <ins> eprintln!("WARNING: No rustdoc doctest environment variable provided so doctests will be run in  the same process"); </ins> std::process::Termination::report(test::test_main(test_args, Vec::from(TESTS), None)) }}", nb_tests = self.nb_tests,
Code change:
I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and

Related discussion:
text: if !verify_rustfmt_version(build) { return Ok(None); } get_git_modified_files(&build.config.git_config(), Some(&build.config.src), &["rs"]) }
Code change:
I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and

Related discussion:
text: use std::path::PathBuf; use std::{env, fs}; <del> use build_helper::git::warn_old_master_branch; </del> use crate::Build; #[cfg(not(feature = "bootstrap-self-test"))] use crate::builder::Builder;
Code change:
I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and

Related discussion:
text: if let Some(ref s) = build.config.ccache { cmd_finder.must_have(s); } <del> warn_old_master_branch(&build.config.git_config(), &build.config.src); </del> }
Code change:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.

Related discussion:
text: }, Primitive::F32 => types::F32, Primitive::F64 => types::F64, <del> Primitive::Pointer => pointer_ty(tcx), </del> <ins> // FIXME(erikdesjardins): handle non-default addrspace ptr sizes Primitive::Pointer(_) => pointer_ty(tcx), </ins> } }
Code change:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.

Related discussion:
text: pub(crate) use cpuid::codegen_cpuid_call; pub(crate) use llvm::codegen_llvm_intrinsic_call; <ins> use rustc_middle::ty::layout::HasParamEnv; </ins> use rustc_middle::ty::print::with_no_trimmed_paths; use rustc_middle::ty::subst::SubstsRef; use rustc_span::symbol::{kw, sym, Symbol};
Code change:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.

Related discussion:
text: return; } <del> if intrinsic == sym::assert_zero_valid && !fx.tcx.permits_zero_init(layout) { </del> <ins> if intrinsic == sym::assert_zero_valid && !fx.tcx.permits_zero_init(fx.param_env().and(layout)) { </ins> with_no_trimmed_paths!({ crate::base::codegen_panic( fx,
Code change:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.

Related discussion:
text: } if intrinsic == sym::assert_mem_uninitialized_valid <del> && !fx.tcx.permits_uninit_init(layout) </del> <ins> && !fx.tcx.permits_uninit_init(fx.param_env().and(layout)) </ins> { with_no_trimmed_paths!({ crate::base::codegen_panic(
Code change:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.

Related discussion:
text: is_main_fn: bool, sigpipe: u8, ) { <del> let main_ret_ty = tcx.fn_sig(rust_main_def_id).output(); </del> <ins> let main_ret_ty = tcx.bound_fn_sig(rust_main_def_id).subst_identity().output(); </ins> // Given that `main()` has no arguments, // then its return type cannot have // late-bound regions, since late-bound
Code change:
See I propose to change the license of Non trivial contributors: OK OK OK (MoCo employee) Contributors appearing in git blame that are trivial (trivial update due to language changes): OK (MoCo employee) OK OK (MoCo employee) OK OK OK OK OK OK (sent agreement to by email) 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 any previous contributions to according to the term of the computer Language Benchmarks Game license (
We don't need statements from Graydon or Marijn as they both contributed as employees. On Jun 7, 2014 5:50 AM, "TeXitoi" wrote:
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
Op updated. could you please respond?
Citing in a private email: can I consider the contribution of negligible? the same for renaming? If yes I can propose a PR for this and for
guh, I suppose so, though I'm disappointed that didn't cooperate.
My change is obviously trivial and I have zero copyright over anything to do with the shootout benchmarks, but if you must, then: I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
OP updated. Thanks. I'll wait some days to see if respond to my email.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()

Related discussion:
text: "libstd/sync/spsc_queue.rs", # BSD "libstd/sync/mpmc_bounded_queue.rs", # BSD "libsync/mpsc_intrusive.rs", # BSD <ins> "test/bench/shootout-binarytrees.rs", # BSD </ins> "test/bench/shootout-fannkuch-redux.rs", # BSD "test/bench/shootout-meteor.rs", # BSD "test/bench/shootout-regex-dna.rs", # BSD
Code change:
Currently, pointers stored on the stack aren't word-aligned. This is a critical issue because it causes stack growth to fail most of the time.
Commit disables task growth for now until this is fixed.
WONTFIX (moot point given disabled stack growth)

Related discussion:
text: rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done