jiebi/CodeConvo huggingface dataset:
Code change:
here is the example: this example will compile well if you remove
Backtrace: `
Hmm I reproduced same ICE with next snippet without :
Smaller repro: Edit: AFAICT the problem is the existential assoc type is being made dependent on the type parameter of the trait method ('s in this repro, 's in the OP). So it would be a compile error if it weren't for the ICE.
compiles without ICE.
sorry it needs to be feature or used 2018 edition. Here is complete one which fails to compile regardless feature:
Right, 2015 doesn't hit the error until you actually try to use the type. Regardless, as I said in my previous comment, this code should be a compile error anyway regardless of edition, since it's trying to declare an associated type that depends on the type parameters of the trait method rather than the trait.
hey have you had a chance to look into this yet? Do you think you will be looking at it in the near term, or should we unassign you?
Removed my assignment. Unfortunately I'm running behind on the not-time-critical issues I assigned to myself.
Discussed in T-compiler meeting. This is a blocker for the existential type feature. But there is no schedule yet set for stabilizing that feature. Thus, downgrading fixing this to P-medium.
This no longer produces an ICE on the latest nightly.
Yes, it was fixed by

Related discussion:
text: <ins> error: type parameter `impl Deref<Target = Self>` is part of concrete type but not used in parameter list for the `impl Trait` type alias --> $DIR/issue-57700.rs:16:58 | LL |       fn foo(self: impl Deref<Target = Self>) -> Self::Bar { |  __________________________________________________________^ LL | | LL | |         self LL | |     } | |_____^ error: aborting due to previous error </ins>
Code change:
This takes a while to compile. I presume because needs to hit the loop checker in miri. Changing the foofoo&(loop{}, 1).1'staticlifetime. () Errors:
The following code times out with either borrow checker:
The reason that foo matters is because of
I don't think this is an NLL issue in particular?
Based on 's identification of a test that reproduces the issue on either borrow-checker, I am going to remove the A-NLL label.
That example is not problematic, because nothing is promoted at all. I now don't even think my example is problematic anymore, because it seems to be perfectly alright to promote anything if we diverge before we give the user access to the value. I guess this just needs a test now (just a ui test with a comment, not a run-pass test, as that would hang forever)
Can I work on this? I'm a newbie to rust.
Sure! You can take the example from the issue message and create a new file in and add the comment at the top. Then, when running it should succeed to run the tests.

Related discussion:
text: <ins> //compile-pass #![feature(nll)] fn main() { let _: &'static usize = &(loop {}, 1).1; } </ins>
Code change:
This also occurs with etc. Changing requires only the reverse dependencies of to be recompiled. is also recompiled. As you can see, this takes twice as much as compiling the reverse dependencies of alone, leading to compilation being 3x slower.

Related discussion:
text: let mut cargo = Command::new(&self.initial_cargo); let out_dir = self.stage_out(compiler, mode); <del> // command specific path, we call clear_if_dirty with this let mut my_out = match cmd { "build" => self.cargo_out(compiler, mode, target), // This is the intended out directory for crate documentation. "doc" | "rustdoc" =>  self.crate_doc_out(target), _ => self.stage_out(compiler, mode), }; // This is for the original compiler, but if we're forced to use stage 1, then // std/test/rustc stamps won't exist in stage 2, so we need to get those from stage 1, since // we copy the libs forward. let cmp = self.compiler_for(compiler.stage, compiler.host, target); let libstd_stamp = match cmd { "check" | "clippy" | "fix" => check::libstd_stamp(self, cmp, target), _ => compile::libstd_stamp(self, cmp, target), }; let libtest_stamp = match cmd { "check" | "clippy" | "fix" => check::libtest_stamp(self, cmp, target), _ => compile::libtest_stamp(self, cmp, target), }; let librustc_stamp = match cmd { "check" | "clippy" | "fix" => check::librustc_stamp(self, cmp, target), _ => compile::librustc_stamp(self, cmp, target), }; </del> <ins> // Codegen backends are not yet tracked by -Zbinary-dep-depinfo, // so we need to explicitly clear out if they've been updated. for backend in self.codegen_backends(compiler) { self.clear_if_dirty(&out_dir, &backend); } </ins> if cmd == "doc" || cmd == "rustdoc" { <del> if mode == Mode::Rustc || mode == Mode::ToolRustc || mode == Mode::Codegen { </del> <ins> let my_out = match mode { </ins> // This is the intended out directory for compiler documentation. <del> my_out = self.compiler_doc_out(target); } </del> <ins> Mode::Rustc | Mode::ToolRustc | Mode::Codegen => self.compiler_doc_out(target), _ => self.crate_doc_out(target), }; </ins> let rustdoc = self.rustdoc(compiler); self.clear_if_dirty(&my_out, &rustdoc); <del> } else if cmd != "test" { match mode { Mode::Std => { self.clear_if_dirty(&my_out, &self.rustc(compiler)); for backend in self.codegen_backends(compiler) { self.clear_if_dirty(&my_out, &backend); } }, Mode::Test => { self.clear_if_dirty(&my_out, &libstd_stamp); }, Mode::Rustc => { self.clear_if_dirty(&my_out, &self.rustc(compiler)); self.clear_if_dirty(&my_out, &libstd_stamp); self.clear_if_dirty(&my_out, &libtest_stamp); }, Mode::Codegen => { self.clear_if_dirty(&my_out, &librustc_stamp); }, Mode::ToolBootstrap => { }, Mode::ToolStd => { self.clear_if_dirty(&my_out, &libstd_stamp); }, Mode::ToolTest => { self.clear_if_dirty(&my_out, &libstd_stamp); self.clear_if_dirty(&my_out, &libtest_stamp); }, Mode::ToolRustc => { self.clear_if_dirty(&my_out, &libstd_stamp); self.clear_if_dirty(&my_out, &libtest_stamp); self.clear_if_dirty(&my_out, &librustc_stamp); }, } </del> } cargo
Code change:
This also occurs with etc. Changing requires only the reverse dependencies of to be recompiled. is also recompiled. As you can see, this takes twice as much as compiling the reverse dependencies of alone, leading to compilation being 3x slower.

Related discussion:
text: }, } <ins> // This tells Cargo (and in turn, rustc) to output more complete // dependency information.  Most importantly for rustbuild, this // includes sysroot artifacts, like libstd, which means that we don't // need to track those in rustbuild (an error prone process!). This // feature is currently unstable as there may be some bugs and such, but // it represents a big improvement in rustbuild's reliability on // rebuilds, so we're using it here. // // For some additional context, see #63470 (the PR originally adding // this), as well as #63012 which is the tracking issue for this // feature on the rustc side. cargo.arg("-Zbinary-dep-depinfo"); </ins> cargo.arg("-j").arg(self.jobs().to_string()); // Remove make-related flags to ensure Cargo can correctly set things up cargo.env_remove("MAKEFLAGS");
Code change:
This also occurs with etc. Changing requires only the reverse dependencies of to be recompiled. is also recompiled. As you can see, this takes twice as much as compiling the reverse dependencies of alone, leading to compilation being 3x slower.

Related discussion:
text: let libdir = builder.sysroot_libdir(compiler, target); let hostdir = builder.sysroot_libdir(compiler, compiler.host); add_to_sysroot(&builder, &libdir, &hostdir, &rustdoc_stamp(builder, compiler, target)); <del> builder.cargo(compiler, Mode::ToolRustc, target, "clean"); </del> } }
Code change:
This also occurs with etc. Changing requires only the reverse dependencies of to be recompiled. is also recompiled. As you can see, this takes twice as much as compiling the reverse dependencies of alone, leading to compilation being 3x slower.

Related discussion:
text: use std::process::{Command, Stdio, exit}; use std::str; <del> use build_helper::{output, mtime, t, up_to_date}; </del> <ins> use build_helper::{output, t, up_to_date}; </ins> use filetime::FileTime; use serde::Deserialize; use serde_json;
Code change:
This also occurs with etc. Changing requires only the reverse dependencies of to be recompiled. is also recompiled. As you can see, this takes twice as much as compiling the reverse dependencies of alone, leading to compilation being 3x slower.

Related discussion:
text: // for reason why the sanitizers are not built in stage0. copy_apple_sanitizer_dylibs(builder, &builder.native_dir(target), "osx", &libdir); } <del> builder.cargo(target_compiler, Mode::ToolStd, target, "clean"); </del> } }
Code change:
This also occurs with etc. Changing requires only the reverse dependencies of to be recompiled. is also recompiled. As you can see, this takes twice as much as compiling the reverse dependencies of alone, leading to compilation being 3x slower.

Related discussion:
text: &builder.sysroot_libdir(target_compiler, compiler.host), &libtest_stamp(builder, compiler, target) ); <del> builder.cargo(target_compiler, Mode::ToolTest, target, "clean"); </del> } }
Code change:
This also occurs with etc. Changing requires only the reverse dependencies of to be recompiled. is also recompiled. As you can see, this takes twice as much as compiling the reverse dependencies of alone, leading to compilation being 3x slower.

Related discussion:
text: &builder.sysroot_libdir(target_compiler, compiler.host), &librustc_stamp(builder, compiler, target) ); <del> builder.cargo(target_compiler, Mode::ToolRustc, target, "clean"); </del> } }
Code change:
This also occurs with etc. Changing requires only the reverse dependencies of to be recompiled. is also recompiled. As you can see, this takes twice as much as compiling the reverse dependencies of alone, leading to compilation being 3x slower.

Related discussion:
text: deps.push((path_to_add.into(), false)); } <del> // Now we want to update the contents of the stamp file, if necessary. First // we read off the previous contents along with its mtime. If our new // contents (the list of files to copy) is different or if any dep's mtime // is newer then we rewrite the stamp file. </del> deps.sort(); <del> let stamp_contents = fs::read(stamp); let stamp_mtime = mtime(&stamp); </del> let mut new_contents = Vec::new(); <del> let mut max = None; let mut max_path = None; </del> for (dep, proc_macro) in deps.iter() { <del> let mtime = mtime(dep); if Some(mtime) > max { max = Some(mtime); max_path = Some(dep.clone()); } </del> new_contents.extend(if *proc_macro { b"h" } else { b"t" }); new_contents.extend(dep.to_str().unwrap().as_bytes()); new_contents.extend(b"0"); } <del> let max = max.unwrap(); let max_path = max_path.unwrap(); let contents_equal = stamp_contents .map(|contents| contents == new_contents) .unwrap_or_default(); if contents_equal && max <= stamp_mtime { builder.verbose(&format!("not updating {:?}; contents equal and {:?} <= {:?}", stamp, max, stamp_mtime)); return deps.into_iter().map(|(d, _)| d).collect() } if max > stamp_mtime { builder.verbose(&format!("updating {:?} as {:?} changed", stamp, max_path)); } else { builder.verbose(&format!("updating {:?} as deps changed", stamp)); } </del> t!(fs::write(&stamp, &new_contents)); deps.into_iter().map(|(d, _)| d).collect() }
Code change:
Discovered in it turns out that our vendored copies of these libraires cause problems when they override the system versions by accident. We should rename our copies with a Rust-specific name to avoid this name clash.

Related discussion:
text: fn copy_apple_sanitizer_dylibs(builder: &Builder, native_dir: &Path, platform: &str, into: &Path) { for &sanitizer in &["asan", "tsan"] { <del> let filename = format!("libclang_rt.{}_{}_dynamic.dylib", sanitizer, platform); </del> <ins> let filename = format!("lib__rustc__clang_rt.{}_{}_dynamic.dylib", sanitizer, platform); </ins> let mut src_path = native_dir.join(sanitizer); src_path.push("build"); src_path.push("lib");
Code change:
Discovered in it turns out that our vendored copies of these libraires cause problems when they override the system versions by accident. We should rename our copies with a Rust-specific name to avoid this name clash.

Related discussion:
text: pub out_dir: PathBuf, } <ins> impl NativeLibBoilerplate { /// On OSX we don't want to ship the exact filename that compiler-rt builds. /// This conflicts with the system and ours is likely a wildly different /// version, so they can't be substituted. /// /// As a result, we rename it here but we need to also use /// `install_name_tool` on OSX to rename the commands listed inside of it to /// ensure it's linked against correctly. pub fn fixup_sanitizer_lib_name(&self, sanitizer_name: &str) { if env::var("TARGET").unwrap() != "x86_64-apple-darwin" { return } let dir = self.out_dir.join("build/lib/darwin"); let name = format!("clang_rt.{}_osx_dynamic", sanitizer_name); let src = dir.join(&format!("lib{}.dylib", name)); let new_name = format!("lib__rustc__{}.dylib", name); let dst = dir.join(&new_name); println!("{} => {}", src.display(), dst.display()); fs::rename(&src, &dst).unwrap(); let status = Command::new("install_name_tool") .arg("-id") .arg(format!("@rpath/{}", new_name)) .arg(&dst) .status() .expect("failed to execute `install_name_tool`"); assert!(status.success()); } } </ins> impl Drop for NativeLibBoilerplate { fn drop(&mut self) { if !thread::panicking() {
Code change:
Discovered in it turns out that our vendored copies of these libraires cause problems when they override the system versions by accident. We should rename our copies with a Rust-specific name to avoid this name clash.

Related discussion:
text: pub fn sanitizer_lib_boilerplate(sanitizer_name: &str) -> Result<(NativeLibBoilerplate, String), ()> { <del> let (link_name, search_path, dynamic) = match &*env::var("TARGET").unwrap() { </del> <ins> let (link_name, search_path, apple) = match &*env::var("TARGET").unwrap() { </ins> "x86_64-unknown-linux-gnu" => ( format!("clang_rt.{}-x86_64", sanitizer_name), "build/lib/linux",
Code change:
Discovered in it turns out that our vendored copies of these libraires cause problems when they override the system versions by accident. We should rename our copies with a Rust-specific name to avoid this name clash.

Related discussion:
text: ), _ => return Err(()), }; <del> let to_link = if dynamic { format!("dylib={}", link_name) </del> <ins> let to_link = if apple { format!("dylib=__rustc__{}", link_name) </ins> } else { format!("static={}", link_name) };
Code change:
Discovered in it turns out that our vendored copies of these libraires cause problems when they override the system versions by accident. We should rename our copies with a Rust-specific name to avoid this name clash.

Related discussion:
text: .out_dir(&native.out_dir) .build_target(&target) .build(); <ins> native.fixup_sanitizer_lib_name("asan"); </ins> } println!("cargo:rerun-if-env-changed=LLVM_CONFIG"); }
Code change:
Discovered in it turns out that our vendored copies of these libraires cause problems when they override the system versions by accident. We should rename our copies with a Rust-specific name to avoid this name clash.

Related discussion:
text: .out_dir(&native.out_dir) .build_target(&target) .build(); <ins> native.fixup_sanitizer_lib_name("tsan"); </ins> } println!("cargo:rerun-if-env-changed=LLVM_CONFIG"); }
Code change:
std::io::Seek I got confused by this line and over on so after a little discussion it seems like this might be better wording for those of us who are silly A seek beyond the end of a stream is allowed, but it is implementation-defined. The hyphen makes it clear “implementation defined” is a known concept (and matches it’s usage elsewhere) and the “it is” makes it a bit more clear that the full sentence is considered and intentional. While normally I find brevity improves clarity, in this case if you don’t realize “implementation defined” is a single concept, it sounds like a thought that trailed off after an edit
Thanks I know other projects I've worked with have Easy and Documentation as tags so I wasn't sure if you guys might do the same
Yep, they're just actual labels over on the right ;-) (I also tabbed away and forgot to put the easy label on immediately )
Don't worry about that! It's very easy for developers to misjudge whether such descriptions will make sense to the target users. Pointing these things out is a great way to contribute to documentation.

Related discussion:
text: pub trait Seek { /// Seek to an offset, in bytes, in a stream. /// <del> /// A seek beyond the end of a stream is allowed, but implementation /// defined. </del> <ins> /// A seek beyond the end of a stream is allowed, but behavior is defined /// by the implementation. </ins> /// /// If the seek operation completed successfully, /// this method returns the new position from the start of the stream.
Code change:
Compiling code like: results in: presumably because attempts to translate it into an x86-specific ABI, which the AArch64 backend rightly rejects. already ignores for non-x86 targets: I'm not completely sure what the right answer for Rust is. I think is the rough equivalent of the above clang bit and needs to take a few more cases into account for non-x86 Windows: does that sound right? If so, I'll code up a patch.
Sounds like a good place to me!

Related discussion:
text: } impl Target { <del> /// Given a function ABI, turn "System" into the correct ABI for this target. </del> <ins> /// Given a function ABI, turn it into the correct ABI for this target. </ins> pub fn adjust_abi(&self, abi: Abi) -> Abi { match abi { Abi::System => {
Code change:
Compiling code like: results in: presumably because attempts to translate it into an x86-specific ABI, which the AArch64 backend rightly rejects. already ignores for non-x86 targets: I'm not completely sure what the right answer for Rust is. I think is the rough equivalent of the above clang bit and needs to take a few more cases into account for non-x86 Windows: does that sound right? If so, I'll code up a patch.
Sounds like a good place to me!

Related discussion:
text: Abi::C } }, <ins> // These ABI kinds are ignored on non-x86 Windows targets. // See https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-and-naming-conventions // and the individual pages for __stdcall et al. Abi::Stdcall | Abi::Fastcall | Abi::Vectorcall | Abi::Thiscall => { if self.options.is_like_windows && self.arch != "x86" { Abi::C } else { abi } }, </ins> abi => abi } }
Code change:
Compiling code like: results in: presumably because attempts to translate it into an x86-specific ABI, which the AArch64 backend rightly rejects. already ignores for non-x86 targets: I'm not completely sure what the right answer for Rust is. I think is the rough equivalent of the above clang bit and needs to take a few more cases into account for non-x86 Windows: does that sound right? If so, I'll code up a patch.
Sounds like a good place to me!

Related discussion:
text: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-arm // ignore-aarch64 </del> <ins> // Test that `extern "stdcall"` is properly translated. // only-x86 </ins> // compile-flags: -C no-prepopulate-passes
Code change:
Because LLVM doesn't know what is, we currently , relying on the  function. So if the current CPU's family is Haswell, we convert to . As noticed and , some Intel Pentiums belong to the Haswell microarch, but they lack AVX. <hr/Here are the flags Clang generates for : Not only does it set the right for optimization purposes, it actually manually enables / disables all the features available / not available on the host. This ensures no matter what the microarch is, only available features will be used. <hr/We should probably use the . I think this issue will supersede both rust-lang/rust and rust-lang/rust. If we can fix this, we will never generate code with unavailable target features. Reproducing these errors is pretty hard, unless you have a machine with a Haswell Intel Pentium. I think it might be possible to reproduce this in QEMU with
Alternatively, we could also use the macros to do this. I'll work on this.
To add another example, doesn't detect the feature on broadwell (see ).
I submitted a PR for a

Related discussion:
text: let code_model = to_llvm_code_model(sess.code_model()); <del> let features = attributes::llvm_target_features(sess).collect::<Vec<_>>(); </del> <ins> let mut features = llvm_util::handle_native_features(sess); features.extend(attributes::llvm_target_features(sess).map(|s| s.to_owned())); </ins> let mut singlethread = sess.target.singlethread; // On the wasm target once the `atomics` feature is enabled that means that
Code change:
Because LLVM doesn't know what is, we currently , relying on the  function. So if the current CPU's family is Haswell, we convert to . As noticed and , some Intel Pentiums belong to the Haswell microarch, but they lack AVX. <hr/Here are the flags Clang generates for : Not only does it set the right for optimization purposes, it actually manually enables / disables all the features available / not available on the host. This ensures no matter what the microarch is, only available features will be used. <hr/We should probably use the . I think this issue will supersede both rust-lang/rust and rust-lang/rust. If we can fix this, we will never generate code with unavailable target features. Reproducing these errors is pretty hard, unless you have a machine with a Haswell Intel Pentium. I think it might be possible to reproduce this in QEMU with
Alternatively, we could also use the macros to do this. I'll work on this.
To add another example, doesn't detect the feature on broadwell (see ).
I submitted a PR for a

Related discussion:
text: PM: &PassManager<'_>, ); <ins> pub fn LLVMGetHostCPUFeatures() -> *mut c_char; pub fn LLVMDisposeMessage(message: *mut c_char); </ins> // Stuff that's in llvm-wrapper/ because it's not upstream yet. /// Opens an object file.
Code change:
Because LLVM doesn't know what is, we currently , relying on the  function. So if the current CPU's family is Haswell, we convert to . As noticed and , some Intel Pentiums belong to the Haswell microarch, but they lack AVX. <hr/Here are the flags Clang generates for : Not only does it set the right for optimization purposes, it actually manually enables / disables all the features available / not available on the host. This ensures no matter what the microarch is, only available features will be used. <hr/We should probably use the . I think this issue will supersede both rust-lang/rust and rust-lang/rust. If we can fix this, we will never generate code with unavailable target features. Reproducing these errors is pretty hard, unless you have a machine with a Haswell Intel Pentium. I think it might be possible to reproduce this in QEMU with
Alternatively, we could also use the macros to do this. I'll work on this.
To add another example, doesn't detect the feature on broadwell (see ).
I submitted a PR for a

Related discussion:
text: use rustc_session::Session; use rustc_span::symbol::Symbol; use rustc_target::spec::{MergeFunctions, PanicStrategy}; <del> use std::ffi::CString; </del> <ins> use std::ffi::{CStr, CString}; </ins> use std::slice; use std::str;