jiebi/CodeConvo huggingface dataset:
Code change:
def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

Related discussion:
text: 0-src/src/llvm- --write-if-changed -o -d " [2/2594] Building FAILED: G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows- /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-intrinsic-impl -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm- --write-if-changed -o -d " [3/2594] Building IntrinsicsARM.h. FAILED: include/llvm/IR/IntrinsicsARM.h G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include/llvm/IR/IntrinsicsARM.h /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-intrinsic-enums -intrinsic-prefix=arm -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.
Code change:
def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

Related discussion:
text: 0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm- --write-if-changed -o include/llvm/IR/IntrinsicsARM.h -d include/llvm/IR/IntrinsicsARM.h.d" [4/2594] Building IntrinsicsHexagon.h. FAILED: include/llvm/IR/IntrinsicsHexagon.h G:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include/llvm/IR/IntrinsicsHexagon.h /C "cd /D G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuild && G:rustc-1.59.0-srcrustc-1.59.0-srcbuildx8664-pc-windows-gnullvmbuildbinllvm- -gen-intrinsic-enums -intrinsic-prefix=hexagon -I G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include/llvm/IR -IG:/rustc-1.59.0-src/rustc-1.59.0-src/build/x8664-pc-windows-gnu/llvm/build/include -IG:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm-project/llvm/include G:/rustc-1.59.0-src/rustc-1.59.0-src/src/llvm- --write-if-changed -o include/llvm/IR/IntrinsicsHexagon.h -d include/llvm/IR/IntrinsicsHexagon.h.d" ninja: build stopped: subcommand failed.
Code change:
def update_submodules(self): """Update submodules""" <del> if (not os.path.exists(os.path.join(self.rust_root, ".git"))) or  self.get_toml('submodules') == "false": </del> <ins> has_git = os.path.exists(os.path.join(self.rust_root, ".git")) # This just arbitrarily checks for cargo, but any workspace member in # a submodule would work. has_submodules = os.path.exists(os.path.join(self.rust_root, "src/tools/cargo/Cargo.toml")) if not has_git and not has_submodules: print("This is not a git repository, and the requisite git submodules were not found.") print("If you downloaded the source from https://github.com/rust-lang/rust/releases,") print("those sources will not work. Instead, consider downloading from the source") print("releases linked at") print("https://forge.rust-lang.org/infra/other-installation-methods.html#source-code") print("or clone the repository at https://github.com/rust-lang/rust/.") raise SystemExit(1) if not has_git or self.get_toml('submodules') == "false": </ins> return default_encoding = sys.getdefaultencoding()

Related discussion:
text: thread 'main' panicked at ' command did not execute successfully, got: exit code: 1 build script failed, must exit now', C:UsersDragon boy.cargoregistrysrccmake-0.1.44src note: run with environment variable to display a backtrace finished in 70.343 seconds Build completed unsuccessfully in 0:04:02
Code change:
hasher.finish() }; let end_pos = start_pos.to_usize() + src.len(); <ins> if end_pos > u32::max_value() as usize { return Err(OffsetOverflowError); } </ins> let (lines, multibyte_chars, non_narrow_chars) = analyze_source_file::analyze_source_file(&src[..], start_pos); <del> SourceFile { </del> <ins> Ok(SourceFile { </ins> name, name_was_remapped, unmapped_path: Some(unmapped_path),

Related discussion:
text: I know that having huge literal in source is a bad idea, but it should not cause ICE :( It looks like something overflowed. Version: Command, output and backtrace: Here is the generator of the source:
cc
Took a quick look. We certainly have a restriction that any file can't be that large, because we use u32 for indexing. And looks like we never try to enforce it anywhere. I think the place to do that would be . Do we have any way to panic without this being marked as ICE? I don't want to thread to each , and this seems like a marginal error where it's totally OK to panic. This is even OK in the IDE context I think: IDE should enforce reasonable max size of the file (something like 10mb, not 4gb) at the virtual file system layer. The "just panic" fix is here:
Do we have any way to panic without this being marked as ICE? or if the context is available.
I tried to compile the same thing in gcc and clang: With gcc: With clang: EDIT: Opened
Code change:
fn main() { let x = Foo; x.zero(0)   //~ ERROR this function takes 0 parameters but 1 parameter was supplied <ins> //~^ NOTE expected 0 parameters </ins> .one()     //~ ERROR this function takes 1 parameter but 0 parameters were supplied //~^ NOTE the following parameter type was expected <ins> //~| NOTE expected 1 parameter </ins> .two(0);   //~ ERROR this function takes 2 parameters but 1 parameter was supplied //~^ NOTE the following parameter types were expected <ins> //~| NOTE expected 2 parameters </ins> let y = Foo; y.zero()

Related discussion:
text: From: src/test/compile- Error E0061 needs a span_label, updating it from: To: Bonus: the types could be incorporated into the label rather than a note (though we may want to avoid types with long names in the label)
Planning on tackling the bonus here. Is there a prefered max length for output on the console. In the case it would exceed this should i truncate the typename or just not include?
- great point. If you want to work on truncation, feel free to add it, too. I'm not sure if the term crate will tell you the current terminal size, but it may.
I'm fixing and I noticed that it and this issue currently share the same code for generating this error, and adding code to add a to the message in would fix both.
Did you do the bonus as well? I can tackle that if you haven't.
I haven't yet - I can fix the issue (currently testing/fixing unit tests) and you can take on the bonus part of the issue.
Sounds great to me! Thanks.
- I opened up issue to track the bonus portion of the work for you.
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. #![deny(unused_variable)] fn main() { for _ in range(1i, 101) { let x = (); //~ ERROR: unused variable: `x` match () { a => {} //~ ERROR: unused variable: `a` } } } </ins>

Related discussion:
text: compiles without a peep, even though and are unused. Commenting out the gives the expected output:
I think this an be closed
Thanks (fixed in )
Code change:
signature. Each type parameter must be explicitly declared, in an angle-bracket-enclosed, comma-separated list following the function name. <del> ```{.ignore} fn iter<T, F>(seq: &[T], f: F) where T: Copy, F: Fn(T) { for elt in seq { f(*elt); } } fn map<T, U, F>(seq: &[T], f: F) -> Vec<U> where T: Copy, U: Copy, F: Fn(T) -> U { let mut acc = vec![]; for elt in seq { acc.push(f(*elt)); } acc } </del> <ins> ```rust,ignore // foo is generic over A and B fn foo<A, B>(x: A, y: B) { </ins> ``` Inside the function signature and body, the name of the type parameter can be used as a type name. [Trait](#traits) bounds can be specified for type parameters to allow methods with that trait to be called on values of that type. This is <del> specified using the `where` syntax, as in the above example. </del> <ins> specified using the `where` syntax: ```rust,ignore fn foo<T>(x: T) where T: Debug { ``` </ins> When a generic function is referenced, its type is instantiated based on the context of the reference. For example, calling the `iter` function defined

Related discussion:
text: In the in the section it is stated that (emphasis mine) But the example shows a type parameter on , which requires parenthesis-enclosed type parameters rather than angle-brackets. mentioned on IRC that this might be some special case to open the possibility to easier change the traits at a later time (if I understood correctly), but I found it confusing to see a specialization using parenthesis without ever having heard they existed.
Isn't the text referring to Those angle brackets? "following the function name"
Yeah, I suspect the real confusion here is that the syntax with parens has not yet been introduced (nor is it explained anywhere, apparently), so it's the wrong example at this point in the document, and it's not clear to a first-time reader what is being referred to. It seems like there should be a sufficient example here that doesn't use closures, maybe one simple one with and , and one using traits over collections or iterators or something, to demonstrate that parameterized types can appear in the bounds, to make it easier to understand. That said, the reference is explicitly not intended to be pedagogical, and implicitly not yet expected to be complete.
Code change:
#![allow(unused_variables)]; //~ ERROR expected item, found `;` <del> //~^ ERROR `main` function </del> fn foo() {} <ins> //~^ ERROR `main` function </ins>

Related discussion:
text: Tested on nightly and stable. The second diagnostic is strange. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-diagnostics S-has-mvce
claim
any idea why rustbot ignored me?
Just guessing, the missing + for S-has-mcve maybe?
Oops, this should'nt've been closed.
Code change:
See [LICENSE-APACHE](LICENSE-APACHE), [LICENSE-MIT](LICENSE-MIT), and [COPYRIGHT](COPYRIGHT) for details. <ins> ## Trademark [trademark]: #trademark The Rust programming language is an open source, community project governed by a core team. It is also sponsored by the Mozilla Foundation (“Mozilla”), which owns and protects the Rust and Cargo trademarks and logos (the “Rust Trademarks”). If you want to use these names or brands, please read the [media guide][media-guide]. Third-party logos may be subject to third-party copyrights and trademarks. See [Licenses][policies-licenses] for details. [media-guide]: https://www.rust-lang.org/policies/media-guide [policies-licenses]: https://www.rust-lang.org/policies/licenses </ins>

Related discussion:
text: Want to fix this bug? There are . This github repository does not contain a trademark file, and I am curious if still applies, as it would seem. Debian and some other distributions are applying patches against the Rust language and Cargo package. I assume this qualifies as something which requires explicit approval? If so, removing or restricting packages from Cargo would also be considered a modification. e.g. some distributions may wish to block access to Cargo downloads that are not in compliance with license standards. Just wanted to get some clarification on this as it is not mentioned here in the repo and some folks seems to think that because there is no trademark "here" that rust-lang can be distributed with modifications without approval. I believe the only way such modifications would be allowed unrestricted, is if "rust" was not used at all in the package and it was clearly defined as a rebranded fork that is not affiliated with the official package - Otherwise the trademark policy is still enforced.
This question should be asked at the linked on the Legal page rather than here.
Just received a response. It seems a may be useful to direct people to the appropriate from github. This issue can be closed once trademark notification is included or mentioned on Thank you.
I've tagged this issue as and . To close this bug, we should add a new section to that mentions that there are trademarks on the rust name and logo, and link to If you want to fix this bug and need any help, please let me know, and I'm happy to assist!
Hi I'd like to work on this and opened to add a section about trademarks. But I'm not sure whether I made appropriate wording. Could you please help to review? Thanks a lot.
Any news regarding this ^ Cheers
Code change:
#[rustc_const_unstable(feature = "const_waker", issue = "102012")] pub const fn build(self) -> Context<'a> { let ContextBuilder { waker, local_waker, ext, _marker, _marker2 } = self; <del> Context { waker, local_waker, ext, _marker, _marker2 } </del> <ins> Context { waker, local_waker, ext: AssertUnwindSafe(ext), _marker, _marker2 } </ins> } }

Related discussion:
text: https://crater-
I'll need to re-check later but this seems to bisect to somehow.
The UI test changes from that PR appear to back this up, as confusing as it is.
I'm not sure what's going on in that crate, if it built successfully by mistake, or how that PR interacts with it, so let's cc the PR author and reviewer for validation.
After , no longer implements and , because the context now contains a which doesn't implement those traits. So this is an issue with the standard library and not the crate being built. Repro: label -T-compiler +T-libs +S-has-mcve
WG-prioritization assigning priority (). Noticing this on which says that was meant to be confined on nightly. Unsure about the fallout of this regression but for now marking as critical for tracking purposes. label -I-prioritize +P-critical
Revert up:
Isn't not unwind safe?
That line was by your PR, so while what you say is technically true, talking about what "already happened" when we are traveling back and forth through time via version control may be more confusing than helpful.
That line was already there. I the line below it though. Original PR:
Apologies, I guess I can't count numbers today? Hm, so, the full error of the regression is this: Note that it's trying to make a pointer implement . And for what it's worth, stable does indeed document is . Thus unfortunately that line you pointed to, as opposed to the one I thought you were referring to, is effectively just documenting that all are , and that will include regardless of whether it is is . And confusingly, , unlike .
I have opened as an alternative.
Code change:
///     } /// } /// ``` <del> fn lower_expr_await(&mut self, await_span: Span, expr: &Expr) -> hir::ExprKind<'hir> { let dot_await_span = expr.span.shrink_to_hi().to(await_span); </del> <ins> fn lower_expr_await(&mut self, dot_await_span: Span, expr: &Expr) -> hir::ExprKind<'hir> { let full_span = expr.span.to(dot_await_span); </ins> match self.generator_kind { Some(hir::GeneratorKind::Async(_)) => {} Some(hir::GeneratorKind::Gen) | None => { let mut err = struct_span_err!( self.sess, <del> await_span, </del> <ins> dot_await_span, </ins> E0728, "`await` is only allowed inside `async` functions and blocks" ); <del> err.span_label(await_span, "only allowed inside `async` functions and blocks"); </del> <ins> err.span_label(dot_await_span, "only allowed inside `async` functions and blocks"); </ins> if let Some(item_sp) = self.current_item { err.span_label(item_sp, "this is not `async`"); }

Related discussion:
text: This code: produces: Which is invalid. Looks like the span of the desugaring of uses only the part, instead of the span of the entire expression. This results in invalid suggestions when used by the code in .
I'm not entirely sure if this means that desugaring should use a bigger span, or if the suggestion diagnostic needs to be interpreted differently.
hmm.. is the only case where the desugared expr's span doesn't cover the whole piece of code it comes from? That doesn't sound right. If wonder if the expr should have the bigger span by default, and then async-specific code could grab the tighter span for diagnostics that need to point at the operator.
Some of the desugaring only uses the span, but the parts relevant for diagnostics like this do use the full span. Not sure if there's a problem there too.
I thought I might have accidentally introduced this bug in , but right after that PR was merged, the output was correct: So something changed in the last two months in what spans are used for await desugarings, it seems.
actually I think it was introduced in in , cc Do you need someone to fix this? I'm happy to put up a quick PR.
Yeah, looks like it: I just finished bisecting, which pointed at a rollup involving .
this was introduced in the PR linked earlier to try and improve other errors. It is tricky because reducing the span to only incurs these kind of bugs. On the other hand, the errors that got improved there became much less noisy, so I wouldn't want to revert the whole change. My fix above will solve this issue, but I'm sure there will be others in the future :-/
Code change:
<ins> // compile-flags:--test // run-pass // ignore-emscripten no subprocess support use std::fmt; use std::fmt::{Display, Formatter}; pub struct A(Vec<u32>); impl Display for A { fn fmt(&self, _f: &mut Formatter<'_>) -> fmt::Result { self.0[0]; Ok(()) } } #[test] fn main() { let result = std::panic::catch_unwind(|| { let a = A(vec![]); eprintln!("{}", a); }); assert!(result.is_err()); } </ins>

Related discussion:
text: I tried this code (using ): I expected to see this happen: The thread should've panicked with 'Index out of bounds: the len is 0 but the index is 0' Instead, this happened: Thread crashes with SIGILL (illegal instruction) This bug works in stable, beta and nightly. It also does the same in . Here is my (I figured that it might be useful given the nature of the bug). The bug doesn't appear if run from main, nor if run directly (without passing from the Display impl). : <details<summaryBacktrace</summary<prunning 1 test thread panicked while processing panic. aborting. error: test failed, to rerun pass '--lib' Caused by: process didn't exit successfully: (signal: 4, SIGILL: illegal instruction) </p</details
This seems to be due to the . Using instead works fine.
I can reproduce. This seems to happen if LOCALSTDERR is initialized (e.g., with setpanic) which leads us to this . Note that the RefCell there is borrowed so that we can write to it, but then when we go to panic we try to temporarily . This borrows the RefCell mutably, again, leading to a panic. Since this happens within an existing panic, we abort the process. Smaller example:
Code change:
<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/default-ty-closure.rs:3:20 | LL | struct X<const FN: fn() = { || {} }>; |                    ^^^^ | = note: the only supported types are integers, `bool` and `char` error: aborting due to 1 previous error </ins>

Related discussion:
text: 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
really need to add auto-bisection to icemaker reports... Regression in nightly-2021-04-26 found 9 bors merge commits in the specified range commit[0] 2021-04-24: Auto merge of - davidhewitt:revert-, r=GuillaumeGomez commit[1] 2021-04-24: Auto merge of - RalfJung:const-fn-feature-flags, r=oli-obk commit[2] 2021-04-25: Auto merge of - jyn514:no-span, r=GuillaumeGomez commit[3] 2021-04-25: Auto merge of - CDirkx:rt, r=m-ou-se commit[4] 2021-04-25: Auto merge of - cuviper:array-method-dispatch, r=nikomatsakis,m-ou-se commit[5] 2021-04-25: Auto merge of - RalfJung:black-box, r=Mark-Simulacrum commit[6] 2021-04-25: Auto merge of - lcnr:const-generics-defaults-name-res, r=varkor commit[7] 2021-04-25: Auto merge of - RalfJung:miri, r=RalfJung commit[8] 2021-04-25: Auto merge of - jsha:ephemeral-collapse, r=GuillaumeGomez maybe ?
hm, with , this crashes like this:
Hmm, I'm confused by the result of the bisection, I expected it to find a relatively recent commit since the reproducer doesn't ICE on stable (1.73) (while it does ICE on beta and nightly):
Doesn't ICE if is enabled.
this feature fixing an ice instead of causing one, that's a first...
This errors cleanly since beta 1.76.