jiebi/CodeConvo huggingface dataset:
Change:
suggest_adding_lifetime_params(self.infcx.tcx, sub, ty_sup, ty_sub, diag); } <ins> fn suggest_move_on_borrowing_closure(&self, diag: &mut Diagnostic) { let map = self.infcx.tcx.hir(); let body_id = map.body_owned_by(self.mir_def_id()); let expr = &map.body(body_id).value; let mut closure_span = None::<rustc_span::Span>; match expr.kind { hir::ExprKind::MethodCall(.., args, _) => { // only the first closre parameter of the method. args[0] is MethodCall PathSegment for i in 1..args.len() { if let hir::ExprKind::Closure(..) = args[i].kind { closure_span = Some(args[i].span.shrink_to_lo()); break; } } } hir::ExprKind::Block(blk, _) => { if let Some(ref expr) = blk.expr { // only when the block is a closure if let hir::ExprKind::Closure(..) = expr.kind { closure_span = Some(expr.span.shrink_to_lo()); } } } _ => {} } if let Some(closure_span) = closure_span { diag.span_suggestion_verbose( closure_span, format!("consider adding 'move' keyword before the nested closure"), "move ", Applicability::MaybeIncorrect, ); } } </ins> }

Discussion:
Given the following code: The current output is: The actually needed fix here is the following, which should ideally be recommended <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
slightly more minimal:
claim
I came up with a solution of printing an extra line of to give user a recommendation of fixing the error by adding 'move' keyword before the closure parameter of map(). The following is the output for the first testing code. Is this good enough? This is the output from the second testing code ():
Refined the fix with a verbose suggestion of where to add keyword. The output of the first test case is: The output of the second test case is: In addition, the fix will also add the suggestion for nested closure block like this test case: The output of the above test case is:
Change:
use back::abi; <del> use lib::llvm::{llvm, ConstFCmp, ConstICmp, SetLinkage, PrivateLinkage, ValueRef, Bool, True}; </del> <ins> use lib::llvm::{llvm, ConstFCmp, ConstICmp, SetLinkage, PrivateLinkage, ValueRef, Bool, True, False}; </ins> use lib::llvm::{IntEQ, IntNE, IntUGT, IntUGE, IntULT, IntULE, IntSGT, IntSGE, IntSLT, IntSLE, RealOEQ, RealOGT, RealOGE, RealOLT, RealOLE, RealONE};

Discussion:
This line in my project currently causes an unimplemented expression error, told me to submit an issue
Change:
# Forces frame pointers to be used with `-Cforce-frame-pointers`. # This can be helpful for profiling at a small performance cost. frame-pointers = true <del> # Build the llvm-bitcode-linker as it is required for running nvptx tests llvm-bitcode-linker = true </del> [llvm] # Having this set to true disrupts compiler development workflows for people who use `llvm.download-ci-llvm = true`

Discussion:
With the latest , when I run a run-make test twice in a row, bootstrap rebuilds and : This has to be a recent regression, it didn't happen until ~yesterday. Confirmed with that it also happens for them.
Sounds suspiciously similar to
Yeah this is again caused by being enabled :laughing: Do you think that there's some more general solution to the rebuild problem?
Thanks for notifying me about this. I am travelling this weekend, meaning i might not have a chance to thoroughly investigate before Monday. (But I will at the latest be able to look on Monday). The last time it was due to dependency on the same crates with different rustflags. One from llbc-linker and one from some other tool (rustdoc?). The two different invocations maps to the same cache entry but is invalid between each other and thus triggers a rebuild. The solution last time was to mimic the rustflags being used other places in llbc-linker. That might be a good short term solution now as well. I don't know about the long term solution but it seems like either caching multiple versions of a crate or unifying the rustflag somewhere might be alternatives?
Of course, there's no rush, I just wanted to let you know, given that you already have some experience in debugging this :laughing: This seems rather brittle though, as you mention. I wonder what's so unique about this tool that it causes these rebuilds so often. You mentioned that we cannot share flags between all Step invocations. But maybe it would make sense to better share flags between at least this tool and other steps, rather than hardcoding selected flags? (as was done last time with the parallel compiler).
Actually, I wonder if we really need to enable this linker by default in all four bootstrap profiles.
Sure, seems fine to me. I didn't expect it to be a problem this frequently.
posted instead to disable this flag by default, I don't think it should be enabled for most contributors.
Change:
LL | /     match num { LL | |         1 => { LL | |             cx.answer_str("hi"); <del> | |             -------------------- | |             |                  | | |             |                  help: consider removing this semicolon | |             this is found to be of type `()` </del> <ins> | |             -------------------- this is found to be of type `()` </ins> LL | |         } LL | |         _ => cx.answer_str("hi"), | |              ^^^^^^^^^^^^^^^^^^^ expected `()`, found future LL | |     } | |_____- `match` arms have incompatible types <ins> | help: consider removing this semicolon | LL -             cx.answer_str("hi"); LL +             cx.answer_str("hi") | help: consider using a semicolon here, but this will discard any values in the match arms | LL |     }; |      + </ins> error: aborting due to previous error

Discussion:
I tried this code (): I expected to see this happen: A compiler error about missing between and Instead, this happened: This is very confusing, because I "know" that return type is which is coercible to anything else (or whatever is the technical explanation for "we can really ignore the return type of "), so it should not ever be present in error messages about mistyping stuff. <!-- 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. --: This issue is also present in 1.34.2 (from a year ago), and in two-week-old nightly (rustc 1.45.0-nightly ( 2020-05-11)) p.s.: When deminimizing the issue, i realized that it's even more confusing when match is the last statement in a for loop (as it was in my real code), i.e.: gives the same error message about incompatible match arms.
The s coerces to because the whole needs to evaluate as a statement, not an expression because its return value is ignored. Adding a trailing "fixes" the code.
As far as I can tell, didn't fix this issue (you didn't add a test for it either), and the two UI tests that the PR did touch, the suggestion didn't do anything useful -- it only fires when one of the arms is actually evaluated to be type , rather than being constrained to due to (lack of) semicolon.
Actually, we do suggest using a semicolon, but not via . I'm just gonna revert that, and add this as a test.
Change:
pub mod expr_use_visitor; mod astconv; <ins> mod bounds; </ins> mod check_unused; mod coherence; mod collect;

Discussion:
That file () has almost 3k LOC and just 3 lines of documentation on the file (methods and types are documented though). I'm entirely unsure how to process that file. I think splitting it up into submodules (e.g. start by extracting out all functions just handling error reporting into a separate module). Some of this work can be just mechanical splitting up, but some parts may require you to start understanding at least some of what's going on in the file in order to find a good module structure. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'll do it, although I am not familiar with the . At least the mechanical part is no problem. As to the model structure, I am going to dive into that issue so I can better think of a reasonable structure. If it is a problem that I am not familiar with the topic, I will back down, no worries.
That's awesome. Please wait until is merged though (you can subscribe to it so you see when it does get merged), because otherwise you'll just get loads of conflicts.
If you are unsure about the module structure, you can first post a design suggestion here if you want.
assign
You still working on this?
Not quite, my other PR is not yet through and I thought I wait for it. But if you want to do it, just take it. If not I'll be on it soon.
I would like to claim this, if nobody minds
assign It's all yours!
release-assignment
I'd like to work in this if is not on it anymore
generally it's fine if it's 3 months and there is no pr from the author. you can start working on it
Gotcha, thanks
claim
Change:
<ins> #![feature(generic_const_exprs, array_map)] #![allow(incomplete_features)] pub struct ConstCheck<const CHECK: bool>; pub trait True {} impl True for ConstCheck<true> {} pub trait OrdesDec { type Newlen; type Output; fn pop(self) -> (Self::Newlen, Self::Output); } impl<T, const N: usize> OrdesDec for [T; N] where ConstCheck<{N > 1}>: True, [T; N - 1]: Sized, { type Newlen = [T; N - 1]; type Output = T; fn pop(self) -> (Self::Newlen, Self::Output) { let mut iter = IntoIter::new(self); //~^ ERROR: failed to resolve: use of undeclared type `IntoIter` let end = iter.next_back().unwrap(); let new = [(); N - 1].map(move |()| iter.next().unwrap()); (new, end) } } fn main() {} </ins>

Discussion:
: <details<summaryerror output</summary</details
Rust playground:
Have you been able to reproduce this ICE with the latest nightly?
Playground link is not failing, I guess it's a good sign.
No longer ICEs since

The code below will trigger an ICE on the latest nightly build This is as small as i could make it while still triggering the error <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Also occurs on stable! Regression from 1.50 to 1.51 modify labels: -requires-nightly +regression-from-stable-to-stable
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-04-29 regressed nightly: nightly-2021-01-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed PR is , cc
See and
just because something is gated doesn't mean it can't crash on stable ;) Use the above code and try to build it on the playground or compile it with a stable compiler, it will ICE.
We briefly discussed this on . I'd revert some labels here because we think this is a nightly-only issue due to the unstable feature. The fact that it compiles and reproduces on stable is kind of misleading because it's the that allows that. Makes sense? modify labels: +requires-nightly -regression-from-stable-to-stable +P-medium
sure enough ;) but just to be clear, even without this results in an ICE on stable
Okay so this is a bit complicated. Because while this does has , is still ICEs on stable. That said, not including the feature gate doesn't ICE. Given that, I think the current labels are appropriate, except maybe . It is technically a stable to stable regression, but it requires a feature to ICE, and I'm not sure that's the spirit of what that label is intended to track.
agreed on the labels, I've got the context partially wrong here. modify labels: -requires-nightly
With this also doesn't ICE
No longer ICEs since as far as I could tell with various combinations of the new feature gates
Change:
<ins> // aux-build:issue-79890.rs // revisions:rpass1 rpass2 rpass3 // compile-flags:--extern issue_79890 --test // edition:2018 // Tests that we don't ICE when the set of imported crates changes #[cfg(rpass2)] use issue_79890::MyTrait; </ins>

Discussion:
This seems to be an incremental error‽ We need an external crate for this to work. Haven't managed it to work in an internal mod only :/ Also this only happens with . Haven't managed to get it running with sadly extern crate (let's call it f) code Then just remove and add afterwards again (or the other way round, it doesn't matter). This script does it for you: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pand with RUST_BACKTRACE=full the LLVMing assert vanishes </p</details
searched nightlies: from nightly-2020-12-08 to nightly-2020-12-10 regressed nightly: nightly-2020-12-10 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
Assigning as discussed as part of the and removing .
I've fixed the issue locally, and I'm working on a PR.
Opened
Change:
] [[package]] <ins> name = "compiletest_rs" version = "0.7.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "64698e5e2435db061a85e6320af12c30c5fd88eb84b35d2c1e03ce4f143255ca" dependencies = [ "diff", "filetime", "getopts", "lazy_static", "libc", "log", "miow", "regex", "rustfix 0.5.1", "serde", "serde_derive", "serde_json", "tempfile", "tester", "winapi", ] [[package]] </ins> name = "core" version = "0.0.0" dependencies = [

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Change:
a: &'tcx ty::Const<'tcx>, b: &'tcx ty::Const<'tcx>, ) -> RelateResult<'tcx, &'tcx ty::Const<'tcx>> { <del> debug!("{}.consts({:?}, {:?})", self.tag(), a, b); if a == b { return Ok(a); } let infcx = self.fields.infcx; let a = replace_if_possible(infcx.const_unification_table.borrow_mut(), a); let b = replace_if_possible(infcx.const_unification_table.borrow_mut(), b); let a_is_expected = self.a_is_expected(); match (a.val, b.val) { (ConstValue::Infer(InferConst::Var(a_vid)), ConstValue::Infer(InferConst::Var(b_vid))) => { infcx.const_unification_table .borrow_mut() .unify_var_var(a_vid, b_vid) .map_err(|e| const_unification_error(a_is_expected, e))?; return Ok(a); } (ConstValue::Infer(InferConst::Var(a_id)), _) => { self.fields.infcx.unify_const_variable(a_is_expected, a_id, b)?; return Ok(a); } (_, ConstValue::Infer(InferConst::Var(b_id))) => { self.fields.infcx.unify_const_variable(!a_is_expected, b_id, a)?; return Ok(a); } _ => {} } self.fields.infcx.super_combine_consts(self, a, b)?; Ok(a) </del> <ins> self.fields.infcx.super_combine_consts(self, a, b) </ins> } fn binders<T>(&mut self, a: &ty::Binder<T>, b: &ty::Binder<T>)

Discussion:
<short summary of the bugI tried this code: I expected to see this happen: It should build. Instead, this happened: rustc crashed with: Possible workaround: replace with . playground: rustc version: 1.39.0-nightly 2019-09-15
cc
Also ICEs without explicit feature gate enabled :/
Change:
// We go to `usize` as we cannot allocate anything bigger anyway. let (field_count, variant, down) = match val.ty().kind() { ty::Array(_, len) => (usize::try_from(len.eval_usize(tcx, param_env)).unwrap(), None, op), <ins> // Checks if we have any variants, to avoid downcasting to a non-existing variant (when // there are no variants `read_discriminant` successfully returns a non-existing variant // index). ty::Adt(def, _) if def.variants.is_empty() => throw_ub!(Unreachable), </ins> ty::Adt(def, _) => { let variant = ecx.read_discriminant(&op)?.1; let down = ecx.operand_downcast(&op, variant)?;

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched toolchains through Regression in which is my rollup :sweat_smile: : ... Maybe ? cc
Reduced: `
Thanks for report and test case. In , I removed the special case for enums without variants, expecting that now that we handle failure gracefully it would be caught there. Alas, in this specific case, the succeeds while returning a non-existing variant index.
Change:
<ins> extern crate bar; #[no_mangle] pub extern "C" fn my_foo_add(left: i32, right: i32) -> i32 { // Obviously makes no sense but... unsafe { init(std::ptr::null_mut()); } bar::my_bar_add(left, right) } #[link(name = "systemd")] extern "C" { fn init(p: *mut ()); } </ins>

Discussion:
This is with Rust 1.69 but was probably always the case. Example: Compiling with prints Similarly when providing nothing changes. I didn't really follow how collects the libraries but I think it's via the query in which claims so this should be included AFAIU. Also the rationale of was to provide all libraries needed to link to the resulting , which is not the case in the above example. CC who originally implemented this feature.
It works as expected if the attribute is used in a dependencies. It seems to me that the function, is forgetting to add the current native libs. Doing something like this correctly adds to the output (even when passed via the command line) but I don't know if it's the right thing to do (cc
Yeah, I think adding is the correct fix. That adds the same information as does for dependencies.
Beware that is rather quirky. Originally Rust printed lines during build with information which link flags need to be to use the static library it builds, and is a blunt way of redirecting these "warnings". I don't know whether omission of is a bug or the old warnings just weren't meant to print them.
I can't imagine it to be a deliberate omission as is the only way to know how to correctly link any arbitrary staticlib afaik.
Change:
// - Trait object shims // - Fn Pointer shims <del> #![allow(dead_code)] </del> <ins> #![allow(dead_code, warnings)] </ins> extern crate reproducible_build_aux;

Discussion:
I was trying to determine if sccache could cache crates built as dependencies of different root crates. When I looked into it I found that the rlibs were not bit-identical despite being built from the same source. Most of the differences were in the debug info because the current directory winds up encoded there. I tried using which removed most of the differences but not all. A small difference in the metadata remains, which from looking at the diff of the serialized metadata said was the . do you know why this would be? I built this twice in different directories using the script. The diff of the rlib from each build (I generated that using .) Presumably this would block and also
Lots of stuff goes into the SVH. It might well be that something directory related accidentally goes into it. The SVH is computed here:
cc This is similar to the GCC build-path issue where other programs (and in the past, GCC's DWATproducer) likes to embed CFLAGS into the output. Suggested options: out -Zremap-path-prefix away from that SVH calculation - but other programs that also embed RUSTFLAGS or similar, would also need similar logic the envvar or something similar cargo support a constant flag (whose value does not depend on build-path) that figures out the right -Zremap-path-prefix for rustc so they don't need to appear in RUSTFLAGS. you'd also need to implement (1) but at least the caveat (about other programs) doesn't apply.
addresses (1), which is kind of orthogonal to (2) and (3) because the SVH will always be part of the output binary and it must change if the result of the mapping changes.
With the latest Rust nightly: which includes the fix from , the outputs from are still not the same:
I think we may still be hashing arguments?
Yes, it seems we do: Good catch! Not sure if we have to hash those at this point. The tracking system should catch resulting changes later on, if we don't have any holes in the tracking. This needs some review.
Edit: never mind - seems fixed now that I've rebased to master. I found that (after implementing it) still affects the SVH, even if the mapping does nothing: will generate different metadata hashes if I change the mapping, even though it doesn't affect anything and nothing else changes.
Change:
| LL |     let foo: (), |     ^^^ expected identifier, found keyword <del> | help: you can escape reserved keywords to use them as identifiers | LL |     r#let foo: (), |     ^^^^^ </del> error: expected `:`, found `foo` --> $DIR/removed-syntax-field-let.rs:2:9

Discussion:
Right now the raw ident suggestion when using a reserved keyword somewhere where it is not allowed is context free, leading to misleading output: The parser should perform some lookahead to see if it could actually continue parsing if a raw identifier had been supplied in its place and if so, only then suggest raw idents.
Or we shouldn't suggest using raw identifiers if we cannot do that easily and reliably.
Change:
pub fn iter(&self) -> Iter<T> { Iter { rx: self } } <ins> /// Returns an iterator that will attempt to yield all pending values. /// It will return `None` if there are no more pending values or if the /// channel has hung up. The iterator will never `panic!` or block the /// user by waiting for values. #[unstable(feature = "receiver_try_iter", issue = "34931")] pub fn try_iter(&self) -> TryIter<T> { TryIter { rx: self } } </ins> } impl<T> select::Packet for Receiver<T> {

Discussion:
Tracking issue for the new non-blocking iterator API introduced in . The API is currently gated behind the unstable feature. The API includes: - cc
Hey folks, just thought I'd ping this and ask if there's anything I can do to help guide this towards stable? Would love to start using it, but no worries if it's just low on the priority list :+1:
I'd like to know the same thing as mitchmindtree. Is this being guide towards stable?
fcp merge Seems like a nifty API to have!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell: psst I wasn't able to add the label, please do so.
The final comment period is now complete.