jiebi/CodeConvo huggingface dataset:
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: handle_native(name) } <ins> pub fn handle_native_features(sess: &Session) -> Vec<String> { match sess.opts.cg.target_cpu { Some(ref s) => { if s != "native" { return vec![]; } let features_string = unsafe { let ptr = llvm::LLVMGetHostCPUFeatures(); let features_string = if !ptr.is_null() { CStr::from_ptr(ptr) .to_str() .unwrap_or_else(|e| { bug!("LLVM returned a non-utf8 features string: {}", e); }) .to_owned() } else { bug!("could not allocate host CPU features, LLVM returned a `null` string"); }; llvm::LLVMDisposeMessage(ptr); features_string }; features_string.split(",").map(|s| s.to_owned()).collect() } None => vec![], } } </ins> pub fn tune_cpu(sess: &Session) -> Option<&str> { match sess.opts.debugging_opts.tune_cpu { Some(ref s) => Some(handle_native(&**s)),
Code change:
Rust version: How to reproduce: Error:
Minimized reproduction:
I'd like to work on this.

Related discussion:
text: ty::RegionKind::ReLateBound(_, _), ) => {} <del> (ty::RegionKind::ReLateBound(_, _), _) => { </del> <ins> (ty::RegionKind::ReLateBound(_, _), _) | (_, ty::RegionKind::ReVar(_)) => { // One of these is true: </ins> // The new predicate has a HRTB in a spot where the old // predicate does not (if they both had a HRTB, the previous <del> // match arm would have executed). </del> <ins> // match arm would have executed). A HRBT is a 'stricter' // bound than anything else, so we want to keep the newer // predicate (with the HRBT) in place of the old predicate. </ins> // <del> // The means we want to remove the older predicate from // user_computed_preds, since having both it and the new </del> <ins> // OR // // The old predicate has a region variable where the new // predicate has some other kind of region. An region // variable isn't something we can actually display to a user, // so we choose ther new predicate (which doesn't have a region // varaible). // // In both cases, we want to remove the old predicate, // from user_computed_preds, and replace it with the new // one. Having both the old and the new </ins> // predicate in a ParamEnv would confuse SelectionContext <ins> // </ins> // We're currently in the predicate passed to 'retain', // so we return 'false' to remove the old predicate from // user_computed_preds return false; } <del> (_, ty::RegionKind::ReLateBound(_, _)) => { // This is the opposite situation as the previous arm - the // old predicate has a HRTB lifetime in a place where the // new predicate does not. We want to leave the old </del> <ins> (_, ty::RegionKind::ReLateBound(_, _)) | (ty::RegionKind::ReVar(_), _) => { // This is the opposite situation as the previous arm. // One of these is true: // // The old predicate has a HRTB lifetime in a place where the // new predicate does not. // // OR // // The new predicate has a region variable where the old // predicate has some other type of region. // // We want to leave the old </ins> // predicate in user_computed_preds, and skip adding // new_pred to user_computed_params. should_add_new = false <del> } </del> <ins> }, </ins> _ => {} } }
Code change:
Rust version: How to reproduce: Error:
Minimized reproduction:
I'd like to work on this.

Related discussion:
text: <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. pub trait ScopeHandle<'scope> {} // @has issue_54705/struct.ScopeFutureContents.html // @has - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]//*/code' "impl<'scope, S>  // Send for ScopeFutureContents<'scope, S> where S: Sync" // // @has - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]//*/code' "impl<'scope, S>  // Sync for ScopeFutureContents<'scope, S> where S: Sync" pub struct ScopeFutureContents<'scope, S> where S: ScopeHandle<'scope>, { dummy: &'scope S, this: Box<ScopeFuture<'scope, S>>, } struct ScopeFuture<'scope, S> where S: ScopeHandle<'scope>, { contents: ScopeFutureContents<'scope, S>, } unsafe impl<'scope, S> Send for ScopeFuture<'scope, S> where S: ScopeHandle<'scope>, {} unsafe impl<'scope, S> Sync for ScopeFuture<'scope, S> where S: ScopeHandle<'scope>, {} </ins>
Code change:
That is, appears to lose incremental artifacts. cc
Yes, I believe this is because rustc/cargo will otherwise error on "found a new std" or something like that? I don't quite see how incremental is different from the normal compilation here?
incremental would still work even if dependencies changed. I think the fundamental problem here is that deletes everything, whereas (which, IIRC, does not remove incremental artifacts by default) would be appropriate.
Hm, I thought was equivalent to essentially -- could you clarify that? Would it be better to use cargo clean in rustbuild?
Regardless of what does I don't think we should execute it here. Rustbuild is overly conservative in what it deletes, and it can get away probably with just deleting the folder instead of the entire folder. That would leave around the incremental cache. I believe, however, that is like
Maybe the benchmarks I remember having for incremental had the incremental dir elsewhere than . I sure was confused by it, since I'd expect to remove all artifacts. If it does do that, then I agree should just remove a subset of the contents of target dirs.
Looking at the code, these calls appear to be relevant: The problem is that the directory refers to is non-trivially structured. Instead of removing , we need to remove all the files (or at least the ones that are artifacts) and the directory in .
I keep hitting this, specifically it keeps rebuilding and , every time I change rustc, which cause them to take much longer than any of the rustc crates, and this issue has become my main bottleneck (now that I'm building on a machine).
Nominating for discussion (specifically, allocating resources towards this) at the next relevant team meeting (tagged both and as I'm not sure which has "jurisdiction" here).
It'd be helpful to know how much rustbuild can "trust" the compiler here. Can we keep incremental artifact directories around from previous versions of the compiler?
The compiler can only work with incremental artifacts that it created itself. For any other version of the compiler it has to assume that it's incompatible. It usually just ignores such incompatible artifacts, but in the bootstrapping scenario, it might not always be smart enough to do that.
I think the question here is will rustc's incremental artifacts correctly deal with crates changing (including adding and removing crates) in the sysroot. If so, we could keep the folder around. Cargo assumes the sysroot is unchanging, which is why we remove the directory in the first place.
Incremental doesn't care about vs , so I'd expect it to be pretty resilient here.
triage: P-medium. (this inefficiency in incremental comp. would be nice to resolve, but is not P-high IMO.)

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:
That is, appears to lose incremental artifacts. cc
Yes, I believe this is because rustc/cargo will otherwise error on "found a new std" or something like that? I don't quite see how incremental is different from the normal compilation here?
incremental would still work even if dependencies changed. I think the fundamental problem here is that deletes everything, whereas (which, IIRC, does not remove incremental artifacts by default) would be appropriate.
Hm, I thought was equivalent to essentially -- could you clarify that? Would it be better to use cargo clean in rustbuild?
Regardless of what does I don't think we should execute it here. Rustbuild is overly conservative in what it deletes, and it can get away probably with just deleting the folder instead of the entire folder. That would leave around the incremental cache. I believe, however, that is like
Maybe the benchmarks I remember having for incremental had the incremental dir elsewhere than . I sure was confused by it, since I'd expect to remove all artifacts. If it does do that, then I agree should just remove a subset of the contents of target dirs.
Looking at the code, these calls appear to be relevant: The problem is that the directory refers to is non-trivially structured. Instead of removing , we need to remove all the files (or at least the ones that are artifacts) and the directory in .
I keep hitting this, specifically it keeps rebuilding and , every time I change rustc, which cause them to take much longer than any of the rustc crates, and this issue has become my main bottleneck (now that I'm building on a machine).
Nominating for discussion (specifically, allocating resources towards this) at the next relevant team meeting (tagged both and as I'm not sure which has "jurisdiction" here).
It'd be helpful to know how much rustbuild can "trust" the compiler here. Can we keep incremental artifact directories around from previous versions of the compiler?
The compiler can only work with incremental artifacts that it created itself. For any other version of the compiler it has to assume that it's incompatible. It usually just ignores such incompatible artifacts, but in the bootstrapping scenario, it might not always be smart enough to do that.
I think the question here is will rustc's incremental artifacts correctly deal with crates changing (including adding and removing crates) in the sysroot. If so, we could keep the folder around. Cargo assumes the sysroot is unchanging, which is why we remove the directory in the first place.
Incremental doesn't care about vs , so I'd expect it to be pretty resilient here.
triage: P-medium. (this inefficiency in incremental comp. would be nice to resolve, but is not P-high IMO.)

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:
That is, appears to lose incremental artifacts. cc
Yes, I believe this is because rustc/cargo will otherwise error on "found a new std" or something like that? I don't quite see how incremental is different from the normal compilation here?
incremental would still work even if dependencies changed. I think the fundamental problem here is that deletes everything, whereas (which, IIRC, does not remove incremental artifacts by default) would be appropriate.
Hm, I thought was equivalent to essentially -- could you clarify that? Would it be better to use cargo clean in rustbuild?
Regardless of what does I don't think we should execute it here. Rustbuild is overly conservative in what it deletes, and it can get away probably with just deleting the folder instead of the entire folder. That would leave around the incremental cache. I believe, however, that is like
Maybe the benchmarks I remember having for incremental had the incremental dir elsewhere than . I sure was confused by it, since I'd expect to remove all artifacts. If it does do that, then I agree should just remove a subset of the contents of target dirs.
Looking at the code, these calls appear to be relevant: The problem is that the directory refers to is non-trivially structured. Instead of removing , we need to remove all the files (or at least the ones that are artifacts) and the directory in .
I keep hitting this, specifically it keeps rebuilding and , every time I change rustc, which cause them to take much longer than any of the rustc crates, and this issue has become my main bottleneck (now that I'm building on a machine).
Nominating for discussion (specifically, allocating resources towards this) at the next relevant team meeting (tagged both and as I'm not sure which has "jurisdiction" here).
It'd be helpful to know how much rustbuild can "trust" the compiler here. Can we keep incremental artifact directories around from previous versions of the compiler?
The compiler can only work with incremental artifacts that it created itself. For any other version of the compiler it has to assume that it's incompatible. It usually just ignores such incompatible artifacts, but in the bootstrapping scenario, it might not always be smart enough to do that.
I think the question here is will rustc's incremental artifacts correctly deal with crates changing (including adding and removing crates) in the sysroot. If so, we could keep the folder around. Cargo assumes the sysroot is unchanging, which is why we remove the directory in the first place.
Incremental doesn't care about vs , so I'd expect it to be pretty resilient here.
triage: P-medium. (this inefficiency in incremental comp. would be nice to resolve, but is not P-high IMO.)

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:
That is, appears to lose incremental artifacts. cc
Yes, I believe this is because rustc/cargo will otherwise error on "found a new std" or something like that? I don't quite see how incremental is different from the normal compilation here?
incremental would still work even if dependencies changed. I think the fundamental problem here is that deletes everything, whereas (which, IIRC, does not remove incremental artifacts by default) would be appropriate.
Hm, I thought was equivalent to essentially -- could you clarify that? Would it be better to use cargo clean in rustbuild?
Regardless of what does I don't think we should execute it here. Rustbuild is overly conservative in what it deletes, and it can get away probably with just deleting the folder instead of the entire folder. That would leave around the incremental cache. I believe, however, that is like
Maybe the benchmarks I remember having for incremental had the incremental dir elsewhere than . I sure was confused by it, since I'd expect to remove all artifacts. If it does do that, then I agree should just remove a subset of the contents of target dirs.
Looking at the code, these calls appear to be relevant: The problem is that the directory refers to is non-trivially structured. Instead of removing , we need to remove all the files (or at least the ones that are artifacts) and the directory in .
I keep hitting this, specifically it keeps rebuilding and , every time I change rustc, which cause them to take much longer than any of the rustc crates, and this issue has become my main bottleneck (now that I'm building on a machine).
Nominating for discussion (specifically, allocating resources towards this) at the next relevant team meeting (tagged both and as I'm not sure which has "jurisdiction" here).
It'd be helpful to know how much rustbuild can "trust" the compiler here. Can we keep incremental artifact directories around from previous versions of the compiler?
The compiler can only work with incremental artifacts that it created itself. For any other version of the compiler it has to assume that it's incompatible. It usually just ignores such incompatible artifacts, but in the bootstrapping scenario, it might not always be smart enough to do that.
I think the question here is will rustc's incremental artifacts correctly deal with crates changing (including adding and removing crates) in the sysroot. If so, we could keep the folder around. Cargo assumes the sysroot is unchanging, which is why we remove the directory in the first place.
Incremental doesn't care about vs , so I'd expect it to be pretty resilient here.
triage: P-medium. (this inefficiency in incremental comp. would be nice to resolve, but is not P-high IMO.)

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:
That is, appears to lose incremental artifacts. cc
Yes, I believe this is because rustc/cargo will otherwise error on "found a new std" or something like that? I don't quite see how incremental is different from the normal compilation here?
incremental would still work even if dependencies changed. I think the fundamental problem here is that deletes everything, whereas (which, IIRC, does not remove incremental artifacts by default) would be appropriate.
Hm, I thought was equivalent to essentially -- could you clarify that? Would it be better to use cargo clean in rustbuild?
Regardless of what does I don't think we should execute it here. Rustbuild is overly conservative in what it deletes, and it can get away probably with just deleting the folder instead of the entire folder. That would leave around the incremental cache. I believe, however, that is like
Maybe the benchmarks I remember having for incremental had the incremental dir elsewhere than . I sure was confused by it, since I'd expect to remove all artifacts. If it does do that, then I agree should just remove a subset of the contents of target dirs.
Looking at the code, these calls appear to be relevant: The problem is that the directory refers to is non-trivially structured. Instead of removing , we need to remove all the files (or at least the ones that are artifacts) and the directory in .
I keep hitting this, specifically it keeps rebuilding and , every time I change rustc, which cause them to take much longer than any of the rustc crates, and this issue has become my main bottleneck (now that I'm building on a machine).
Nominating for discussion (specifically, allocating resources towards this) at the next relevant team meeting (tagged both and as I'm not sure which has "jurisdiction" here).
It'd be helpful to know how much rustbuild can "trust" the compiler here. Can we keep incremental artifact directories around from previous versions of the compiler?
The compiler can only work with incremental artifacts that it created itself. For any other version of the compiler it has to assume that it's incompatible. It usually just ignores such incompatible artifacts, but in the bootstrapping scenario, it might not always be smart enough to do that.
I think the question here is will rustc's incremental artifacts correctly deal with crates changing (including adding and removing crates) in the sysroot. If so, we could keep the folder around. Cargo assumes the sysroot is unchanging, which is why we remove the directory in the first place.
Incremental doesn't care about vs , so I'd expect it to be pretty resilient here.
triage: P-medium. (this inefficiency in incremental comp. would be nice to resolve, but is not P-high IMO.)

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:
On rustc 1.31.0-nightly ( 2018-10-07) and x8664-unknown-linux-gnu, we see the following surprising behavior: In release mode it seems the write has not happened in the place that it should. Mentioning threadlocal tracking issue: .
Ah, apparently this is missing a . With the behavior is correct. We need to make sure mutating a thread_local static that does not have does not compile.
cc Did fix this by any chance?
It looks like this is fixed on nightly; I'm guessing is the reason. We probably should add some regression tests for the cases listed here.

Related discussion:
text: <ins> error[E0594]: cannot assign to immutable static item `S` --> $DIR/thread-local-mutation.rs:11:5 | LL |     S = "after"; //~ ERROR cannot assign to immutable |     ^^^^^^^^^^^ cannot assign error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>
Code change:
On rustc 1.31.0-nightly ( 2018-10-07) and x8664-unknown-linux-gnu, we see the following surprising behavior: In release mode it seems the write has not happened in the place that it should. Mentioning threadlocal tracking issue: .
Ah, apparently this is missing a . With the behavior is correct. We need to make sure mutating a thread_local static that does not have does not compile.
cc Did fix this by any chance?
It looks like this is fixed on nightly; I'm guessing is the reason. We probably should add some regression tests for the cases listed here.

Related discussion:
text: <ins> // Regression test for #54901: immutable thread locals could be mutated. See: // https://github.com/rust-lang/rust/issues/29594#issuecomment-328177697 // https://github.com/rust-lang/rust/issues/54901 #![feature(thread_local)] #[thread_local] static S: &str = "before"; fn set_s() { S = "after"; //~ ERROR cannot assign to immutable } fn main() { println!("{}", S); set_s(); println!("{}", S); } </ins>
Code change:
On rustc 1.31.0-nightly ( 2018-10-07) and x8664-unknown-linux-gnu, we see the following surprising behavior: In release mode it seems the write has not happened in the place that it should. Mentioning threadlocal tracking issue: .
Ah, apparently this is missing a . With the behavior is correct. We need to make sure mutating a thread_local static that does not have does not compile.
cc Did fix this by any chance?
It looks like this is fixed on nightly; I'm guessing is the reason. We probably should add some regression tests for the cases listed here.

Related discussion:
text: <ins> error[E0594]: cannot assign to immutable thread-local static item --> $DIR/thread-local-mutation.rs:11:5 | LL |     S = "after"; //~ ERROR cannot assign to immutable |     ^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>
Code change:
The following code gives "warning: enum is never used: ": This regressed pretty recently. cc
27.0 does not warn, 1.28.0 does.
triage: P-medium; This seems like a papercut that should be easy to work-around (at least if one isn't using ...).
switched to P-high after prompting from
whoops forgot to tag with T-compiler in time for the meeting...
assigning to
I'm grabbing this, I think I broke it and it should be easy to fix

Related discussion:
text: hir::ItemKind::Fn(..) | hir::ItemKind::Ty(..) | hir::ItemKind::Static(..) <ins> | hir::ItemKind::Existential(..) </ins> | hir::ItemKind::Const(..) => { intravisit::walk_item(self, &item); }