jiebi/CodeConvo huggingface dataset:
Change:
pub prior_arm_ty: Ty<'tcx>, pub prior_arm_span: Span, pub scrut_span: Span, <ins> pub scrut_hir_id: hir::HirId, </ins> pub source: hir::MatchSource, pub prior_arms: Vec<Span>, pub opt_suggest_box_span: Option<Span>,

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:
/// Creates a draining iterator that removes the specified range in the vector /// and yields the removed items. /// <del> /// Note 1: The element range is removed even if the iterator is only /// partially consumed or not consumed at all. /// /// Note 2: It is unspecified how many elements are removed from the vector /// if the `Drain` value is leaked. </del> <ins> /// When the iterator **is** dropped, all elements in the range are removed /// from the vector, even if the iterator was not fully consumed. If the /// iterator **is not** dropped (with [`mem::forget`] for example), it is /// unspecified how many elements are removed. </ins> /// /// # Panics ///

Discussion:
I wanted to move out a number of front element from a vector, like but I wonder if this is the right way to do this cause doc is unclear, note 1 and note 2 say the opposite each other: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
"partially consumed" means taking a few elements out and then dropping the value. Note 2 talks specifically about leaking the value. Is there any way to make this more clear in the docs?
What leaked mean for you ? How would I leak drain struct ? Drop it ?
No, leaking means specifically destroying a value without running its destructor, for example via 
So I think write: Because in the current form the two note look like they apply both whereas it's two difference case, leaked or not. (I'm not sure leak is the good word here for me leak mean leak memory not forget it, so maybe say "without run it's destructor" is more clear)
I myself am familiar with this usage of "to leak", but I don't know how I picked up that, why this is called leaking, or where it's explained in the docs. I suspect that this usage originates from smart pointers, for which destroying them without running destructors would leak the referenced objects. If we generalize this to something that is not a smart pointer, it's called jargon. Although it's convenient to use (in fact, there are more than ten instances of this usage in the standard library), it's not something we can expect to be understood for sure. For this reason, I agree with Replacing the word with something like “destroyed without running its destructor” or at least adding a reference to in parentheses would make sense.
claim
Change:
/// As a result, using `&packed.unaligned as *const FieldType` causes immediate /// *undefined behavior* in your program. /// <del> /// An example of what not to do and how this relates to `write_unaligned` is: </del> <ins> /// Instead you must use the [`ptr::addr_of_mut!`](addr_of_mut) /// macro to create the pointer. You may use that returned pointer together with /// this function. /// /// An example of how to do it and how this relates to `write_unaligned` is: </ins> /// <del> /// ```no_run </del> <ins> /// ``` </ins> /// #[repr(packed, C)] /// struct Packed { ///     _padding: u8, ///     unaligned: u32, /// } /// <del> /// let v = 0x01020304; </del> /// let mut packed: Packed = unsafe { std::mem::zeroed() }; /// <del> /// #[allow(unaligned_references)] /// let v = unsafe { ///     // Here we attempt to take the address of a 32-bit integer which is not aligned. ///     let unaligned = ///         // A temporary unaligned reference is created here which results in ///         // undefined behavior regardless of whether the reference is used or not. ///         &mut packed.unaligned ///         // Casting to a raw pointer doesn't help; the mistake already happened. ///         as *mut u32; </del> <ins> /// // Take the address of a 32-bit integer which is not aligned. /// // In contrast to `&packed.unaligned as *mut _`, this has no undefined behavior. /// let unaligned = std::ptr::addr_of_mut!(packed.unaligned); </ins> /// <del> ///     std::ptr::write_unaligned(unaligned, v); </del> <ins> /// unsafe { std::ptr::write_unaligned(unaligned, 42) }; </ins> /// <del> ///     v /// }; </del> <ins> /// assert_eq!({packed.unaligned}, 42); // `{...}` forces copying the field instead of creating a reference. </ins> /// ``` /// <del> /// Accessing unaligned fields directly with e.g. `packed.unaligned` is safe however. // FIXME: Update docs based on outcome of RFC #2582 and friends. </del> <ins> /// Accessing unaligned fields directly with e.g. `packed.unaligned` is safe however /// (as can be seen in the `assert_eq!` above). </ins> /// /// # Examples ///

Discussion:
Rust 1.51 was released yesterday and included the  macro. Its documentation talks about its usage in creating pointers to unaligned fields without the need for an intermediate reference: Despite that, the documentation of [] states the following: The documentation of [] should be updated to reflect the new changes in the language. : and modify labels: T-doc claim []: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Change:
v.push_str(&minify_replacer( &format!("{}n{}", variables.join(""), all_indexes.join("n")), options.enable_minification)); <del> v.push_str("initSearch(searchIndex);addSearchOptions(searchIndex);"); </del> <ins> // "addSearchOptions" has to be called first so the crate filtering can be set before the // search might start (if it's set into the URL for example). v.push_str("addSearchOptions(searchIndex);initSearch(searchIndex);"); </ins> cx.shared.fs.write(&dst, &v)?; } if options.enable_index_page {

Discussion:
Right now it is allowed to select whether we want to search within all crates or in the specific ones (e.g. core, std, etc). It would be really useful to remember the selected option, because in most cases we want to search in the std crate only. cc
Good idea!
Does not work, neither in stable nor nightly. Go to Choose the "std" option. Type Option, click on it We still see the "All crates" on the , and if we try to search something else, results will be from all sources anyway.
Indeed, will take a look quickly.
Works perfectly now. Thanks!
Change:
} struct DiagnosticHandlers<'a> { <del> inner: Box<(&'a CodegenContext, &'a Handler)>, </del> <ins> data: *mut (&'a CodegenContext, &'a Handler), </ins> llcx: ContextRef, }

Discussion:
I don't know if this is really problem, but e.g. the reimplements this function (and yields a bunch of other s, too. This needs some looking at Mostly leaving this here so I don't forget
is probably a hack for cache keying, and should ideally be removed?
Change:
<del> Subproject commit 266b75faecd11e6a0b63fb6526fac56cda22bebc </del> <ins> Subproject commit 3fafb835ea42e6e3af27f5dc8f26bda590cb49e9 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! And nominating for compiler team prioritization.
Working on it!
something odd happened with the notification here... the PR is by but the bot pinged .
I sent the PR from a repository under fusion-engineering-forks. Looks like it uses the owner of the repo the PR came from, instead of the user that opened the PR.
Reopening until the submodule is bumped.
Change:
variant.ident == ident && variant.ctor_kind == CtorKind::Const }) { <ins> let variant_count = edef.variants.len(); </ins> cx.tcx.struct_span_lint_hir( BINDINGS_WITH_VARIANT_NAME, p.hir_id, p.span, |lint| { let ty_path = cx.tcx.def_path_str(edef.did); <del> lint.build(&format!( </del> <ins> let mut err = lint.build(&format!( </ins> "pattern binding `{}` is named the same as one  <del> of the variants of the type `{}`", </del> <ins> of the variants of the type `{}`", </ins> ident, ty_path <del> )) .code(error_code!(E0170)) .span_suggestion( p.span, "to match on the variant, qualify the path", format!("{}::{}", ty_path, ident), Applicability::MachineApplicable, ) .emit(); </del> <ins> )); err.code(error_code!(E0170)); // If this is an irrefutable pattern, and there's > 1 variant, // then we can't actually match on this. Applying the below // suggestion would produce code that breaks on `check_irrefutable`. if rf == Refutable || variant_count == 1 { err.span_suggestion( p.span, "to match on the variant, qualify the path", format!("{}::{}", ty_path, ident), Applicability::MachineApplicable, ); } err.emit(); </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case
Change:
custom_unwind_resume: true, abi_return_struct_as_int: true, emit_debug_gdb_scripts: false, <ins> requires_uwtable: true, </ins> .. Default::default() }

Discussion:
From Gecko profiler uses EHABI information to walk stack. But since rustc doesn't generate EHABI, it cannot walk stack on generated code by rust. says, "-C panic=abort" causes that EHABI isn't emitted", so we need a option not to remove it (or don't remove EHABI even if -C panic=abort).
Note the same actually applies to EH_FRAME info on x86-64, which iirc the Firefox profiler also uses on x86-64. More generally, it can be desirable to have unwind info even when panic doesn't unwind.
For C/C++ code in Firefox we use  to ensure that the compiler generates these when is on: The equivalent for x86-64 is  which is apparently on by default. It seems like having a compiler option to enable this would be good enough, since the behavior here mirrors what gcc does: only emit unwind info if needed for exceptions/unwinding.
LLVM seems to turn on EHABI as default by (EnableARMEHABI is removed by this landing, but still has it) is similar issue for Win64 ABI.
This may or may not be related to , but I can prepare a patch like for the targets here. do you know what targets are in use by Firefox and would need this treatment?
Change:
error[E0597]: `b` does not live long enough --> $DIR/ref-escapes-but-not-over-yield.rs:24:13 | <del> LL |         a = &b; |             ^^ borrowed value does not live long enough LL |         //~^ ERROR `b` does not live long enough LL |     }; |     - borrowed value only lives until here </del> <ins> LL |       let mut b = move || { |  _________________- LL | |         yield(); LL | |         let b = 5; LL | |         a = &b; | |             ^^ borrowed value does not live long enough LL | |         //~^ ERROR `b` does not live long enough LL | |     }; | |     - | |     | | |     borrowed value only lives until here | |_____temporary later dropped here, potentially using the reference |       borrow may end up in a temporary, created here </ins> error: aborting due to previous error

Discussion:
Code shows a case where doesn't stay borrowed for long enough allowing it to be mutated while a reference to it exists. I think treating generators as if they implement would fix this, but I'm not sure if this will end up causing incorrect errors in other places.
Change:
bad: data[..= usize::MAX]; message: "maximum usize"; } <ins> in mod boundpair_overflow_end { data: [0; 1]; bad: data[(Bound::Unbounded, Bound::Included(usize::MAX))]; message: "maximum usize"; } in mod boundpair_overflow_start { data: [0; 1]; bad: data[(Bound::Excluded(usize::MAX), Bound::Unbounded)]; message: "maximum usize"; } </ins> } // panic_cases! }

Discussion:
These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)
Change:
let b_offset = a_size.align_to(b.align(self).abi); assert!(b_offset.bytes() > 0); // we later use the offset to tell apart the fields let b_ptr = ptr.offset(b_offset, self)?; <del> let a_val = self.memory.get_raw(ptr.alloc_id)?.read_scalar(self, a_ptr, a_size)?; let b_val = self.memory.get_raw(ptr.alloc_id)?.read_scalar(self, b_ptr, b_size)?; </del> <ins> let a_val = alloc.read_scalar(self, a_ptr, a_size)?; let b_val = alloc.read_scalar(self, b_ptr, b_size)?; </ins> Ok(Some(ImmTy { imm: Immediate::ScalarPair(a_val, b_val), layout: mplace.layout })) } _ => Ok(None),

Discussion:
I tried this code: I expected the code to fail to compile with a cycle error. Instead, it compiled and ran,printing the value of . I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 ) versions. Trying this code in it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.
cc
narrowed to the following: Auto merge of - petrochenkov:builtout, r=eddyb Auto merge of - luca-barbieri:optimize-refcell-borrow, r=RalfJung Auto merge of - Centril:rollup-, r=Centril Auto merge of - petrochenkov:rpass, r=Centril Possibly ?
Weaponized soundness hole (using as a foundation): ==
cc
oopsie yeah... is probably where this started. But that is crucial to fix The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for : So there actually is a that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.
Assigning as and removing .
Change:
are called with the `Struct::method()` syntax, rather than the `ref.method()` syntax. # Closures So far, we've made lots of functions in Rust. But we've given them all names.

Discussion:
The explanation of argument patterns in closures is pretty dense. Maybe it could be explained better by comparing to a match statement. See
And also patterns
part of
So much of this has changed, both with , and with closures, that I don't know if this issue is still relevant. is it?
there are a family of potential problems that are flagged in the reddit discussion. Here are the ones that I can identify with a quick skim: The original poster did not see that the syntax within the closure's arguments was a pattern binding that performs a dereference of the input, The fact that the closure itself takes a reference as input might be obscured by the fact that the closure doesn't have an explicit type signature (at least, that was one of huon's theories in his comment), brson interpreted the discussion as a sign that drawing an analogy between and the arguments to a could be helpful. (But 's comment points out that the patterns for arguments need to be irrefutable, which is an important distinction and thus I am not 100% sure an analogy with will help.) I'm not sure if this particular ticket is actionable on its own. I would want to make sure that the guide covers the fact that means one thing in expression context (namely, "make a reference to the l-value ") and another thing in pattern context (namely, "dereference the input and bind the resulting value to "). We cannot put that into the "Variable bindings" section of the current guide, since that precedes the section on "Pointers", but maybe just make sure that there is a TODO in the "Pointers" section that ensures we cover the distinction between an expression and an pattern.
Cool. Agreed. Since I'm working on pointers right now, that's very timely! cc
I actually think I'm just going to make patterns their own section, after pointers. We haven't talked about anything more than just very basic usage, and at the very least deserves an explanation
that is probably best; there are a lot of subtle details in terms of the distinction between how l-values are handled versus r-values.
Change:
<del> error: expected token: `,` </del> <ins> error: expected one of `!`, `,`, or `::`, found `(` </ins> --> $DIR/issue-54516.rs:4:58 | LL |     println!("{}", std::mem:size_of::<BTreeMap<u32, u32>>()); <del> |                            -                             ^ expected `,` </del> <ins> |                            -                             ^ expected one of `!`, `,`, or `::` here </ins> |                            | |                            help: maybe write a path separator here: `::` |

Discussion:
See The macro claims that it expects when failing to parse a format string argument, but it actually accepts all tokens that make up expressions in that position. The simplest fix would be to use , but that causes parsing errors directly after the format string to claim that expression tokens are expected in that position are accepted, when they are not. In other words, it would be nice to get diagnostics like this: while avoiding getting diagnostics like this:
Change:
<del> // ignore-test // FIXME(const_generics): This test causes an ICE after reverting #76030. #![feature(adt_const_params)] #![allow(incomplete_features)] struct Bug<const S: &'static str>; fn main() { let b: Bug::<{ unsafe { // FIXME(adt_const_params): Decide on how to deal with invalid values as const params. std::mem::transmute::<&[u8], &str>(&[0xC0, 0xC1, 0xF5]) } }>; } </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. --code from <!-- 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
Heh, I guess wasn't fixed after all. I wonder when it regressed.
That label is for , I do not think it is the right one here.
cargo bisect rustc says this regressed in Perhaps ?
Untagging as a regression, this requires nightly (const generics).
The bug no longer needs the to trigger.
Change:
<ins> error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/issue-85945-check-where-clause-before-suggesting-unsized.rs:4:16 | LL | fn bar() { foo(""); } |            --- ^^ doesn't have a size known at compile-time |            | |            required by a bound introduced by this call | = help: the trait `Sized` is not implemented for `str` note: required by a bound in `foo` --> $DIR/issue-85945-check-where-clause-before-suggesting-unsized.rs:3:8 | LL | fn foo<T>(_: &T) where T: Sized {} |        ^ required by this bound in `foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Given the following code: The current output is: Ideally, the diagnostic shouldn't suggest relaxing an explicit bound in the where clause. (There is already code that skips the suggestion for type parameters that have an explicit bound.) I can work on this in an in-progress pull request where I'm making other improvements to unsized suggestions. claim label +A-traits +A-typesystem +D-papercut <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Change:
llvm_sha = subprocess.check_output([ "git", "log", "--author=bors", "--format=%H", "-n1", "-m", "--first-parent", <del> "--", "src/llvm-project" </del> <ins> "--", "src/llvm-project", "src/bootstrap/download-ci-llvm-stamp", </ins> ]).decode(sys.getdefaultencoding()).strip() llvm_assertions = self.get_toml('assertions', 'llvm') == 'true' if self.program_out_of_date(self.llvm_stamp(), llvm_sha + str(llvm_assertions)):

Discussion:
I recently to in my local repository. In particular, this enables: When running the full test suite with I get three errors similar to this: Maybe the packaging of LLVM downloaded from CI needs to be fixed to include ?
Cc since you're the one who implemented this :)
Yes, that seems right. I did not know we relied on the LLVM tooling -- probably there's a few more tools we need too, will need to check. I imagine it's mostly a matter of just adding them to this section: , they should already be built. I would be happy to take a PR for this.
I can make a patch adding a couple lines for like the ones there for , but can I test it without landing it and waiting for the next Nightly? (I assume testing locally involves compiling LLVM, so I might wait to do that until I have access again to a many-cores desktop rather than just my laptop.)
Hm, sort of. So you will need to post a PR, but then bors try will generate sufficient artifacts to test. You will want to replace with the sha of the try build that bors posts.
might also be necessary but I'm not sure.
I’ll find out! I’ve already started a try build with just : I can temporarily hard-code in for the purpose of testing, but for everyone else the logic is still picking the last commit that touched the submodule, which after lands will still be some commit that does not include Would it make sense to have a "timestamp-ish" file, and pick the last commit that touched either the submodule or that file? That would only be useful until the next LLVM update, though. (Unless we need to tweak thepackaging of the component again.)