jiebi/CodeConvo huggingface dataset:
Change:
The following macro won't work without the extra set of parens: Here's an example use: I'd like to remove those extra parens. It seems like [ field:ident),* ] should be unambiguous, but rustc doesn't like it. The actual error is . Also, it seems like it should tell me the other options so I have some clue what is going wrong.
Nominating for milestone 1, well-defined (part of figuring out what macros actually parse)
Related to which has to do with the implementation of parsing being able to stop / reset / restart. But I want to have some bug on file for well-definedness that says which grammar-class of macros we support. The current macro tutorial at has a little discussion of it, but is not entirely clear. I believe the class is "1-token predictive grammars" which is the non-backtracking subset of LL(1), quite limited. It's fine if that's our limitation -- it's still much more than in other languages -- but we ought to say so. (We discussed this in the nomination meeting today when we hit and decided to accept "some bug" for the well-definedness of the macro parser, and leave on the problem of its implementation)
Triage: still an issue. Specifically, the following fails FWIW, the example in the issue is one of many working versions, e.g. also works (called like: ).

Discussion:
sp_lo: sp.lo }); } <del> MatchNonterminal(_,_,_) => { bb_eis.push(ei) } </del> <ins> MatchNonterminal(_,_,_) => { // Built-in nonterminals never start with these tokens, // so we can eliminate them from consideration. match tok { token::RPAREN | token::RBRACE | token::RBRACKET => {}, _ => bb_eis.push(ei) } } </ins> MatchTok(ref t) => { let mut ei_t = ei.clone(); if token_name_eq(t,&tok) {

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(macro_rules)] macro_rules! list ( ( ($($id:ident),*) ) => (()); ( [$($id:ident),*] ) => (()); ( {$($id:ident),*} ) => (()); ) macro_rules! tt_list ( ( ($($tt:tt),*) ) => (()); ) pub fn main() { list!( () ); list!( [] ); list!( {} ); tt_list!( (a, b, c) ); tt_list!( () ); } </ins>
Change:
Using the syntax does not work as a generic to an impl Trait in return position. Error As a parameter it does work: This issue looks related, but specifically calls out type equality constraints.
cc is this a lazy-norm issue?
This was fixed by , which includes tests, so maybe this should just be closed?
Closing per comment

Discussion:
<ins> // check-pass trait A { type Foo; } impl<T> A for T { type Foo = (); } fn foo() -> impl std::borrow::Borrow<<u8 as A>::Foo> { () } fn main() { foo(); } </ins>
Change:
Tracking issue for making on stable: ,
FYI, in Rust issue tracker, "tracking issue" is a jargon for stabilizing features already in nightly. As I understand, is not yet in nightly?
A tracking issue has to be opened before a feature can land in nightly, because the attribute needs an issue number to refer to. has also been approved already, so it'll land in one of the next nightlies.
How about moving this to stable?
What's left to do to stabilize this feature? Any ETA?
Can this be stablised for 1.37?
Another reminder -- can we kick off FCP for stabilization?
any updates?
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

Discussion:
/// # Examples /// /// ```no_run <del> /// #![feature(udp_peer_addr)] </del> /// use std::net::{Ipv4Addr, SocketAddr, SocketAddrV4, UdpSocket}; /// /// let socket = UdpSocket::bind("127.0.0.1:34254").expect("couldn't bind to address");

/// [`NotConnected`]: ../../std/io/enum.ErrorKind.html#variant.NotConnected /// /// ```no_run <del> /// #![feature(udp_peer_addr)] </del> /// use std::net::UdpSocket; /// /// let socket = UdpSocket::bind("127.0.0.1:34254").expect("couldn't bind to address"); /// assert_eq!(socket.peer_addr().unwrap_err().kind(), ///            ::std::io::ErrorKind::NotConnected); /// ``` <del> #[unstable(feature = "udp_peer_addr", issue = "59127")] </del> <ins> #[stable(feature = "udp_peer_addr", since = "1.40.0")] </ins> pub fn peer_addr(&self) -> io::Result<SocketAddr> { self.0.peer_addr() }
Change:
While working around which was caused by minification, we have discovered that the resulting non-minified docs have a broken search index (), and the resulting docs are limited to the single toplevel crate from the chosen manifest directory.

Discussion:
// with rustdoc running in parallel. all_indexes.sort(); let mut w = try_err!(File::create(&dst), &dst); <del> if options.enable_minification { try_err!(writeln!(&mut w, "var N=null,E="",T="t",U="u",searchIndex={{}};"), &dst); } else { try_err!(writeln!(&mut w, "var searchIndex={{}};"), &dst); } </del> <ins> try_err!(writeln!(&mut w, "var N=null,E="",T="t",U="u",searchIndex={{}};"), &dst); </ins> try_err!(write_minify_replacer(&mut w, &format!("{}n{}", variables.join(""), all_indexes.join("n")), options.enable_minification),
Change:
Current handling of this feature goes through functions and . One or both of these functions should be removed. cc
NLL triage: prioritizing as P-medium.

Discussion:
self.queries.on_disk_cache.serialize(self.global_tcx(), encoder) } <del> /// This checks whether one is allowed to have pattern bindings /// that bind-by-move on a match arm that has a guard, e.g.: /// /// ```rust /// match foo { A(inner) if { /* something */ } => ..., ... } /// ``` /// /// It is separate from check_for_mutation_in_guard_via_ast_walk, /// because that method has a narrower effect that can be toggled /// off via a separate `-Z` flag, at least for the short term. pub fn allow_bind_by_move_patterns_with_guards(self) -> bool { self.features().bind_by_move_pattern_guards } /// If true, we should use a naive AST walk to determine if match /// guard could perform bad mutations (or mutable-borrows). pub fn check_for_mutation_in_guard_via_ast_walk(self) -> bool { !self.allow_bind_by_move_patterns_with_guards() } </del> /// If true, we should use the AST-based borrowck (we may *also* use /// the MIR-based borrowck). pub fn use_ast_borrowck(self) -> bool {

// Second, if there is a guard on each arm, make sure it isn't // assigning or borrowing anything mutably. if let Some(ref guard) = arm.guard { <del> if self.tcx.check_for_mutation_in_guard_via_ast_walk() { </del> <ins> if !self.tcx.features().bind_by_move_pattern_guards { </ins> check_for_mutation_in_guard(self, &guard); } }

"cannot bind by-move with sub-bindings") .span_label(p.span, "binds an already bound by-move value by moving it") .emit(); <del> } else if has_guard && !cx.tcx.allow_bind_by_move_patterns_with_guards() { </del> <ins> } else if has_guard && !cx.tcx.features().bind_by_move_pattern_guards { </ins> let mut err = struct_span_err!(cx.tcx.sess, p.span, E0008, "cannot bind by-move into a pattern guard"); err.span_label(p.span, "moves value into pattern guard");
Change:
We expect everyone to rebase instead of merge and we also try to have fixup commits squashed into previous related commits. I think we should document this policy, since it keeps suprising newcomers.
I can take care of this one as it's quite a fresh experience :).
I think we should only rebase when resolving merge conflict, or the review process has completed and reviewer request a rebasing. Otherwise I prefer adding new commits for easier reviewing.
I agree with that this policy is sound for actually merging the PR, but it might cause confusion for reviews. I've had a PR lying around for awhile, and when there is merge conflicts the 'waiting-on-author' label gets so noone reviews it, but when I do the rebasing to get back my 'waiting-on-review' it seems as if Github sometimes loses context of previous reviews, which can be quite confusing...
for the record: I personally want no rebasing and just merging, I'm just stating what the policy is.
Before we close this issue. Could we talk a bit about ? I think we should encourage contributors close issues by keywords in PR descriptions only. Because otherwise the commit could be rebased many times, and each time it creates a reference to the want-to-close issue. Also in the referenced issue, the commit number of the new commit that could close that issue is not really informative. The PR number itself appeared in the issue is more informative and concise. In short, we create another policy for closing issue.

Discussion:
Also, please make sure that fixup commits are squashed into other related commits with meaningful commit messages. <ins> GitHub allows [closing issues using keywords][closing-keywords]. This feature should be used to keep the issue tracker tidy. However, it is generally preferred to put the "closes #123" text in the PR description rather than the issue commit; particularly during rebasing, citing the issue number in the commit can "spam" the issue in question. [closing-keywords]: https://help.github.com/en/articles/closing-issues-using-keywords </ins> Please make sure your pull request is in compliance with Rust's style guidelines by running
Change:
The error happens on latest stable and nightly. Steps to reproduce: ; : : returns error: The error only happens if the module is named (for instance, and work without error). The error is not produced if doesn't use in any way. If doesn't contain imports but uses the library directly (e.g. ), the error is produced. always succeeds. I don't know if this is supposed to be forbidden but the error message seems to be misleading.
The second instance is injected implicitly. The error could be better, yes.
Where exactly is injected - in the library or in the test? Why does the library work on its own? Why does conflict with in the test?
Ok, it turns out this is a legitimate bug, I misinterpreted it as a more commonly reported diagnostic issue. is injected into both the library and the test, but only the first one causes the error. If you set in , then you'll see the error immediately while compiling - conflicts with . On 2018 edition, however, is injected in more subtle way, as where is some unique symbol that still has the string representation , but doesn't clash with anything in the same crate. Unfortunately, turns into "just " after encoding into metadata in the compiled library (this is the bug). So, when we load that library from the test it looks like the library defines two conflicting items.
The solution is to either encode gensyms/hygiene into metadata properly (this is a large task and a long standing issue), or come up with some hack preventing the injected specifically from being encoded (it doesn't really need to be encoded).
Fixed in

Discussion:
} // Empty groups `a::b::{}` are turned into synthetic `self` imports <del> // `a::b::c::{self as _}`, so that their prefixes are correctly </del> <ins> // `a::b::c::{self as __dummy}`, so that their prefixes are correctly </ins> // resolved and checked for privacy/stability/etc. if items.is_empty() && !empty_for_self(&prefix) { let new_span = prefix[prefix.len() - 1].ident.span;

Ident::new(keywords::SelfLower.name(), new_span) ), kind: ast::UseTreeKind::Simple( <del> Some(Ident::new(keywords::Underscore.name().gensymed(), new_span)), </del> <ins> Some(Ident::new(Name::gensym("__dummy"), new_span)), </ins> ast::DUMMY_NODE_ID, ast::DUMMY_NODE_ID, ),

None => continue, }; <del> // Filter away "empty import canaries" and ambiguous imports. </del> <ins> // Filter away ambiguous and gensymed imports. Gensymed imports // (e.g. implicitly injected `std`) cannot be properly encoded in metadata, // so they can cause name conflict errors downstream. </ins> let is_good_import = binding.is_import() && !binding.is_ambiguity() && <del> binding.vis != ty::Visibility::Invisible; </del> <ins> !(ident.name.is_gensymed() && ident.name != "_"); </ins> if is_good_import || binding.is_macro_def() { let def = binding.def(); if def != Def::Err {

with_interner(|interner| interner.gensymed(self)) } <ins> pub fn is_gensymed(self) -> bool { with_interner(|interner| interner.is_gensymed(self)) } </ins> pub fn as_str(self) -> LocalInternedString { with_interner(|interner| unsafe { LocalInternedString {

<ins> // compile-pass // edition:2018 // aux-build:gensymed.rs extern crate gensymed; fn main() {} </ins>
Change:
I was trying to find in rustdoc, but that doesn't show up anywhere if I just search for : It does show up if I search for () so there's a workaround, but I think it'd be nice if when I type an exact name, things with that exact name show up at the top, or something.
It's supposed to, so some adjustments need to be done on the "search engine". I'll take a look.

Discussion:
returned = checkReturned(ty, output, true); if (output.name === "*" || returned === true) { in_args = false; <del> var module = false; </del> <ins> var is_module = false; </ins> if (input === "*") { <del> module = true; </del> <ins> is_module = true; </ins> } else { var allFound = true; for (var it = 0; allFound === true && it < inputs.length; it++) {

dontValidate: true, }; } <del> if (module === true) { </del> <ins> if (is_module === true) { </ins> results[fullId] = { id: i, index: -1,

if (index !== -1 || lev <= MAX_LEV_DISTANCE) { if (index !== -1 && paths.length < 2) { lev = 0; <ins> } else if (searchWords[j] === val) { // Small trick to fix when you're looking for a one letter type // and there are other short named types. lev = -1; </ins> } if (results[fullId] === undefined) { results[fullId] = {

<ins> const QUERY = 'P'; const EXPECTED = { 'others': [ { 'path': 'search_short_types', 'name': 'P' }, { 'path': 'search_short_types', 'name': 'Ap' }, ], }; </ins>

<ins> macro_rules! imp { ($name:ident) => { pub struct $name { pub op: usize, } impl $name { pub fn op() {} pub fn cmp() {} pub fn map() {} pub fn pop() {} pub fn ptr() {} pub fn rpo() {} pub fn drop() {} pub fn copy() {} pub fn zip() {} pub fn sup() {} pub fn pa() {} pub fn pb() {} pub fn pc() {} pub fn pd() {} pub fn pe() {} pub fn pf() {} pub fn pg() {} pub fn ph() {} pub fn pi() {} pub fn pj() {} pub fn pk() {} pub fn pl() {} pub fn pm() {} pub fn pn() {} pub fn po() {} } }; ($name:ident, $($names:ident),*) => { imp!($name); imp!($($names),*); }; } macro_rules! en { ($name:ident) => { pub enum $name { Ptr, Rp, Rpo, Pt, Drop, Dr, Dro, Sup, Op, Cmp, Map, Mp, } }; ($name:ident, $($names:ident),*) => { en!($name); en!($($names),*); }; } imp!(Ot, Foo, Cmp, Map, Loc, Lac, Toc, Si, Sig, Sip, Psy, Psi, Py, Pi, Pa, Pb, Pc, Pd); imp!(Pe, Pf, Pg, Ph, Pj, Pk, Pl, Pm, Pn, Po, Pq, Pr, Ps, Pt, Pu, Pv, Pw, Px, Pz, Ap, Bp, Cp); imp!(Dp, Ep, Fp, Gp, Hp, Ip, Jp, Kp, Lp, Mp, Np, Op, Pp, Qp, Rp, Sp, Tp, Up, Vp, Wp, Xp, Yp, Zp); en!(Place, Plac, Plae, Plce, Pace, Scalar, Scalr, Scaar, Sclar, Salar); pub struct P; </ins>
Change:
This was found while building rustc 1.33.0 on . Test fails at the third test: The LLVM IR generated for this test case on and (respectively) is identical: The test appears to expect that the bitmask is interpreted as bitwise little-endian (in other words, the LSB selects the first element from the vectors). However, the implementation uses a bitcast to a vector of . On big-endian architectures such as powerpc64, the LSB becomes the last element of this vector, not the first. Unfortunately, all of the upstream test cases are symmetrical, so "choosing the wrong vector" and "reading the bitmask backwards" are indistinguishable. I an additional test case: This passes on , but fails on with: The two "unlike" elements were chosen from the wrong place in the vector. Since the vectors are 256 bits, and the POWER VSX registers are only 128 bits wide, LLVM must split each vector across two registers. The following powerpc64 assembly is from the last test case (), and clearly shows that LLVM (not the hardware) picks the first half of and the second half of : So is this a bug in the test, because it should be ensuring that the bitmask is in native vector/endian order? Or in the implementation of , because it should always take a little-endian bitmask and reverse the bits as necessary?
From it looks like that the bitcast is the intended semantics, so that would mean the test is invalid on big-endian targets. Thoughts, ?
This, we should only enable the test for little endian platforms, maybe adding a new test for big endian platforms.

Discussion:
#![allow(non_camel_case_types)] // ignore-emscripten <ins> // ignore-mips       behavior of simd_select_bitmask is endian-specific // ignore-mips64     behavior of simd_select_bitmask is endian-specific // ignore-powerpc    behavior of simd_select_bitmask is endian-specific // ignore-powerpc64  behavior of simd_select_bitmask is endian-specific </ins> // Test that the simd_select intrinsics produces correct results.
Change:
I got this pretty weird ICE while in the middle of a refactor. I don't know how to turn this into a minimal example, so here's the offending code that reproduces this error:
What version of the compiler are you using?

Discussion:
match self.at(&self.misc(span), self.param_env).sup(impl_ty, self_ty) { Ok(ok) => self.register_infer_ok_obligations(ok), Err(_) => { <del> span_bug!(span, </del> <ins> self.tcx.sess.delay_span_bug(span, &format!( </ins> "instantiate_value_path: (UFCS) {:?} was a subtype of {:?} but now is not?", self_ty, <del> impl_ty); </del> <ins> impl_ty, )); </ins> } } }

<ins> pub mod test { pub struct A; pub struct B; pub struct Foo<T>(T); impl Foo<A> { fn foo() {} } impl Foo<B> { fn foo() {} } } fn main() { test::Foo::<test::B>::foo(); //~ ERROR method `foo` is private } </ins>

<ins> error[E0624]: method `foo` is private --> $DIR/issue-53498.rs:16:5 | LL |     test::Foo::<test::B>::foo(); |     ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0624`. </ins>
Change:
This is a tracking issue for the feature gate, tracking the stabilization of the bittest Intel intrinsics - see .
I think it'd be reasonable to stabilize these at this point. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [ ] [x] [x] [x] [x] [ ] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

Discussion:
<del> Subproject commit 1e05dffbeeb80ba61bf59cc63b222d538d7825ed </del> <ins> Subproject commit 3001c75a1d2a81d2a76bef139c69387cb2ebb820 </ins>
Change:
Here it is: I believe that the line here is incorrect "Some of these affect the output of the compiler, while others affect programs which link to the standard library." since I believe none of these variables affect the output of the compiler. Why is this a problem? Well, the logical reader might say to themselves: " "Some" means at least 1. It makes very little sense for the top three to affect the output of the compiler. Therefore it must be the bottom one, RUST_BACKTRACE, which affects the output of the compiler."
I think "the output" should just be removed here - applies to both rustc and binaries produced by it, for example.
First, I do agree the phrase "the output of the compiler" is suboptimal, since it can be taken to mean the diagnostics emitted to stdout or other files it generates, while the original intent here (I think) is for the word "output" to denote the behavior of the binary generated by the compiler. Second, while saying "Some of these affect the compiler, ..." would be technically correct, I think it would be misleading. In particular, I personally would read the phase " affects the compiler", at least initially, as meaning that the environment variable only matters during execution of the compiler itself, which is the opposite of what we want to convey. How about: all programs which link to the Rust standard library. (I'm actually not particularly wedded to that second sentence. I would not mind if it were omitted.)
Thanks, Now that you point it out I realize that the problem with the problematic statement is not that it is wrong, so much as that it is entirely ambiguous and that when reading it it is easy to choose the wrong, that is unintended, meaning. Your suggested wording works for me.
I think the extra note on the end is likely to make things more confusing. So keeping it to only the first part of your suggestion is the best I think!: If you want I could create a PR for this?
I'ld be fine w/ that wording as well.
I created a PR for you !

Discussion:
.SH ENVIRONMENT <del> Some of these affect the output of the compiler, while others affect programs which link to the standard library. </del> <ins> Some of these affect only test harness programs (generated via rustc --test); others affect all programs which link to the Rust standard library. </ins> .TP fBRUST_TEST_THREADSfR