jiebi/CodeConvo huggingface dataset:
Code change:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

Related discussion:
text: } <del> // Check for overloaded operators if allowed. </del> <ins> // Check for overloaded operators if not an assignment. </ins> let result_t; <del> if allow_overloaded_operators == AllowOverloadedOperators { </del> <ins> if is_binop_assignment == SimpleBinop { </ins> result_t = check_user_binop(fcx, callee_id, expr,
Code change:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

Related discussion:
text: } else { fcx.type_error_message(expr.span, |actual| { <del> format!("binary operation {} cannot be  applied to type `{}`", ast_util::binop_to_str(op), actual) </del> <ins> format!("binary assignment operation  {}= cannot be applied to type `{}`", ast_util::binop_to_str(op), actual) </ins> }, lhs_t, None); <ins> check_expr(fcx, rhs); </ins> result_t = ty::mk_err(); }
Code change:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

Related discussion:
text: lhs, rhs, expected, <del> AllowOverloadedOperators); </del> <ins> SimpleBinop); </ins> let lhs_ty = fcx.expr_ty(lhs); let rhs_ty = fcx.expr_ty(rhs);
Code change:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

Related discussion:
text: lhs, rhs, expected, <del> DontAllowOverloadedOperators); </del> <ins> BinopAssignment); </ins> let lhs_t = fcx.expr_ty(lhs); let result_t = fcx.expr_ty(expr);
Code change:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

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. struct Foo; fn main() { let mut a = Foo; let ref b = Foo; a += *b; //~ Error: binary assignment operation += cannot be applied to type `Foo` } </ins>
Code change:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:

Related discussion:
text: // Regression test for issue #5239 fn main() { <del> let x: |int| -> int = |ref x| { x += 1; }; //~ ERROR binary operation + cannot be applied to type `&int` </del> <ins> let x: |int| -> int = |ref x| { x += 1; }; //~ ERROR binary assignment operation += cannot be applied to type `&int` </ins> }
Code change:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.

Related discussion:
text: } } <ins> all_native_libs.extend_from_slice(&codegen_results.crate_info.used_libraries); </ins> if sess.opts.prints.contains(&PrintRequest::NativeStaticLibs) { print_native_static_libs(sess, &all_native_libs, &all_rust_dylibs); }
Code change:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.

Related discussion:
text: <ins> include ../tools.mk # ignore-cross-compile # ignore-wasm all: $(RUSTC) --crate-type rlib -lbar_cli bar.rs $(RUSTC) foo.rs -lfoo_cli --crate-type staticlib --print native-static-libs 2>&1  | grep 'note: native-static-libs: '  | sed 's/note: native-static-libs: (.*)/1/' > $(TMPDIR)/libs.txt cat $(TMPDIR)/libs.txt | grep -F "glib-2.0" # in bar.rs cat $(TMPDIR)/libs.txt | grep -F "systemd" # in foo.rs cat $(TMPDIR)/libs.txt | grep -F "bar_cli" cat $(TMPDIR)/libs.txt | grep -F "foo_cli" </ins>
Code change:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.

Related discussion:
text: <ins> #[no_mangle] pub extern "C" fn my_bar_add(left: i32, right: i32) -> i32 { // Obviously makes no sense but... unsafe { g_free(std::ptr::null_mut()); } left + right } #[link(name = "glib-2.0")] extern "C" { fn g_free(p: *mut ()); } </ins>
Code change:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.

Related discussion:
text: <ins> extern crate bar; #[no_mangle] pub extern "C" fn my_foo_add(left: i32, right: i32) -> i32 { // Obviously makes no sense but... unsafe { init(std::ptr::null_mut()); } bar::my_bar_add(left, right) } #[link(name = "systemd")] extern "C" { fn init(p: *mut ()); } </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim

Related discussion:
text: <ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] // Check that we don't crash when printing inherent projections in diagnostics. pub struct Carrier<'a>(&'a ()); pub type User = for<'b> fn(Carrier<'b>::Focus<i32>); impl<'a> Carrier<'a> { pub type Focus<T> = &'a mut User; //~ ERROR overflow evaluating associated type } fn main() {} </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim

Related discussion:
text: <ins> error: overflow evaluating associated type `Carrier<'b>::Focus<i32>` --> $DIR/issue-111879-0.rs:11:25 | LL |     pub type Focus<T> = &'a mut User; |                         ^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim

Related discussion:
text: <ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] // Check that we don't crash when printing inherent projections in diagnostics. struct Foo<T>(T); impl<'a> Foo<fn(&'a ())> { type Assoc = &'a (); } fn main(_: for<'a> fn(Foo<fn(&'a ())>::Assoc)) {} //~ ERROR `main` function has wrong type </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim

Related discussion:
text: <ins> error[E0580]: `main` function has wrong type --> $DIR/issue-111879-1.rs:12:1 | LL | fn main(_: for<'a> fn(Foo<fn(&'a ())>::Assoc)) {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ incorrect number of function parameters | = note: expected fn pointer `fn()` found fn pointer `fn(for<'a> fn(Foo<fn(&'a ())>::Assoc))` error: aborting due to previous error For more information about this error, try `rustc --explain E0580`. </ins>
Code change:
Sometimes when changing compiler internals, I run to make sure I didn't break tools and codegen backends. This also checks rust-analyzer by default, which is not very useful, I cannot break that. If we want to keep that, it would at least be useful to put it last so I can Ctrl-C out of it. Currently, rustfmt is checked after rust-analyzer. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
mentoring instructions: switch the order of these two lines:
points out that Cargo also isn't checked by default, so for consistency it would be nice for RustAnalyzer not to be either:
claim

Related discussion:
text: check::CargoMiri, check::MiroptTestTools, check::Rls, <del> check::RustAnalyzer, </del> check::Rustfmt, <ins> check::RustAnalyzer, </ins> check::Bootstrap ), Kind::Test => describe!(
Code change:
Sometimes when changing compiler internals, I run to make sure I didn't break tools and codegen backends. This also checks rust-analyzer by default, which is not very useful, I cannot break that. If we want to keep that, it would at least be useful to put it last so I can Ctrl-C out of it. Currently, rustfmt is checked after rust-analyzer. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
mentoring instructions: switch the order of these two lines:
points out that Cargo also isn't checked by default, so for consistency it would be nice for RustAnalyzer not to be either:
claim

Related discussion:
text: impl Step for RustAnalyzer { type Output = (); const ONLY_HOSTS: bool = true; <del> const DEFAULT: bool = true; </del> <ins> const DEFAULT: bool = false; </ins> fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/rust-analyzer")
Code change:
I tried to enable vendoring in and then following the instructions given by . I expected to see this happen: All dependencies are vendored. Instead, this happened: To work around this, I need to explicitly use a nightly cargo. Caused by enabling the unstable cargo feature.
This also broke the rust-analyzer config as rust-analyzer fetches the workspace layout using the default toolchain which for most users is stable.
can we override the cargo that rust-analyzer uses? we should use the beta toolchain for consistency.
I can't find any configuration for that.
ok. i think we should consider reverting . why did you need a new cargo feature to make that PR work?
So, how are people going to dogfood unstable Cargo features before they get stabilized if rust-analyzer breaks on it? In any case, I used an unstable Cargo feature because I wanted to use the private dependency metadata in the rlib, and that means Cargo needs to actually mark the dependency as private, and that means needs to communicate this information to Cargo.
As a hack you could handle marking deps as private and public in .
I am stumbling over this too. So is the only workaround ?
You can also put between and to override the toolchain to use for just a single call. I'm not aware of any other workaround than using nightly or using the unstable with a recent enough stable/beta cargo.
This is no longer a problem since I think?
Does that also add RUSTC_BOOTSTRAP=1 to the vendor command shown by x.py?
Oh wait, I didn't see the manually invoked part.

Related discussion:
text: if toml_val is not None: env["{}_{}".format(var_name, host_triple_sanitized)] = toml_val <ins> # In src/etc/rust_analyzer_settings.json, we configure rust-analyzer to # pass RUSTC_BOOTSTRAP=1 to all cargo invocations because the standard # library uses unstable Cargo features. Without RUSTC_BOOTSTRAP, # rust-analyzer would fail to fetch workspace layout when the system's # default toolchain is not nightly. # # But that setting has the collateral effect of rust-analyzer also # passing RUSTC_BOOTSTRAP=1 to all x.py invocations too (the various # overrideCommand). For compiling bootstrap, that is unwanted and can # cause spurious rebuilding of bootstrap when rust-analyzer x.py # invocations are interleaved with handwritten ones on the command line. env.pop("RUSTC_BOOTSTRAP", None) </ins> # preserve existing RUSTFLAGS env.setdefault("RUSTFLAGS", "")