jiebi/CodeConvo huggingface dataset:
Change:
<ins> running 1 test test $DIR/unparseable-doc-test.rs - foo (line 6) ... FAILED failures: ---- $DIR/unparseable-doc-test.rs - foo (line 6) stdout ---- error: unterminated double quote string --> $DIR/unparseable-doc-test.rs:8:1 | 2 | "unterminated | ^^^^^^^^^^^^^ error: aborting due to previous error thread '$DIR/unparseable-doc-test.rs - foo (line 6)' panicked at 'couldn't compile the test', src/librustdoc/test.rs:319:13 note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace. failures: $DIR/unparseable-doc-test.rs - foo (line 6) test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out </ins>

Discussion:
Doc test with missing closing back quotes fail without any explanation. rust /// let x = 7; /// asserteq!(x, a()); /// // <- HERE /// fn a() -i32 { 7 } rustc 1.35.0-nightly ( 2019-03-22) binary: rustc commit-hash: commit-date: 2019-03-22 host: x8664-unknown-linux-gnu release: 1.35.0-nightly LLVM version: 8.0 rustc 1.33.0 ( 2019-02-28) binary: rustc commit-hash: commit-date: 2019-02-28 host: x86_64-unknown-linux-gnu release: 1.33.0 LLVM version: 8.0
~I believe this is related to . The second <coderust</codeline is unable to be lexed, so the lexer bails with an unbuffered fatal error.~ I was wrong. I have a fix incoming.
Oh hey, this looks to be related to and , cc
Change:
<ins> error[E0425]: cannot find value `err` in this scope --> $DIR/issue-103909.rs:5:12 | LL |     if Err(err) = File::open("hello.txt") { |            ^^^ not found in this scope | help: you might have meant to use pattern matching | LL |     if let Err(err) = File::open("hello.txt") { |        +++ error[E0308]: mismatched types --> $DIR/issue-103909.rs:5:8 | LL |     if Err(err) = File::open("hello.txt") { |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `bool`, found `()` error: aborting due to 2 previous errors Some errors have detailed explanations: E0308, E0425. For more information about an error, try `rustc --explain E0308`. </ins>

Discussion:
Given the following code: The current output is: Ideally the output should look like: How do we remove other diagnostics in this scenario?
label +D-verbose
Change:
); } }; <ins> let args = self.resolve_vars_if_possible(args); </ins> let closure_def_id = closure_def_id.expect_local(); assert_eq!(self.tcx.hir().body_owner_def_id(body.id()), closure_def_id);

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' 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 --
probably also caused by ?
yep ill put up a fix in a few
Change:
<ins> error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/issue-75889.rs:3:24 | LL | const FOO: dyn Fn() -> _ = ""; |                        ^ not allowed in type signatures error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/issue-75889.rs:4:25 | LL | static BOO: dyn Fn() -> _ = ""; |                         ^ not allowed in type signatures error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0121`. </ins>

Discussion:
I'll jump straight into the minimum verifiable example: Try it out . Here is the standard error output: Being a complete beginner I don't really know what I can add to this report, and I have a workaround which I can use to avoid this problem. (I know what I can put in the place of ) Edit: () gives which seems not ideal.
Assigning as and removing .
There is a partial fix in , though it regresses diagnostics. I think it ought not to be too much work to address this, but I do not have time at the moment.
This ICEs since . modify labels: +regression-from-stable-to-stable
Change:
<del> Subproject commit e1a0f66373a1a185334a6e3be24e94161e3b4a43 </del> <ins> Subproject commit 965160d4d7976ddead182b4a65b73f59818537de </ins>

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! cc the PR reviewer, and -- nominating for prioritization.
Miri is fixed upstream, but will be broken again by so I'd like to land that before updating.
Change:
result } <del> /// Checks whether a trait's method is impossible to call on a given impl. </del> <ins> /// Checks whether a trait's associated item is impossible to reference on a given impl. </ins> /// /// This only considers predicates that reference the impl's generics, and not /// those that reference the method's generics. <del> fn is_impossible_method(tcx: TyCtxt<'_>, (impl_def_id, trait_item_def_id): (DefId, DefId)) -> bool { </del> <ins> fn is_impossible_associated_item( tcx: TyCtxt<'_>, (impl_def_id, trait_item_def_id): (DefId, DefId), ) -> bool { </ins> struct ReferencesOnlyParentGenerics<'tcx> { tcx: TyCtxt<'tcx>, generics: &'tcx ty::Generics,

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. --The command causes an ICE error. This happens when we use the features of () in different workspaces. workspace- : workspace- : <!-- 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 --<!-- TRIAGEBOT_END --
label T-rustdoc
label -needs-triage A-cross-crate-reexports Ah lol, just noticed that we're also leaking the desugared form of RPITITs (the assoc ty) for a slightly altered non-icing version of this code (still cross-crate tho). Also needs to be addressed at some point, taking a mental note. claim
Change:
<ins> //! This test used to actually start evaluating the static even though //! there were errors in typeck. //! issue: rust-lang/rust#123153 pub struct Foo { pub version: str, } pub struct Bar { pub ok: &'static [&'static Bar], pub bad: &'static Foo, } pub static WITH_ERROR: Foo = Foo { version: 0 }; //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| ERROR the size for values of type `str` cannot be known at compilation time //~| ERROR mismatched types pub static USE_WITH_ERROR: Bar = Bar { ok: &[], bad: &WITH_ERROR }; fn main() {} </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. --(reduced) <details<summary<strongOriginal</strong</summary<p</p</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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Bisects to , but I guess it just made the ICE easier to reach. cc
Nope unfortunately this one only reproduces with statics, and thus can't be reached on stable or before that PR. It's still not useful to look at to figure out why it's ICEing now, as the ICE is happening somewhere else entirely.
Change:
<ins> error[E0618]: expected function, found `(&'static str, {integer})` --> $DIR/array-diagnostics.rs:4:9 | LL |         ("C200B40A83", 4) |         ^^^^^^^^^^^^^^^^^- help: consider separating array elements with a comma: `,` error: aborting due to previous error For more information about this error, try `rustc --explain E0618`. </ins>

Discussion:
Given the following code (): The current output is: <!-- The following is not always necessary. --Ideally the output should look like: and the compiler would preview the fix, by adding the commas in green. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This week I'm busier than I thought ;) release-assignment
label +A-parser
claim
Change:
<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn iter<'a>(data: &'a [usize]) -> impl Iterator<Item = usize> + 'a { data.iter() .map( |x| x // fn(&'a usize) -> &'(ReScope) usize ) .map( |x| *x // fn(&'(ReScope) usize) -> usize ) } fn main() { } </ins>

Discussion:
I got ICE for sometime and also searched in issues but cannot find a relative one. Sorry for not able to produce the minimal cases to pin down the actual failing case in my code base by simply reverting my code. x This issue does not exists in . Error message as follows: meta for 2018-03-21 meta for 2018-03-24 I appreciate any hints and suggestions on helping me to reproduce this issue into minimal case but right now I just can't find out what changes in my code caused this problem. My code base is
I have dig into this and found the snippet of code caused this problem: It should produce an error which did not appeared in previous build This is not the whole story, when I assign to a variable and return the variable, it got the same ICE but the type inference error gone. I finally able to mitigate the problem by turning the return type from to
I got a possibly same ICE with this code: Meta: <detailsBacktrace: </details
This gives me the same ICE: However this does not ICE:
Hi all. does not fix my issue.
Sorry, I forgot to test with your case. Though you seem to be using a nightly-2018-03-23 which can never contain unmerged , right? depends on which is not even compilable with recent nightlies.
Hi, sorry for the slow reply. I will try that again once the branch have been merged. Any ETA on when it will go into nightly? Thanks
No, it varies due to approval of other PRs. Here is the current queue:
Nightly 2018-04-14 contains . Could you reopen if the problem persists?
As at least one data point, I had the same issue and it was resolved with 2018-04-15.
Change:
let tuple_type = self.structurally_resolved_type(sp, fn_inputs[0]); match tuple_type.sty { ty::TyTuple(arg_types) if arg_types.len() != args.len() => { <del> parameter_count_error(tcx.sess, sp, fn_inputs, arg_types.len(), args.len(), </del> <ins> parameter_count_error(tcx.sess, sp_args, fn_inputs, arg_types.len(), args.len(), </ins> "E0057", false); expected_arg_tys = &[]; self.err_args(args.len())

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:
Ty::is_unit(self) } <ins> pub fn is_transparent<C>(self) -> bool where Ty: TyAbiInterface<'a, C>, { Ty::is_transparent(self) } </ins> pub fn offset_of_subfield<C>(self, cx: &C, indices: impl Iterator<Item = usize>) -> Size where Ty: TyAbiInterface<'a, C>,

Discussion:
The types and do not have the same ABI, as demonstrated by this testcase: The first is The second is Not sure whom to ping for RISC-V issues.
I think the fix will have to be to treat repr(transparent) unions specially somewhere around here
Cc
I'm afraid that the semantics of on unions are not clearly defined enough to figure out exactly how they should be specially treated (which variant should be used? etc.). Can you ping other people who have more knowledge on this? (If on unions turns out to be incompatible with ABIs that have content destructuring semantics that depends on the types of the field in the (e.g. the RISC-V C psABI) then we definitely have a bigger problem.)
I have no idea who would know anything about RISC-V calling conventions. :shrug: and no other ABI is failing this test. Basically, when the ABI description says "unions do X", then this should only apply to repr(C) and repr(Rust) unions. A repr(transparent) union must be treated exactly like its non-ZST field.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I haven't seen the Rust representation before - is the example saying that is splitting the values into float and integer registers and passing them, whereas is treating the whole thing as an bigger opaque integer? If so then based on section 18.2 here, I think the first one would be correct, assuming Rust doesn't ever make its tuples opaque helped me with something RISC-V at some point so may know where to look. Or deferring to clang
I honestly don't know what that means, it is sadly mostly undocumented. But I know it must be the same for the types to be ABI-compatible. has been opened to fix this issue.
now that this is fixed, is there a CI test to catch regressions?
There is a test in  but we don't run tests for riscv, since it's a tier 2 target.
Also see for another ABI issue that affects riscv (and more).
Are tier 2 tests run once before release or anything like that? It seems like at least a subset of tests (this one) are important enough that we should raise a red flag if we brake them somehow on any targets.

But that doesn't fit well into the tiering structure...
I'm not aware of any process like that. Part of the point of being tier 2 is not to burden all contributors with keeping the target working, is it? If we do want to accept that burden, we could consider running something like for tier 2 targets. But having this discussion in a closed issue makes little sense. Do you want to open a new issue or Zulip thread for discussing tier 2 target test coverage?
Inspired by I found a way to have a test for this:
Awesome! Thanks for the update here
Change:
let mut base = super::windows_base::opts(); base.cpu = "pentium4".to_string(); base.max_atomic_width = Some(64); <ins> base.eliminate_frame_pointer = false; // Required for backtraces </ins> // Mark all dynamic libraries and executables as compatible with the larger 4GiB address // space available to x86 Windows binaries on x86_64.

Discussion:
Backtraces on windows are generated using the function. This will generate incorrect backtraces if any of the frame pointers are omitted due to FPO. This would normally be fine, as debug builds are compiled without FPO enabled. However, even in debug builds, the code will be linked to an optimised build of , so if any frames from libstd are on the top of the stack when the backtrace is generated (which will always be the case for obvious reasons) there's the potential for one or more of those frames to have been optimised out, breaking the backtrace. On , this turns out to always be the case, as triggers FPO. On , it currently works, but I'm unsure if that's just luck, or whether FPO is not used for that target. This was not caught by tests because has been (accidentally?) disabled on all windows targets.
It is due to the Windowx 64-bit calling convention being designed in such a way that FPO can always be done and stack walking always work, unlike 32-bit.
Change:
export CCACHE_BASEDIR endif <del> FIND_COMPILER = $(word 1,$(1:ccache=)) </del> <ins> FIND_COMPILER = $(strip $(1:ccache=)) </ins> define CFG_MAKE_TOOLCHAIN # Prepend the tools with their prefix if cross compiling

Discussion:
I'm building Rust with , it fails at the miniz step:
This is due to , specifically . The problem is that --enable-ccache exports and it's ambiguous whether that's a file name with a space in it or two arguments.
Change:
<ins> error[E0277]: the trait bound `Box<T>: Copy` is not satisfied --> $DIR/issue-74824.rs:8:5 | LL |     type Copy<T>: Copy = Box<T>; |     ^^^^^^^^^^^^^^----^^^^^^^^^^ |     |             | |     |             required by this bound in `UnsafeCopy::Copy` |     the trait `Copy` is not implemented for `Box<T>` error[E0277]: the trait bound `T: Clone` is not satisfied --> $DIR/issue-74824.rs:8:5 | LL |     type Copy<T>: Copy = Box<T>; |     ^^^^^^^^^^^^^^----^^^^^^^^^^ |     |             | |     |             required by this bound in `UnsafeCopy::Copy` |     the trait `Clone` is not implemented for `T` | = note: required because of the requirements on the impl of `Clone` for `Box<T>` help: consider restricting type parameter `T` | LL |     type Copy<T: Clone>: Copy = Box<T>; |                ^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
<!-- 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: Getting some errors that does not satisfy the bound. Instead, this happened: The program compiled and resulted in a double free, and both are of type and point to the same memory... <!-- 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<summaryBacktrace</summary<p</p</detailsThis seems like some variation of and <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess, this duplicates . (Especially with the comment that I pretty much at the exact same time you created this issue).
Yes, I noticed it haha. Perhaps splitting your original issue up in several issues is a good idea, though
Triage: this given an error, on nightly. modify labels +E-needs-test claim
Change:
<ins> enum A { Value(()) } fn main() { let a = A::Value(()); a == A::Value; //~^ ERROR binary operation `==` cannot be applied to type `A` } </ins>

Discussion:
Hello, I found a bug while developing a project who produce an internal error. I create this code to reproduce the error: I got this error: ! If you do the same using an Option, for example: But if you do this: You got another internal compiler error: ! And to know: There is a correct way to do this without a match? I try this, but it wasn't accepted: Thank you
Does not panic on nightly-2019-06-17 (playground nightly). Must have been fixed. E-needstest?
you should update your rust :)
Hello, Ok with an update it's fixed: ! Thank you :) But, there is a way to have auto updates on Linux? There is a way to check the enum value type without checking the content wrapped? (with a if, not a match)
You can use the like so: (Or you can say , which I think is better style, but there are scenarios where one must resort to the method.)
For the record: has been fixed in
Ok thank you ! I forgot the "let" before the Some(), I think it's the reason why it's doesn't works.
Change:
} #[inline] <ins> fn fn_sig_source_span(fn_sig_span: Span, body_span: Span) -> Span { original_sp(fn_sig_span, body_span).with_ctxt(body_span.ctxt()) } #[inline] </ins> fn function_source_span(span: Span, body_span: Span) -> Span { <del> let span = original_sp(span, body_span).with_ctxt(SyntaxContext::root()); </del> <ins> let span = original_sp(span, body_span).with_ctxt(body_span.ctxt()); </ins> if body_span.contains(span) { span } else { body_span } }

Discussion:
I tried to generate test code coverage with this source file using and the LLVM tools. Source File: I expected to see this happen: Instead, this happened: . cargo-kcov, -Zprofile+grcov, and tarpaulin agree on 76%. In the output below lines , , were not executable but should have been executable+uncovered. Line should be executable+covered. <details<summarycoverage output</summary<p</p</details:
label: +A-code-coverage cc
Thanks for the bug report ! There was a recent bug fix (PR ) that addresses most of the missing coverage in your example (except for the last one). I just tested with and I see the expected coverage now for the first three ranges you reported seeing no coverage. These three are now showing coverage (with 0 executions) as expected: I was surprised to see no coverage for line 169, and I do see the did print, so that does seem to be a bug. So as of today, this issue is still a bug that I will need to look into further:
cc: Note, here is a snippet showing the missing coverage and code relevant to its codepath. I haven't thoroughly investigated this. I should be able to reproduce this in a simplified test (without the asynctrait and executor dependencies) that I can add to our unit tests. I don't have a theory yet. It could either be the closure's MIR is not included in coverage (seems unlikely to me), or is silently dropping coverage because it doesn't like something. (This is what was happening for the other missing coverage reported in this issue, that has since been resolved.) The test (shown at the bottom) calls and awaits the implementation of below: I do see the test output, including the from above, and from the awaited call to , below: The async closure seems to be missing coverage, as shown here. Note the wrapper function is covered and called (showing the coverage of on line 168), but there should also be coverage for the awaited implicit closure (lines 168-170, I believe). Since the program output proves this is called, the coverage should be showing execution. And the test that invokes it is covered:
Thank you. I see improvement in the latest nightly.

I minified the test case to the async issues for anyone looking at this (but it still uses executor and asynctrait.) Since this function is missing coverage too the issue isn't specific to async_trait thought.
So it turns out that the internal (auto-generated) closure actually does get coverage, but for some reason the code region for the macro, by itself, is not or not counted. I've created a draft PR with a new test and current results, demonstrating this issue. Once I figure out how to fix it, I'll submit the PR with the updated results.
Update: fixes the issue.