jiebi/CodeConvo huggingface dataset:
Code change:
<ins> error[E0119]: conflicting implementations of trait `Bar` for type `()` --> $DIR/dont-drop-upcast-candidate.rs:10:1 | LL | impl<T> Bar for T where dyn Foo: Unsize<dyn Bar> {} | ------------------------------------------------ first implementation here LL | impl Bar for () {} | ^^^^^^^^^^^^^^^ conflicting implementation for `()` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0119`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: !self.intercrate'', 'thread 'rustc' panicked at 'assertion failed: !self.intercrate'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait -- label +F-Unsize +F-unsize
The bisection looks incorrect? is from 1.77, and this looks to be from 1.72 to me.
Too lazy to look at its PRs :
Due to . This assertion is correct, and we probably shouldn't drop candidates in intercrate mode, since this is incomplete. I would say this fix is low-pri because of the fact that is not expected to be referenced.
Code change:
fn check_trait_fn_not_async(&self, span: Span, asyncness: IsAsync) { if asyncness.is_async() { <del> struct_span_err!(self.session, span, E0706, "trait fns cannot be declared `async`").emit() </del> <ins> struct_span_err!(self.session, span, E0706, "trait fns cannot be declared `async`") .note("`async` trait functions are not currently supported") .note("consider using the `async-trait` crate:  https://crates.io/crates/async-trait") .emit(); </ins> } }

Related discussion:
text: we currently emit We should tell people that trait functions are not possible , and possibly point them to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Created
Code change:
// Note that currently the `wasm-import-module` doesn't do anything, but // eventually LLVM 7 should read this and ferry the appropriate import // module to the output file. <del> if cx.tcx.sess.target.target.arch == "wasm32" { if let Some(module) = wasm_import_module(cx.tcx, id) { llvm::AddFunctionAttrStringValue( llfn, llvm::AttributePlace::Function, const_cstr!("wasm-import-module"), &module, ); </del> <ins> if let Some(id) = id { if cx.tcx.sess.target.target.arch == "wasm32" { if let Some(module) = wasm_import_module(cx.tcx, id) { llvm::AddFunctionAttrStringValue( llfn, llvm::AttributePlace::Function, const_cstr!("wasm-import-module"), &module, ); } </ins> } } }

Related discussion:
text: and are both broken on s390x since Rust 1.28. When is built without debuginfo, the tests hang with their backtracing processes stuck in a loop. With debuginfo, it fails with output like: I believe the problem is this part of : where doesn't identify that is a 64-bit platform. See also alexcrichton/backtrace-rs. I plan to update that here when it's published, and make a similar fix in .
fixes the backtrace when is built with debuginfo, but I'm still getting a hang without. In GDB, it looks like the unwinder gets to the that catches panics, then loops unwinding that same PC forever. This part of the regression is older -- happens on 1.27.2 as well, but 1.26.2 is fine. Binaries from the older version don't appear to have a distinct symbol at all, but maybe that's just inlined differently. I'm bisecting for that hang now.
Bisecting pointed me at (cc which attributes to all functions. For s390x the base features actually include a removal, . But it doesn't look like the features are applied to the synthesized (), and as a result it doesn't get inlined anymore since it has more features (w/ ) than the callee. We probably should apply target-features to as well. I don't know why the non-inlined can't be unwound -- maybe we need to force ? By default GDB backtrace stops at crate , but tries to go further: Maybe Rust's could have a similar defensive check, at least.
Nice find Definitely makes sense to me, and this should be fixed up (at least the business) in
With , , and , I believe we have this fixed.
Code 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. #![feature(nll)] fn main() { let foo = &16; //~^ HELP consider changing this to be a mutable reference //~| SUGGESTION &mut 16 *foo = 32; //~^ ERROR cannot assign to `*foo` which is behind a `&` reference let bar = foo; //~^ HELP consider changing this to be a mutable reference //~| SUGGESTION &mut i32 *bar = 64; //~^ ERROR cannot assign to `*bar` which is behind a `&` reference } </ins>

Related discussion:
text: When I build this code on nightly... ...I get these errors: The first error is fine, but the second one is missing the first character of . It looks like rustc assumes the first character is an and removes it without checking. :
Currently working on a fix here: Still need to add UI tests, which I'll do once I figure out how they work.
Adding to the Rust 2018 Edition Preview milestone. Has a pending PR, too.
Code change:
|              help: replace `_` with the correct type: `i32` error[E0121]: the type placeholder `_` is not allowed within types on item signatures <ins> --> $DIR/typeck_type_placeholder_item.rs:197:26 | LL |     type F: std::ops::Fn(_); |                          ^ not allowed in type signatures error[E0121]: the type placeholder `_` is not allowed within types on item signatures </ins> --> $DIR/typeck_type_placeholder_item.rs:40:24 | LL |     fn test9(&self) -> _ { () }

Related discussion:
text: First time filing a bug report, apologies if i missed anything or if this is a duplicate. Encountered this bug while writing some non-sensical associated function types. Searched around for any similar issues and the closest i found was , seems closely related? Minimal example: Playground link: The ICE happens on all channels it seems
Yes, I think so too. The snippet is rejected as expected on 1.42 but ICE occurs instead since 1.43.
Assigning as and removing .
Code change:
<ins> // aux-build:impl-const.rs // run-pass #![feature(const_generics)] #![allow(incomplete_features)] extern crate impl_const; use impl_const::*; pub fn main() { let n = Num::<5>; n.five(); } </ins>

Related discussion:
text: Currently with const generics you can create a "specialized" implementation, such as: Which has the following output: (playground link: ) However, when using such a type in another crate this causes a stack overflow in the compiler. For example, with the following code (full example: ): I would expect it to produce the same output as the playground link above, however it produces the following:
A bisect shows this stopped crashing after , marked as needing a test
I was still encountering this in my code with and after trying to minimize it seems that the original example is fixed but the stack overflow still occurs when the const expression in the has braces around it. After experimenting I found some more examples of what works and what doesn't: (see to try it) compiles and runs successfully while and (or ) crash the compiler with the same error as the original: :
Code change:
/// } /// ``` #[stable(feature = "io_error_inner", since = "1.3.0")] <ins> #[inline] </ins> pub fn into_inner(self) -> Option<Box<dyn error::Error + Send + Sync>> { match self.repr { Repr::Os(..) => None,

Related discussion:
text: I am facing a problem while reading different kinds of binary formats. If you are going to read primitives like too often, then performance degrades. This is mainly due to the fact that returns box. Also it does boxing TWICE! doc link: I wrote simple bench to show pref problem. Use to get it We can clearly see that performance is degrading. The more calls it takes to read, the worse the results will be. The first very popular crate that comes to mind is . It mainly depends on the data format. But what if you need to receive data over the network? The attacker may abuse wrong data to make ton of pointless memory allocations. stdlib is also use often enough. Let's run a simple bash to make sure of this In many cases, you will see that it is used . stdlib sometimes create with macro, however it doesn't happen very often. Consider adding a new static method such as and new internal member of that's enum. How about using something like , but with static lifetime? : Update 07.03.2021: Benchmarks have been improved as per the comment. This should show the problem better.
The "std_err" bench is still pretty slow though
Yes, I probably made a mistake while copying the code for the benchmark of . It should be . However, this shows that not zero-cost.
This is fixed by
Turns out it was three times, if you also count the that the is copied into.
Running your benchmark (thanks!): Before: After: Looks like it isn't completely solved yet. Adding to now... :)
That fixed it.
Code change:
<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 { proc(_) {} } else { proc(_: &mut ()) {} }; } </ins>

Related discussion:
text: Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.
Code change:
<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 { proc(_) {} } else { proc(_: &mut ()) {} }; } </ins>

Related discussion:
text: Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.
Code change:
<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 { proc(_) {} } else { proc(_: &mut ()) {} }; } </ins>

Related discussion:
text: Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)
Code change:
<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 { proc(_) {} } else { proc(_: &mut ()) {} }; } </ins>

Related discussion:
text: It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.
Code change:
let bin_root = self.out.join(host.triple).join("rustfmt"); let rustfmt_path = bin_root.join("bin").join(exe("rustfmt", host)); let rustfmt_stamp = bin_root.join(".rustfmt-stamp"); <ins> let legacy_rustfmt = self.initial_rustc.with_file_name(exe("rustfmt", host)); if !legacy_rustfmt.exists() { t!(self.symlink_file(&rustfmt_path, &legacy_rustfmt)); } </ins> if rustfmt_path.exists() && !program_out_of_date(&rustfmt_stamp, &channel) { return Some(rustfmt_path); }

Related discussion:
text: broke the rust-analyzer config we suggest in the dev-guide: https://rustc-dev- since now rustfmt is in instead of . Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Hi! Just to clarify, the idea is to change to code to match the docs?
I think the idea is changing the docs to match the new behavior.
For reference:
I'd prefer to change the code so that we don't force all contributors to update their config.
I don't think we can put the binary back, or at least, that feels iffy - we'd be trying to overlap two different sysroots. rustfmt used to be statically linked to libstd and librustc_driver, but that's no longer the case.
I suppose we could try to create a symlink from the old path to the new one? That might work, not sure.
Maybe add a proxy? On Linux it might just be
A symlink seems like a good solution to me.
Does the symlink still finds the correct so?
try it and see
I'll experiment adding a symlink.
On Windows, creating a symlink does not find the needed DLLs. Trying to execute the symlink pops two msgbox saying that it doesn't find the and DLLs. You would need to symlink also the DLLs. On Linux, it does find the correct SOs.
Symlinking also works on macOS.
Ok, this is pretty messy. How about doing both: Add the symlink, which will work with both the old and new config on Mac and Linux Update the recommended config in the dev-guide, which will help contributors fix the error message on Windows and from there we can work long-term to using the same toolchain for rustfmt and other tools, without having a time pressure.
cc ,
May I get some guidance and the creation of the symlink? Do I use rust to create the symlink in after the rustfmt_path line or do I use a bash command? If I do use a bash command, is there a file I should be adding it to? Thank you!
use
And just to confirm, I use that symlink function here?
Code change:
let bin_root = self.out.join(host.triple).join("rustfmt"); let rustfmt_path = bin_root.join("bin").join(exe("rustfmt", host)); let rustfmt_stamp = bin_root.join(".rustfmt-stamp"); <ins> let legacy_rustfmt = self.initial_rustc.with_file_name(exe("rustfmt", host)); if !legacy_rustfmt.exists() { t!(self.symlink_file(&rustfmt_path, &legacy_rustfmt)); } </ins> if rustfmt_path.exists() && !program_out_of_date(&rustfmt_stamp, &channel) { return Some(rustfmt_path); }

Related discussion:
text: yes
I think it would be possible to move rustfmt back to the same sysroot as the bootstrap compiler by only taking , and from the nightly rustc component and not copying any other files like the rustc binary. and both contain a hash in their name unique for each rustc version. should contain the rustc version, so that shouldn't conflict either.
Doing the same with the DLLs on Windows could also work.
related (different error with rustfmt, but caused by the same change):
Hi any progress on the symlink? happy to help out if you're running into trouble :)
Hey ! Thanks for reaching out! I'll be starting tomorrow and will reach out to you if/when I need help! Apologies for the delay!
Code change:
// except according to those terms. // aux-build:attr-on-trait.rs <ins> // ignore-stage1 </ins> #![feature(proc_macro)]

Related discussion:
text: This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.
Code change:
// except according to those terms. // aux-build:attr-on-trait.rs <ins> // ignore-stage1 </ins> #![feature(proc_macro)]

Related discussion:
text: Before , this caused an LLVM error Afterwards, this causes an ICE (the rustc size is the correct one):
I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.
Looks like called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.
Appears to be fixed today. E-needstest.
It seems that a better diagnostic output is needed:
Why? I believe it's implemented as a feature now (maybe it should be ?).
it's unrelated to this issue, but rather to 's solution, merits at least a clarifying label pointing at the , as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the . I know it definitely confused me_ :) Back to this issue, yes, the test in should be .
Code change:
// except according to those terms. // aux-build:attr-on-trait.rs <ins> // ignore-stage1 </ins> #![feature(proc_macro)]

Related discussion:
text: Triage: this no longer ICEs. <details<summaryMeta</summary: rustc 1.16.0 ( 2017-03-10) binary: rustc commit-hash: commit-date: 2017-03-10 host: x86_64-pc-windows-gnu release: 1.16.0 LLVM version: 3.9 </details
Code change:
let host_libs = builder .stage_out(compiler, Mode::ToolRustc) .join(builder.cargo_dir()); <ins> let target_libs = builder .stage_out(compiler, Mode::ToolRustc) .join(&self.host) .join(builder.cargo_dir()); </ins> cargo.env("HOST_LIBS", host_libs); <ins> cargo.env("TARGET_LIBS", target_libs); </ins> // clippy tests need to find the driver cargo.env("CLIPPY_DRIVER_PATH", clippy);

Related discussion:
text: 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.
triage: P-medium. Removing nomination label.
Code change:
pub fn get_linker(sess: &Session) -> (String, Command, Vec<(OsString, OsString)>) { let envs = vec![("PATH".into(), command_path(sess))]; <ins> // If our linker looks like a batch script on Windows then to execute this // we'll need to spawn `cmd` explicitly. This is primarily done to handle // emscripten where the linker is `emcc.bat` and needs to be spawned as // `cmd /c emcc.bat ...`. // // This worked historically but is needed manually since #42436 (regression // was tagged as #42791) and some more info can be found on #44443 for // emscripten itself. let cmd = |linker: &str| { if cfg!(windows) && linker.ends_with(".bat") { let mut cmd = Command::new("cmd"); cmd.arg("/c").arg(linker); cmd } else { Command::new(linker) } }; </ins> if let Some(ref linker) = sess.opts.cg.linker { <del> (linker.clone(), Command::new(linker), envs) </del> <ins> (linker.clone(), cmd(linker), envs) </ins> } else if sess.target.target.options.is_like_msvc { let (cmd, envs) = msvc_link_exe_cmd(sess); ("link.exe".to_string(), cmd, envs) } else { let linker = &sess.target.target.options.linker; <del> (linker.clone(), Command::new(&linker), envs) </del> <ins> (linker.clone(), cmd(linker), envs) </ins> } }

Related discussion:
text: Because of std's stability guarantees it looks like if we ever want a good we'll have to rely on third party crates.
Thanks for the background information. I feel bad to have wasted so much of your time on a discussion that was less than productive so feel free to disregard my ramblings. I think that this might be the best course of action.
do you have thoughts here? Or do you agree with the previous summaries?
I was quite surprised to learn that can execute batch scripts at all. .aspx) explicitly says "To run a batch file, you must start the command interpreter; set lpApplicationName to and set lpCommandLine to the following arguments: /c plus the name of the batch file." I agree with that trying to abstract away all platform differences is fraught with peril.
Ok thanks for the info In light of that the libs team's conclusion during the meeting of "we're not going to revert" I believe still stands, so I'm going to close this. If there's difficulty in updating applications though please let us know! We can try to help work around it if necessary.
In light of that the libs team's conclusion during the meeting of "we're not going to revert" I believe still stands, so I'm going to close this. I am fine with the decision, but could I ask for more explicit documentation about this behavior? The example on the shows the right thing to do, but it is never explicitly explained. Having a note about this in the docs would probably help avoid some confusion for people that are less familiar with Windows, like myself. :smile:
Agreed. Actually I would also expect that such change in behaviour would also be mentioned in the rust release notes. Even if the original behaviour was unintended side effect, this is an important change in behavioral contract for stdlib.