jiebi/CodeConvo huggingface dataset:
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: To be able to use lldb commands as I can if I use lldb directly Instead, this happened: error: file specified in --source (-s) option doesn't exist: 'lldbcommands' <!-- 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. --: The same happens on a macOS machine I saw that is on directory together with shell script, and I also saw that script calls it directly, but I'm not sure how it should behaves in my machine since the is not there (rustup is not installing it) I've asked it on Rust users forum, and also in the discord chat, but no answers, so I'm considering it a bug, feel free to close it if it is something wrong with my installation and, if possible, guide me on where should I look to fix it.
cc who introduced in . I also notice the script references which isn't set anywhere.
The issue happens because expects and its dependencies resides on the current directory. Just to let you know that I got it working doing this: Cloned this repo on : Edit changing the first line to: Then run the following to link the files to the current directory:
Another important highlight, as mentioned, this is a recent change, so 1.45 was working fine and the issue appeared only on 1.46

Discussion:
cp_debugger_script("lldb_lookup.py"); cp_debugger_script("lldb_providers.py"); <ins> cp_debugger_script("lldb_commands") </ins> } } }

<del> command script import "$RUSTC_SYSROOT/lib/rustlib/etc/lldb_lookup.py" </del> type synthetic add -l lldb_lookup.synthetic_lookup -x ".*" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(alloc::([a-z_]+::)+)String$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&str$" --category Rust

fi fi <ins> script_import="command script import "$RUSTC_SYSROOT/lib/rustlib/etc/lldb_lookup.py"" commands_file="$RUSTC_SYSROOT/lib/rustlib/etc/lldb_commands" </ins> # Call LLDB with the commands added to the argument list <del> exec "$lldb" --source-before-file ./lldb_commands "$@" </del> <ins> exec "$lldb" --one-line-before-file "$script_import" --source-before-file "$commands_file" "$@" </ins>
Change:
Hello, I am getting an ICE while "playing" with  MCVE can be found here: <details<summaryOriginal</summary</details<!-- 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. --: (from Playground) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
A project maintainer might want to add the label.
Reduced, no nightly features: Output on stable: ICEs on beta and nightly.
Adding a bound as suggested gives this ICE on stable: <details<summaryBacktrace</summary</detailsWhich looks like . It still gives the original ICE on beta and stable, and it looks like 's code now produces the original ICE of this issue on beta and stable. Does that make this a duplicate?
:
modify labels: -F-unboxed_closures -requires-nightly per
This is now reproducing on stable. This feels like more of a "guts of the borrow checker" kind of issue than async/await-specific, so I'm tagging with .
Assigning as and removing .
Another repro from :

Discussion:
use rustc_infer::infer::{self, InferCtxt, SubregionOrigin}; use rustc_middle::mir::ConstraintCategory; use rustc_middle::ty::subst::GenericArgKind; <ins> use rustc_middle::ty::TypeFoldable; </ins> use rustc_middle::ty::{self, TyCtxt}; use rustc_span::DUMMY_SP;

self.add_outlives(r1_vid, r2_vid); } <del> GenericArgKind::Type(t1) => { </del> <ins> GenericArgKind::Type(mut t1) => { </ins> // we don't actually use this for anything, but // the `TypeOutlives` code needs an origin. let origin = infer::RelateParamBound(DUMMY_SP, t1, None); <ins> // Placeholder regions need to be converted now because it may // create new region variables, which can't be done later when // verifying these bounds. if t1.has_placeholders() { t1 = tcx.fold_regions(&t1, &mut false, |r, _| match *r { ty::RegionKind::RePlaceholder(placeholder) => { self.constraints.placeholder_region(self.infcx, placeholder) } _ => r, }); } </ins> TypeOutlives::new( &mut *self, tcx,

<ins> // edition:2018 // check-pass #![feature(unboxed_closures)] use std::future::Future; async fn wrapper<F>(f: F) where for<'a> F: FnOnce<(&'a mut i32,)>, for<'a> <F as FnOnce<(&'a mut i32,)>>::Output: Future<Output=()> + 'a { let mut i = 41; f(&mut i).await; } async fn add_one(i: &mut i32) { *i = *i + 1; } fn main() {} </ins>
Change:
I wanted to try out the missingdoccodeexamples rustdoc lint, but it seems to be bugged. I tried following the example given in . Steps to reproduce: Create a new crate: Then edit the file: I would now expect to get a linting error when building the crate, since the add function is public, but does not have a code example. However, as well as and completes without any errors.
The lint only works on nightly, the docs should probably be updated.
These docs live in To fix this, add 'and is nightly-only' to the first sentence.
I created PR to update the documentation. Thanks for clarifying. :-)

Discussion:
## missing_doc_code_examples <del> This lint is **allowed by default**. It detects when a documentation block </del> <ins> This lint is **allowed by default** and is **nightly-only**. It detects when a documentation block </ins> is missing a code example. For example: ```rust
Change:
Is incorrectly rejected: fwiw, if I put parens around the call, it's accepted. But the pretty-printer takes out the parens, since they're obviously unnecessary ;)

Discussion:
NOT. { true } BINOP(MINUS.) { true } BINOP(STAR.) { true } <ins> MOD_SEP. { true } </ins> _ { false } } }

<ins> // Regression test for issue #762 // xfail-stage0 fn f() { } fn main() { ret ::f(); } </ins>  No newline at end of file
Change:
When bootstrapping rustc, I can observe a crash inside llvm when building . In I could see this: I did a bisect and found out that the crash happens since cc my cpu is a The timing of the crash makes me think that this might happen somewhere during LTOing of the rustcmiddle crate, rustc did not show a backtrace for the crash though, since it happens inside llvm. I already did purge my rustc build cache and the sccache before I saw the segfault happens inside llvm (it didn't help anyway). :sweat_smile: rustc @
cc
Was a coredump generated? If so, should be able to generate a backtrace by running , followed by the command.
does this help?
via
There is no segfault if I build without
Marking this as P-high based on the
What setup are you using to pass ?
I had in my initially. reproduces the segfault as well.
was hitting segfaults with LLD with target-cpu=native, but that was on MSVC:
Hmm, I think i also have my linker set to lld, but I'm on linux...
Still crashes after llvm update in
I got the same SIGSEGV with at stage 0 Can't reproduce it with bootstrap from 1.47 to 1.47
some users hit it in gentoo with 1.48.0 downstream bug removing or helps as described here.
This
I ran into the same problem: OS: Ubuntu20.04 rustc exited with signal: 9 error: could not compile Caused by:

Discussion:
// FIXME(eddyb) producing readable type names for trait objects can result // in problematically distinct types due to HRTB and subtyping (see #47638). // ty::Dynamic(..) | <del> ty::Adt(..) | ty::Closure(..) | ty::Foreign(..) | ty::Generator(..) | ty::Str if !cx.sess().fewer_names() => { </del> <ins> ty::Adt(..) | ty::Closure(..) | ty::Foreign(..) | ty::Generator(..) | ty::Str => { </ins> let mut name = with_no_trimmed_paths(|| layout.ty.to_string()); if let (&ty::Adt(def, _), &Variants::Single { index }) = (layout.ty.kind(), &layout.variants)

} Some(name) } <del> ty::Adt(..) => { // If `Some` is returned then a named struct is created in LLVM. Name collisions are // avoided by LLVM (with increasing suffixes). If rustc doesn't generate names then that // can improve perf. Some(String::new()) } </del> _ => None, };

<del> // build-pass </del> <ins> // ignore-test // FIXME(const_generics): This test causes an ICE after reverting #76030. </ins> #![allow(incomplete_features)] #![feature(const_generics)]
Change:
Between nightly-2020-08-29 and nightly-2020-09-02, the following began printing an ICE message (despite compiling successfully). The relevant compiler commit range is appears extremely relevant so mentioning From the PR description it sounds like the PR was intended to have no effect unless the new -Z flag is passed. Is it possible it could be causing this? Before: After:
It looks like I misunderstood how works. I'll PR a fix tomorrow.
Assigning as and removing .
PR is up at

Discussion:
} fn enter<R>(self, f: impl FnOnce() -> R) -> R { <ins> let force_show_panics = self.force_show_panics; </ins> // Hide the default panic output within `proc_macro` expansions. // NB. the server can't do this because it may use a different libstd. static HIDE_PANICS_DURING_EXPANSION: Once = Once::new();

panic::set_hook(Box::new(move |info| { let show = BridgeState::with(|state| match state { BridgeState::NotConnected => true, <del> // Something weird is going on, so don't suppress any backtraces BridgeState::InUse => true, BridgeState::Connected(bridge) => bridge.force_show_panics, </del> <ins> BridgeState::Connected(_) | BridgeState::InUse => force_show_panics, </ins> }); if show { prev(info)

<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::{TokenStream, Ident, Span}; #[proc_macro] pub fn panic_in_libproc_macro(_: TokenStream) -> TokenStream { Ident::new("", Span::call_site()); TokenStream::new() } </ins>

<ins> // aux-build:proc-macro-panic.rs // edition:2018 // ignore-stage1 // only-linux // // FIXME: This should be a normal (stage1, all platforms) test in // src/test/ui/proc-macro once issue #59998 is fixed. // Regression test for issue #76270 // Tests that we don't print an ICE message when a panic // occurs in libproc-macro (when `-Z proc-macro-backtrace` is not specified) extern crate proc_macro_panic; proc_macro_panic::panic_in_libproc_macro!(); //~ ERROR proc macro panicked fn main() {} </ins>

<ins> error: proc macro panicked --> $DIR/issue-76270-panic-in-libproc-macro.rs:15:1 | LL | proc_macro_panic::panic_in_libproc_macro!(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: message: `""` is not a valid identifier error: aborting due to previous error </ins>
Change:
that won't compile but should be a type error: But it gives a parse error instead: (It works if you put parens, like )

Discussion:
kw::Move, kw::Return, kw::True, <ins> kw::Try, </ins> kw::Unsafe, kw::While, kw::Yield,

<ins> // run-pass // compile-flags: --edition 2018 #![feature(try_blocks)] fn issue_76271() -> Option<i32> { return try { 4 } } fn main() { assert_eq!(issue_76271(), Some(4)); } </ins>
Change:
Command was with the following <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
And yes, was enough to get the build to finish, in case there were any questions as to whether that was the difference.
This is the first PR that fails with the error described in I do not know if the fault is here or in the symbol mangling but it as I understand it that function that is called is only used for the the size of an array and it feels strange that it shall be a bool -- it seems pretty clear the bug is in the symbol mangling rather than with , because it's not adding anything out of the "ordinary" Rust code. That said, it's likely that the const generic could be replaced to avoid the error perhaps.
Yeah, isn't this "just" an instance of new symbol mangling not being compatible with const generics?
was to tired that night when I hade bisected the rust build and this hade nothing to do with arrays that I was writing. was possible to avoid the bisect all together if I only hade looked trough all of the log. it is saying that it is eg. that fails so it is the bool in the path that is triggering the fault in symbol mangling. according to only unsigned integers is handled and the rest is left for "future const-generics work" shall this be marked with some const-generic label? right now it is only bool that also needs to be handled for rustc to compile but do not know how to go forward
seems like there is a issue for adding mangling support here so this will probably be fixed when that issue is fixed.

Discussion:
match ct.ty.kind() { ty::Uint(_) => {} <ins> ty::Bool => {} </ins> _ => { bug!("symbol_names: unsupported constant of type `{}` ({:?})", ct.ty, ct); }

<ins> // check-pass // revisions: legacy v0 //[legacy]compile-flags: -Z symbol-mangling-version=legacy --crate-type=lib //[v0]compile-flags: -Z symbol-mangling-version=v0 --crate-type=lib #![feature(min_const_generics)] pub struct Bar<const F: bool>; impl Bar<true> { pub fn foo() {} } impl<const F: bool> Bar<F> { pub fn bar() {} } fn main() {} </ins>
Change:
x.rs: y.rs The copy propagation removes storage markers during optimization. Afterwards state transforms considers them to be always live across yield. Due to pass ordering, requires inliner to expose the issue.
The ICE is no longer reproduced with the latest nightly on glacier, marking as .
For copy propagation this is still an issue, but the test case now requires . For destination propagation the test case was fixed after changes that stop propagation if either local was ever borrowed. Hard to say if this fixed the issue more generally.
Thanks for the heads-up! Submitted a PR to readd this: rust-lang/glacier
Triage: It's now compiled fine (again) with the latest nightly (I'd say it's finally fixed by ).

Discussion:
<ins> // edition:2018 // compile-flags: -Z mir-opt-level=2 -Z unsound-mir-opts #[inline(always)] pub fn f(s: bool) -> String { let a = "Hello world!".to_string(); let b = a; let c = b; if s { c } else { String::new() } } </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // edition:2018 // build-pass #![feature(async_closure)] use std::future::Future; fn async_closure() -> impl Future<Output = u8> { (async move || -> u8 { 42 })() } fn main() { let _fut = async_closure(); } </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // build-pass #![feature(type_alias_impl_trait)] use std::marker::PhantomData; trait MyIndex<T> { type O; fn my_index(self) -> Self::O; } trait MyFrom<T>: Sized { type Error; fn my_from(value: T) -> Result<Self, Self::Error>; } trait F {} impl F for () {} type DummyT<T> = impl F; fn _dummy_t<T>() -> DummyT<T> {} struct Phantom1<T>(PhantomData<T>); struct Phantom2<T>(PhantomData<T>); struct Scope<T>(Phantom2<DummyT<T>>); impl<T> Scope<T> { fn new() -> Self { unimplemented!() } } impl<T> MyFrom<Phantom2<T>> for Phantom1<T> { type Error = (); fn my_from(_: Phantom2<T>) -> Result<Self, Self::Error> { unimplemented!() } } impl<T: MyFrom<Phantom2<DummyT<U>>>, U> MyIndex<Phantom1<T>> for Scope<U> { type O = T; fn my_index(self) -> Self::O { MyFrom::my_from(self.0).ok().unwrap() } } fn main() { let _pos: Phantom1<DummyT<()>> = Scope::new().my_index(); } </ins>

<ins> // edition:2018 // build-pass // compile-flags: -Z mir-opt-level=2 -L. // aux-build:issue_76375_aux.rs #![crate_type = "lib"] extern crate issue_76375_aux; pub async fn g() { issue_76375_aux::f(true); h().await; } pub async fn h() {} </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // ignore-cloudabi no std::fs // build-pass use std::fs::File; use std::io::{BufRead, BufReader}; fn file_lines() -> impl Iterator<Item = String> { BufReader::new(File::open("").unwrap()) .lines() .map(Result::unwrap) } fn main() { for _ in file_lines() {} } </ins>
Change:
This is causing spurious errors in the testsuite. <details<summaryDetails</summary</detailsOriginally posted by in
We should probably just remove/ignore these tests if they're causing spurious failures at a relatively high rate.
Maybe instead of removing them we could just split them into separate files? That way the order doesn't have to be deterministic, but we're still testing the output is correct.
Somehow this started to appear quite often recently, usually on builder.

Discussion:
// FIXME: if/when the output of the test harness can be tested on its own, this test should be // adapted to use that, and that normalize line can go away <del> // compile-flags:--test </del> <ins> // compile-flags:--test --test-args --test-threads=1 </ins> // rustc-env:RUST_BACKTRACE=0 // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // failure-status: 101
Change:
My nightly script that checks for reproducible builds of rustc failed this morning. Git bisect pointed me to (). With that commit, about 12 rlibs have differences in my parallel builds (librustcprivacy is one) and nothing in the diff of the binaries jumps out as an obvious culprit. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The PR you linked to wasn't merged; I think you meant
Ah, yes, sorry about that. The commit should be correct, though.
cc
oops, yea this is likely (not sure if there are other hashset/hashmap iterations happening, but that's the only one I found). So the fix is twofold: First change all the and to and where possible, and second, collect to a and sort that before iterating over the set/map
Ah, my bad. I can take this. claim

Discussion:
#![deny(unused_must_use)] <del> use quote::format_ident; use quote::quote; </del> use proc_macro::Diagnostic; <ins> use quote::{format_ident, quote}; </ins> use syn::spanned::Spanned; <del> use std::collections::{HashMap, HashSet}; </del> <ins> use std::collections::{BTreeSet, HashMap}; </ins> /// Implements #[derive(SessionDiagnostic)], which allows for errors to be specified as a struct, independent /// from the actual diagnostics emitting code.

/// ``` /// This function builds the entire call to format!. fn build_format(&self, input: &String, span: proc_macro2::Span) -> proc_macro2::TokenStream { <del> let mut referenced_fields: HashSet<String> = HashSet::new(); </del> <ins> // This set is used later to generate the final format string. To keep builds reproducible, // the iteration order needs to be deterministic, hence why we use a BTreeSet here instead // of a HashSet. let mut referenced_fields: BTreeSet<String> = BTreeSet::new(); </ins> // At this point, we can start parsing the format string. let mut it = input.chars().peekable();
Change:
I tried to build rust right after got merged and caught error:
cc
What command did you run?

Discussion:
/// Adds the compiler's directory of dynamic libraries to `cmd`'s dynamic /// library lookup path. <del> pub fn add_rustc_lib_path(&self, compiler: Compiler, cmd: &mut Cargo) { </del> <ins> pub fn add_rustc_lib_path(&self, compiler: Compiler, cmd: &mut Command) { </ins> // Windows doesn't need dylib path munging because the dlls for the // compiler live next to the compiler and the system will find them // automatically.

return; } <del> add_dylib_path(vec![self.rustc_libdir(compiler)], &mut cmd.command); </del> <ins> add_dylib_path(vec![self.rustc_libdir(compiler)], cmd); </ins> } /// Gets a path to the compiler specified.

self.command.env(key.as_ref(), value.as_ref()); self } <ins> pub fn add_rustc_lib_path(&mut self, builder: &Builder<'_>, compiler: Compiler) { builder.add_rustc_lib_path(compiler, &mut self.command); } </ins> } impl From<Cargo> for Command {

if builder.config.verbose() { cmd.arg("--verbose"); } <ins> // If the lib directories are in an unusual location (changed in // config.toml), then this needs to explicitly update the dylib search // path. builder.add_rustc_lib_path(self.compiler, &mut cmd); </ins> builder.run(&mut cmd); // Run rustbook/mdbook to generate the HTML pages. builder.ensure(RustbookSrc {

&[], ); <del> builder.add_rustc_lib_path(compiler, &mut cargo); </del> <ins> cargo.add_rustc_lib_path(builder, compiler); </ins> cargo.arg("--").args(builder.config.cmd.test_args()); if try_run(builder, &mut cargo.into()) {

t!(fs::create_dir_all(&dir)); cargo.env("RUSTFMT_TEST_DIR", dir); <del> builder.add_rustc_lib_path(compiler, &mut cargo); </del> <ins> cargo.add_rustc_lib_path(builder, compiler); </ins> if try_run(builder, &mut cargo.into()) { builder.save_toolstate("rustfmt", ToolState::TestPass);

cargo.arg("--").args(builder.config.cmd.test_args()); <del> builder.add_rustc_lib_path(compiler, &mut cargo); </del> <ins> cargo.add_rustc_lib_path(builder, compiler); </ins> if !try_run(builder, &mut cargo.into()) { return;

cargo.arg("--").args(builder.config.cmd.test_args()); <del> builder.add_rustc_lib_path(compiler, &mut cargo); </del> <ins> cargo.add_rustc_lib_path(builder, compiler); </ins> builder.run(&mut cargo.into()); }

None => { let rendered: Vec<&str> = msgs.iter().filter_map(|msg| msg["rendered"].as_str()).collect(); <ins> let non_json: Vec<&str> = stderr.lines().filter(|line| !line.starts_with('{')).collect(); </ins> Err(format!( <del> "did not find lint `{}` in output of example, got:n{}", </del> <ins> "did not find lint `{}` in output of example, got:n{}n{}", </ins> name, <ins> non_json.join("n"), </ins> rendered.join("n") ) .into())
Change:
modify labels: A-mir T-doc C-enhancement E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I would be interested in doing this :) claim
Should this issue be on rustc-dev-guide?
I'm not sure if it's covered there, but I meant in terms of a doc comment on the struct.
Ok, take a look around https://rustc-dev- then. But you might want to discuss around Zulip what the convention is for doc-comments.
Hmm, I think most of the items in MIR have doc comments. I can ask on Zulip though.

Discussion:
// BasicBlock rustc_index::newtype_index! { <ins> /// A node in the MIR [control-flow graph][CFG]. /// /// There are no branches (e.g., `if`s, function calls, etc.) within a basic block, which makes /// it easier to do [data-flow analyses] and optimizations. Instead, branches are represented /// as an edge in a graph between basic blocks. /// /// Basic blocks consist of a series of [statements][Statement], ending with a /// [terminator][Terminator]. Basic blocks can have multiple predecessors and successors, /// however there is a MIR pass ([`CriticalCallEdges`]) that removes *critical edges*, which /// are edges that go from a multi-successor node to a multi-predecessor node. This pass is /// needed because some analyses require that there are no critical edges in the CFG. /// /// Read more about basic blocks in the [rustc-dev-guide][guide-mir]. /// /// [CFG]: https://rustc-dev-guide.rust-lang.org/appendix/background.html#cfg /// [data-flow analyses]: ///     https://rustc-dev-guide.rust-lang.org/appendix/background.html#what-is-a-dataflow-analysis /// [`CriticalCallEdges`]: ../../rustc_mir/transform/add_call_guards/enum.AddCallGuards.html#variant.CriticalCallEdges /// [guide-mir]: https://rustc-dev-guide.rust-lang.org/mir/ </ins> pub struct BasicBlock { derive [HashStable] DEBUG_FORMAT = "bb{}",

/////////////////////////////////////////////////////////////////////////// // BasicBlockData and Terminator <ins> /// See [`BasicBlock`] for documentation on what basic blocks are at a high level. </ins> #[derive(Clone, Debug, TyEncodable, TyDecodable, HashStable, TypeFoldable)] pub struct BasicBlockData<'tcx> { /// List of statements in this block.