jiebi/CodeConvo huggingface dataset:
Change:
self.annotate_expected_due_to_let_ty(err, expr); self.suggest_compatible_variants(err, expr, expected, expr_ty); self.suggest_ref_or_into(err, expr, expected, expr_ty); <ins> if self.suggest_calling_boxed_future_when_appropriate(err, expr, expected, expr_ty) { return; } </ins> self.suggest_boxing_when_appropriate(err, expr, expected, expr_ty); self.suggest_missing_await(err, expr, expected, expr_ty); }

Discussion:
gives The in particular is confusing. This can be a pretty intimidating error message for someone new to async/await, when all they forgot was . I'm not sure if we can fix this without stabilizing so we can sprinkle some magic compiler dust on its error messages. Maybe there's something we can do, though. Maybe some intelligent use of type aliases in our error messages? cc
This can be handled without needing to stabilize the struct. It should act the same way that the primitive type cast suggestions do.
Some observations: There is no struct, it's a type-alias We could suggest invoking but that is a method defined only in the futures crate, which feels a bit awkward to me; I'd rather it were part of libstd We can* suggest as well ()
marking as OnDeck, since BoxFuture gets used quite often
I have a PR that suggests the right code for this: <img width="1269" alt="Screen Shot 2020-02-11 at 5 09 37 PM" src="https://user-"But if first you try : <img width="1271" alt="Screen Shot 2020-02-11 at 5 10 12 PM" src="https://user-"or : <img width="1303" alt="Screen Shot 2020-02-11 at 5 11 11 PM" src="https://user-"we will send you in a wild goose chase: <img width="946" alt="Screen Shot 2020-02-11 at 5 10 53 PM" src="https://user-"
Filed for the uncovered cases.
Change:
#![feature(exhaustive_patterns)] #![feature(extern_types)] #![feature(nll)] <ins> #![feature(once_cell)] </ins> #![feature(option_expect_none)] #![feature(or_patterns)] #![feature(min_specialization)]

Discussion:
After is merged, usage of in this module: should be replaced by . The dependency from corresponding can be removed afterwards. It might make sense to request a perf run, as version uses parkinglot, while the standard one uses std mutex, but I expect the difference to not matter -- fast path is equivalent for both.
claim
is done! Though, I am not unsure if we maybe should wait until it tickles down to beta? Not sure how bootstraping works with libstd, I guess, we can just try and see if the build fails.
The compiler always builds with the in-tree standard library, so cfg(bootstrap) should never be necessary (beyond lints, and other compiler-implemented rather than library-implemented) details.
ping this is ready to be implemented.
I'll start soon! Sorry I got a bit overwhelmed with work. If in the next couple of days I haven't replied feel free to re-assign.
On it!
once this is merged, should other sub-crates that depend on also be updated? Like for example. Also, what about ? Some usage can probably be replaced by .
We definitely should actively remove oncecell crate from all rustc’s crates, because having two difference sources of the same data structure feels bad. Replacing lazystatic with std::lazy would also be good!
I'll try to take of it once this issue is fixed :+1:
Change:
// We have to eagerly translate the "spine" of the statements // in order to get the lexical scoping correctly. let stmts = mirror_stmts(cx, self.id, &*self.stmts); <del> let opt_def_id = cx.tcx.hir.opt_local_def_id(self.id); let opt_destruction_extent = opt_def_id.and_then(|def_id| { cx.tcx.region_maps(def_id).opt_destruction_extent(self.id) }); </del> <ins> let opt_destruction_extent = cx.region_maps.opt_destruction_extent(self.id); </ins> Block { targeted_by_break: self.targeted_by_break, extent: CodeExtent::Misc(self.id),

Discussion:
The following code compiles to MIR without any (this is right before the pass): Cc
Cc
Indeed, even the shows no for that borrow. Looking further now.
Very weird: It seems like at the time that control reaches this statement in , there is no destruction scope attached to it...? still looking... (I'm not aware of a place where a destruction scope would be later...)
A ha! The destruction scope exists, but during the HIR -HAIR translation, we fail to find it, because the way we look up the destruction scope is with some code that looks like this: but the that we got for that is , so the lookup doesn't have a chance of working. Now to figure out what is returning here (or if we perhaps should be using a different key for the lookup?)
that I should not be attempting to do in the first place here (which then goes south when I fail to find the appropriate to use), because the itself now carries the appropriate directly, thanks to (specifically ) Will fix!
Change:
&& let hir::Node::Expr(lhs) = self.tcx.hir_node(*lhs_hir_id) && let hir::Node::Expr(rhs) = self.tcx.hir_node(*rhs_hir_id) && let Some(rhs_ty) = typeck_results.expr_ty_opt(rhs) <ins> && let trait_pred = predicate.unwrap_or(trait_pred) // Only run this code on binary operators && hir::lang_items::BINARY_OPERATORS .iter() .filter_map(|&op| self.tcx.lang_items().get(op)) .any(|op| { op == trait_pred.skip_binder().trait_ref.def_id }) </ins> { // Suggest dereferencing the LHS, RHS, or both terms of a binop if possible

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range start index 2 out of range for slice of length 1'', 'thread 'rustc' panicked at 'range start index 2 out of range for slice of length 1'' File: --snippet: 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<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Regression in cc sjwang05
claim
just to jump start, I just checked the contents of in the case presented: I'm checking what breaks in the test suite if we change the slicing to (which intuitively makes more sense but am still trying to piece things together). Edit: Ah, yeah, that won't work.
Thanks for the help, turns out I could've just used instead of slicing all along . I'll submit the PR once the test suite finishes running locally. As a side note, do you know why some binops seem to have 3 args? Intuitively it'd make sense to only have 2 args for the lhs and rhs tys--my guess is that the "extra" arg is something effects-related, but I'm not familiar at all with that part of the code.
Change:
// no-prefer-dynamic // ignore-msvc no jemalloc on msvc <ins> // ignore-bitrig no jemalloc on bitrig either </ins> #![feature(alloc_jemalloc)]

Discussion:
After the new snapshots landed, test failures showed up.
failures: [run-pass] run-pass/allocator- [run-pass] run-pass/allocator-
it looks like the outstanding jemalloc issues are finally biting us.
Change:
if supplied_arg_count >= expected_arg_count { fn_inputs.to_vec() } else { <del> parameter_count_error(tcx.sess, sp, fn_inputs, expected_arg_count, </del> <ins> parameter_count_error(tcx.sess, sp_args, fn_inputs, expected_arg_count, </ins> supplied_arg_count, "E0060", true); expected_arg_tys = &[]; self.err_args(supplied_arg_count) } } else { <del> parameter_count_error(tcx.sess, sp, fn_inputs, expected_arg_count, supplied_arg_count, "E0061", false); </del> <ins> parameter_count_error(tcx.sess, sp_args, fn_inputs, expected_arg_count, supplied_arg_count, "E0061", false); </ins> expected_arg_tys = &[]; self.err_args(supplied_arg_count) };

Discussion:
From: src/test/compile- Error E0057 needs a span_label, updating it from: To: Bonus 1: The note seems excessive. Check other E0057 errors. If it is not needed, remove the note. Bonus 2: The span for the error could likely focus on the parameters rather than the whole call.
I'm taking this one.
I think I've got most of this fix/working, but I'm having a problem fixing one of the unit test cases - issue- The other related test cases (issue-, issue-4935, method-call-err-msg, not-enough-arguments, overloaded-calls-bad and variadic-ffi-3) I was able to fix by following your blog guide. For some reason, issue-3044 is 'different' and I don't understand why. Not sure how to proceed...
- can you show the errors you get when you try to get issue-3044 to pass?
I think I fixed the problem. I'm now trying to get my code checked in and pushed to by fork. Having some ssh key/cert issues. I think once I do that, I can do a PR?
I just submitted a PR, but not sure if I did it correctly.
The note of and this one are printed by the same function, can I modify it to print the expected types directly in the label? I also did the bonus2 part for both E0060 and E0061.
Freeing this one up as part of the final push for .
Actually, according to the comments in maybe this is already closed? , can you confirm?
I think should be closed, and progress is under way in .
Change:
<del> Subproject commit ea85b4c7fb9826f72bd4ab743a703a34c75a40f0 </del> <ins> Subproject commit 07f1736390e1d4dd88cf9fae4ab7737ee5e086b7 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
<ins> error[E0530]: let bindings cannot shadow const parameters --> $DIR/issue-85348.rs:6:17 | LL | impl<const N: usize> ArrayWindowsExample { |            - the const parameter `N` is defined here ... LL |         let mut N; |                 ^ cannot be named the same as a const parameter error[E0412]: cannot find type `ArrayWindowsExample` in this scope --> $DIR/issue-85348.rs:3:22 | LL | impl<const N: usize> ArrayWindowsExample { |                      ^^^^^^^^^^^^^^^^^^^ not found in this scope error[E0282]: type annotations needed --> $DIR/issue-85348.rs:6:13 | LL |         let mut N; |             ^^^^^ consider giving `N` a type error: aborting due to 3 previous errors Some errors have detailed explanations: E0282, E0412, E0530. For more information about an error, try `rustc --explain E0282`. </ins>

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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
LL |         let x = 0; |         ^^^ unexpected token <del> error[E0658]: async closures are unstable --> $DIR/block-no-opening-brace.rs:29:5 | LL |     async |     ^^^^^ | = note: see issue #62290 <https://github.com/rust-lang/rust/issues/62290> for more information = help: add `#![feature(async_closure)]` to the crate attributes to enable error: aborting due to 6 previous errors </del> <ins> error: aborting due to 5 previous errors </ins> <del> For more information about this error, try `rustc --explain E0658`. </del>

Discussion:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?
Change:
<del> //@ known-bug: rust-lang/rust#124833 #![feature(generic_const_items)] trait Trait { const C<'a>: &'a str; } impl Trait for () { const C<'a>:  = "C"; } </del>

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. --(reduced) (original) This code is very similar to closed issue . The only difference is in line 17 which was in previous issue and now it's <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage F-genericconstitems claim
Change:
.collect()) }, ) <del> .unwrap() </del> } pub(crate) fn probe_op<OP, R>(

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'', 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'' 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<!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc ^^
claim
Change:
// `Trait<'a, Item = Type>` while accounting for the `<'a>` in the // suggestion. format!("{}, {}>", &snippet[..snippet.len() - 1], types.join(", ")) <ins> } else if in_expr_or_pat { // The user wrote `Iterator`, so we don't have a type we can suggest, but at // least we can clue them to the correct syntax `Iterator::<Item = Type>`. format!("{}::<{}>", snippet, types.join(", ")) </ins> } else { // The user wrote `Iterator`, so we don't have a type we can suggest, but at // least we can clue them to the correct syntax `Iterator<Item = Type>`.

Discussion:
Given the following code: %20%7B%0A%20%20%20%20let%20%20%3D%20MyIterator%3A%3Anext%3B%0A%20%20%20%20%2F%2Flet%20%20%3D%20MyIterator%3CItem%3D()%3E%3A%3Anext%3B%0A%7D) The current output is: But when when I write , it gets interpreted as comparison expressions like and it fails to compile with a lot of "cannot find value in this scope" and "cannot find crate in the list of imported crates". The suggestion is confusing because it is unclear how to apply it. The error goes away if you use directly: produces the error one would expect: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it gets evaluated as an expression because you are missing a . If you add them, then you get a new error message ():
I see, let me rephrase the issue: The suggestion is "help: specify the associated type: " where "help: specify the associated type: " with a double colon would be correct.
Triage: Suggestion is correct for code using (which all code written in Rust =2021 uses). For code written without in Rust <2021: No change. As mentioned, the suggestion should use an expression-style path (i.e., one with turbofishes).
claim
Working on tests before creating a PR. Multiple tests exist already that have an odd hardcoded expectation for error output, so I'll be double checking those make sense with these changes, and adding a few tests of my own. Otherwise, this really does seem like it was a simple two character fix, unless I missed something somewhere.
Yeah, it's a pretty easy one. Adding before is always correct — not only in expression contexts but also in type contexts since turbofish is also possible in type positions (e.g., ) — albeit redundant. Omitting before in type contexts would be a possible "optimization". However, it really isn't worth doing here.

Consider the following code which is ill-formed even after specifying the assoc ty. () would only be well-formed if we defined an inherent associated type () on which doesn't work yet anyway () and is pretty niche) or once we support arbitrary shorthand projections ().
Change:
<ins> // check-fail struct Foo<'a> //~ ERROR parameter `'a` is never used [E0392] { _a: [u8; std::mem::size_of::<&'a mut u8>()] //~ ERROR  a non-static lifetime is not allowed in a `const` } pub fn main() {} </ins>

Discussion:
The following simpl file causes rustc to panic when compiling:
Oh, removing the lifetime parameter in the type passed to size_of does not panic:
Reproduces with the NLL borrow checker (crashes in ). cc
Triage: This is no longer ICE with the latest nightly ( forbid the case):
Change:
pub fn htmldocck() -> Command { let mut python = python_command(); <del> python.arg(source_path().join("src/etc/htmldocck.py")); </del> <ins> python.arg(source_root().join("src/etc/htmldocck.py")); </ins> python } <del> pub fn source_path() -> PathBuf { </del> <ins> /// Path to the root rust-lang/rust source checkout. pub fn source_root() -> PathBuf { </ins> env_var("S").into() }

Discussion:
Some run-make tests refer to stdlib sources with which seems not ideal. suggested that we should introduce a helper to make this less fragile.
There is already the env var set by compiletest for the source root.
I'm actually dumb, we even already have in the support library:
That's a very descriptive environment variable name, lol
Change:
compiler_builtins = { version = "0.1.15" } profiler_builtins = { path = "../libprofiler_builtins", optional = true } unwind = { path = "../libunwind" } <del> hashbrown = { version = "0.3.0", features = ['rustc-dep-of-std'] } </del> <ins> hashbrown = { version = "0.4.0", features = ['rustc-dep-of-std'] } </ins> [dependencies.backtrace] version = "0.3.25"

Discussion:
In 1.35, 's requires , but in 1.36-beta it requires . Both are auto-derived, so it must be a change in their internals. Obviously, is quite different than the old implementation. ! ! Ditto for . I'm not sure if there's any real impact in this, but it should be considered, and perhaps audit for other similar changes. cc as discussed on IRC.
This is fixed in hashbrown 0.4.0.
Shouldn't be fixed as well?
Since is actually based on , it derives the same constraints.
Ah, gotcha. Thanks! Sorry for the false alarm :).
I think it would be a good idea to add a run-pass to check that these auto-trait impls don't change again.
might make sense to add them as tests to most collections. , , etc. don't have tests for these either. I've made this error in some of my collections (changing some internal implementation detail and breaking users that rely on auto traits working "like before").
Change:
# x86_64-apple-darwin configuration CC_x86_64-apple-darwin=$(CC) <del> LINK_x86_64-apple-darwin=cc </del> CXX_x86_64-apple-darwin=$(CXX) CPP_x86_64-apple-darwin=$(CPP) AR_x86_64-apple-darwin=$(AR)

Discussion:
Appears like: Essentially, 'LINK_foo' is empty. Heres a list:
I think this is your issue. (I ran into it myself while doing a build)
Dup of , apparently.
I believe this will be fixed by
Closing as a duplicate.
Change:
"hexagon" => hexagon::compute_abi_info(self), "riscv32" | "riscv64" => riscv::compute_abi_info(cx, self), "wasm32" | "wasm64" => { <del> if cx.target_spec().adjust_abi(abi) == spec::abi::Abi::Wasm { </del> <ins> if cx.target_spec().adjust_abi(abi, self.c_variadic) == spec::abi::Abi::Wasm { </ins> wasm::compute_wasm_abi_info(self) } else { wasm::compute_c_abi_info(cx, self)

Discussion:
While testing variadic function support with I discovered that Rust requires such functions to use either "C" or "cdecl" ABIs but requires the "system" ABI on non-x86 Windows. My undertstanding from discussing with is that this is not an issue with itself but with Rust's insistence that such functions aren't allowed to use the "system" ABI. It's just that is very strict about calling convention so that's where the issue surfaced. On x64 I should be able to compile this but Rust says no: This example works if I change the ABI to "cdecl" but that's not meant to be a valid ABI on x64 and so when I try to compile this with it fails: The practical result is that it is impossible to link this function with on non-x86.
cc which originally variadics support to some other calling conventions (though not it seems) behind the feature gate .
A workaround is to use "C" on non-x86 as I implemented here:
Thoughts on permitting variadic parameters with the calling convention for non-x86 Windows? If gets merged then we'll be pushing folks to use so that they get the correct calling convention for Windows APIs on all architectures, but that breaks compatibility with variadic parameters.
This work-around is . Would be great if there was a way that it could be avoided. :)
There's a comment saying this can't work: I don't understand anything about these ABIs so I can't say how accurate this is. Also I see nothing here special-casing x86, so why does the issue specifically mention non-x86?
Happy to update as soon as there's a way to avoid it.
Can we make equal to when applied to a variadic function? It's supposed to be whatever ABI is correct for the system api and is the correct ABI for a variadic win32 function. According to the acts as when applied to a variadic function.
Went ahead and opened for this.
Change:
[[package]] name = "git2" <del> version = "0.10.0" </del> <ins> version = "0.10.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "327d698f86a7ebdfeb86a4238ccdb004828939d3a3555b6ead679541d14e36c0" </del> <ins> checksum = "39f27186fbb5ec67ece9a56990292bc5aed3c3fc51b9b07b0b52446b1dfb4a82" </ins> dependencies = [ "bitflags", "libc",

Discussion:
Do we have plan to get rid of this restriction recently? A newer version of cc-rs is needed for VxWorks
can't currently be updated due to a build problem with riscv. More info at I think the issue is that rustbuild uses cc to discover cc toolchains, and gained riscv support, and so now it thinks it should use a gcc toolchain that doesn't exist. The detection is in and Alex mentioned just setting a env var in the riscv container might be enough. It's been on my todo list for a while, but I haven't had a chance to look at it. I can maybe try to look at it this weekend.
Thanks for working on this issue. Enjoy your weekend, it is not that urgent.