jiebi/CodeConvo huggingface dataset:
Code change:
Nobody responded to , and the rabbit hole has only gotten deeper and deeper since I've started trying to work around this . It's time for an issue. Here's a simple pattern macro: Trouble is, suppose somebody writes . Then they'll get this: Here is the simplest alternative I can come up with for working around this warning in this simple macro. Notice how proper support for and requires that the macro output uses shorthand field syntax, as opposed to a more scalable workaround like (where the is at least something that could be produced by a helper macro). A similar pattern macro for a struct with two fields basically requires an incremental muncher now, just to avoid the exponential blowup of rules. This is an awful lot of headache just for a little reminder to write more idiomatic code! Isn't that clippy's job, anyhow?
A crude fix would be to just not trigger this lint in macro expansions (at the cost of missing out on linting macro code where the offending non-shorthand pattern doesn't come as an argument, which, ideally, should be linted):

Related discussion:
text: <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. #![deny(non_shorthand_field_patterns)] pub struct Value<A> { pub value: A } #[macro_export] macro_rules! pat { ($a:pat) => { Value { value: $a } }; } fn main() { let pat!(value) = Value { value: () }; } </ins>
Code change:
I have a Rust written using the msp430 backend. which means using the nightly compiler. Travis CI daily cron builds have been with the nightly compiler since March 27, 2018 with the following error (I am currently not in a position to get a backtrace/increase verbosity, I will update when possible): My msp430 firmware uses to create a for msp430 every time is updated, and recently a new feature has triggered a lint that causes compilation to fail due to an unused macro. Since can't be compiled, the whole build fails. A stopgap solution for now is to use a nightly before March 27, 2018 which compiles for msp430 successfully. cc: based on a in with PR might have tickled the lint into failing compilation for the msp430 backend?
This macro is conditionally used in code that depends on the target’s pointer width. I suspect that this error happens on any 16-bit platform. Adding to the macro’s definition should fix it. Would you send a PR and ping me for review? (As an aside, we should probably have CI on rust-lang/rust that libcore at least compiles for one 16-bit platform.)
Looking at 's fix I guess my q is: why don't 16 bit targets (msp430/avr) need this macro at all?
has some background on the removal of conversions for some combinations of integer types. Here we have a private trait with a generic impl based on and some concrete impls to "restore" missing conversions. The implementation of those concrete conversion depends on the size of : we either check that the source value isn’t too large for the target type, or check nothing at all because the target type covers all values of the source type. When is 16-bits, the minimum, only the latter kind of conversion is used.

Related discussion:
text: } // unsigned to signed (only positive bound) <ins> #[cfg(any(target_pointer_width = "32", target_pointer_width = "64"))] </ins> macro_rules! try_from_upper_bounded { ($($target:ty),*) => {$( impl PrivateTryFromUsize for $target {
Code change:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

Related discussion:
text: // all span information. // // As a result, some AST nodes are annotated with the token <del> // stream they came from. Attempt to extract these lossless // token streams before we fall back to the stringification. </del> <ins> // stream they came from. Here we attempt to extract these // lossless token streams before we fall back to the // stringification. // // During early phases of the compiler, though, the AST could // get modified directly (e.g. attributes added or removed) and // the internal cache of tokens my not be invalidated or // updated. Consequently if the "lossless" token stream // disagrees with our actuall stringification (which has // historically been much more battle-tested) then we go with // the lossy stream anyway (losing span information). </ins> let mut tokens = None; match nt.0 {
Code change:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

Related discussion:
text: _ => {} } <del> tokens.unwrap_or_else(|| { nt.1.force(|| { // FIXME(jseyfried): Avoid this pretty-print + reparse hack let source = pprust::token_to_string(self); parse_stream_from_source_str(FileName::MacroExpansion, source, sess, Some(span)) }) }) </del> <ins> let tokens_for_real = nt.1.force(|| { // FIXME(#43081): Avoid this pretty-print + reparse hack let source = pprust::token_to_string(self); parse_stream_from_source_str(FileName::MacroExpansion, source, sess, Some(span)) }); if let Some(tokens) = tokens { if tokens.eq_unspanned(&tokens_for_real) { return tokens } } return tokens_for_real </ins> } }
Code change:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

Related discussion:
text: (&TokenTree::Token(_, ref tk), &TokenTree::Token(_, ref tk2)) => tk == tk2, (&TokenTree::Delimited(_, ref dl), &TokenTree::Delimited(_, ref dl2)) => { dl.delim == dl2.delim && <del> dl.stream().trees().zip(dl2.stream().trees()).all(|(tt, tt2)| tt.eq_unspanned(&tt2)) </del> <ins> dl.stream().eq_unspanned(&dl2.stream()) </ins> } (_, _) => false, }
Code change:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

Related discussion:
text: /// Compares two TokenStreams, checking equality without regarding span information. pub fn eq_unspanned(&self, other: &TokenStream) -> bool { <del> for (t1, t2) in self.trees().zip(other.trees()) { </del> <ins> let mut t1 = self.trees(); let mut t2 = other.trees(); for (t1, t2) in t1.by_ref().zip(t2.by_ref()) { </ins> if !t1.eq_unspanned(&t2) { return false; } } <del> true </del> <ins> t1.next().is_none() && t2.next().is_none() </ins> } /// Precondition: `self` consists of a single token tree.
Code change:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

Related discussion:
text: <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. // no-prefer-dynamic #![crate_type = "proc-macro"] #![feature(proc_macro)] extern crate proc_macro; use proc_macro::*; #[proc_macro_attribute] pub fn assert1(_a: TokenStream, b: TokenStream) -> TokenStream { assert_eq(b.clone(), "pub fn foo() {}".parse().unwrap()); b } #[proc_macro_derive(Foo, attributes(foo))] pub fn assert2(a: TokenStream) -> TokenStream { assert_eq(a, "pub struct MyStructc { _a: i32, }".parse().unwrap()); TokenStream::empty() } fn assert_eq(a: TokenStream, b: TokenStream) { let mut a = a.into_iter(); let mut b = b.into_iter(); for (a, b) in a.by_ref().zip(&mut b) { match (a, b) { (TokenTree::Group(a), TokenTree::Group(b)) => { assert_eq!(a.delimiter(), b.delimiter()); assert_eq(a.stream(), b.stream()); } (TokenTree::Op(a), TokenTree::Op(b)) => { assert_eq!(a.op(), b.op()); assert_eq!(a.spacing(), b.spacing()); } (TokenTree::Literal(a), TokenTree::Literal(b)) => { assert_eq!(a.to_string(), b.to_string()); } (TokenTree::Term(a), TokenTree::Term(b)) => { assert_eq!(a.to_string(), b.to_string()); } (a, b) => panic!("{:?} != {:?}", a, b), } } assert!(a.next().is_none()); assert!(b.next().is_none()); } </ins>
Code change:
Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc

Related discussion:
text: <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. // aux-build:modify-ast.rs #![feature(proc_macro)] extern crate modify_ast; use modify_ast::*; #[derive(Foo)] pub struct MyStructc { #[cfg_attr(my_cfg, foo)] _a: i32, } macro_rules! a { ($i:item) => ($i) } a! { #[assert1] pub fn foo() {} } fn main() { let _a = MyStructc { _a: 0 }; foo(); } </ins>
Code change:
Caught while fleshing out a much beefier test suite for SliceIndex, which I plan to submit as a PR. (this Issue is here just in case that PR never happens). The unicode character boundary check here should be looking at . Better yet, the method could just delegate to instead. (note: it can't delegate to here without NLL, which seems to be a leading factor as to how this function ended up this way)
Not technically a regression but tagging it as such to ensure that we don't forget about it.
my commit message accidentally closed this, which might defeat the purpose of the tag you (note: I myself can't reopen it because Github attributed the message to Bors)
Oh that's ok, the tags on the PR take over now for backporting and that's how we'll track this.
(ahhhh, now I see. The tag is used in automation for a Github Project to track regressions. That's actually pretty cool!) ('t mind me, just talking to myself)

Related discussion:
text: } #[test] <ins> fn test_str_slice_rangetoinclusive_ok() { let s = "abcαβγ"; assert_eq!(&s[..=2], "abc"); assert_eq!(&s[..=4], "abcα"); } #[test] #[should_panic] fn test_str_slice_rangetoinclusive_notok() { let s = "abcαβγ"; &s[..=3]; } #[test] fn test_str_slicemut_rangetoinclusive_ok() { let mut s = "abcαβγ".to_owned(); let s: &mut str = &mut s; assert_eq!(&mut s[..=2], "abc"); assert_eq!(&mut s[..=4], "abcα"); } #[test] #[should_panic] fn test_str_slicemut_rangetoinclusive_notok() { let mut s = "abcαβγ".to_owned(); let s: &mut str = &mut s; &mut s[..=3]; } #[test] </ins> fn test_is_char_boundary() { let s = "ศไทย中华Việt Nam β-release 🐱123"; assert!(s.is_char_boundary(0));
Code change:
Caught while fleshing out a much beefier test suite for SliceIndex, which I plan to submit as a PR. (this Issue is here just in case that PR never happens). The unicode character boundary check here should be looking at . Better yet, the method could just delegate to instead. (note: it can't delegate to here without NLL, which seems to be a leading factor as to how this function ended up this way)
Not technically a regression but tagging it as such to ensure that we don't forget about it.
my commit message accidentally closed this, which might defeat the purpose of the tag you (note: I myself can't reopen it because Github attributed the message to Bors)
Oh that's ok, the tags on the PR take over now for backporting and that's how we'll track this.
(ahhhh, now I see. The tag is used in automation for a Github Project to track regressions. That's actually pretty cool!) ('t mind me, just talking to myself)

Related discussion:
text: fn index(self, slice: &str) -> &Self::Output { assert!(self.end != usize::max_value(), "attempted to index str up to maximum usize"); <del> let end = self.end + 1; self.get(slice).unwrap_or_else(|| super::slice_error_fail(slice, 0, end)) </del> <ins> (..self.end+1).index(slice) </ins> } #[inline] fn index_mut(self, slice: &mut str) -> &mut Self::Output { assert!(self.end != usize::max_value(), "attempted to index str up to maximum usize"); <del> if slice.is_char_boundary(self.end) { unsafe { self.get_unchecked_mut(slice) } } else { super::slice_error_fail(slice, 0, self.end + 1) } </del> <ins> (..self.end+1).index_mut(slice) </ins> } }
Code change:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

Related discussion:
text: continue; } <del> let result = select.select(&Obligation::new(dummy_cause.clone(), new_env, pred)); </del> <ins> // Call infcx.resolve_type_vars_if_possible to see if we can // get rid of any inference variables. let obligation = infcx.resolve_type_vars_if_possible( &Obligation::new(dummy_cause.clone(), new_env, pred) ); let result = select.select(&obligation); </ins> match &result { &Ok(Some(ref vtable)) => {
Code change:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

Related discussion:
text: } &Ok(None) => {} &Err(SelectionError::Unimplemented) => { <del> if self.is_of_param(pred.skip_binder().trait_ref.substs) { </del> <ins> if self.is_param_no_infer(pred.skip_binder().trait_ref.substs) { </ins> already_visited.remove(&pred); self.add_user_pred( &mut user_computed_preds,
Code change:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

Related discussion:
text: finished_map } <del> pub fn is_of_param(&self, substs: &Substs<'_>) -> bool { if substs.is_noop() { return false; } </del> <ins> fn is_param_no_infer(&self, substs: &Substs<'_>) -> bool { return self.is_of_param(substs.type_at(0)) && !substs.types().any(|t| t.has_infer_types()); } </ins> <del> return match substs.type_at(0).sty { </del> <ins> pub fn is_of_param(&self, ty: Ty<'_>) -> bool { return match ty.sty { </ins> ty::Param(_) => true, <del> ty::Projection(p) => self.is_of_param(p.substs), </del> <ins> ty::Projection(p) => self.is_of_param(p.self_ty()), </ins> _ => false, }; } <ins> fn is_self_referential_projection(&self, p: ty::PolyProjectionPredicate<'_>) -> bool { match p.ty().skip_binder().sty { ty::Projection(proj) if proj == p.skip_binder().projection_ty => { true }, _ => false } } </ins> pub fn evaluate_nested_obligations< 'b, 'c,
Code change:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

Related discussion:
text: <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. pub trait Signal { type Item; } pub trait Signal2 { type Item2; } impl<B, C> Signal2 for B where B: Signal<Item = C> { type Item2 = C; } // @has issue_50159/struct.Switch.html // @has - '//code' 'impl<B> Send for Switch<B> where <B as Signal>::Item: Send' // @has - '//code' 'impl<B> Sync for Switch<B> where <B as Signal>::Item: Sync' // @count - '//*[@id="implementations-list"]/*[@class="impl"]' 0 // @count - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]' 2 pub struct Switch<B: Signal> { pub inner: <B as Signal2>::Item2, } </ins>
Code change:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.

Related discussion:
text: <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. // Some unusual code minimized from // https://github.com/sile/handy_async/tree/7b619b762c06544fc67792c8ff8ebc24a88fdb98 pub trait Pattern { type Value; } pub struct Constrain<A, B = A, C = A>(A, B, C); impl<A, B, C> Pattern for Constrain<A, B, C> where A: Pattern, B: Pattern<Value = A::Value>, C: Pattern<Value = A::Value>, { type Value = A::Value; } pub struct Wrapper<T>(T); impl<T> Pattern for Wrapper<T> { type Value = T; } // @has self_referential/struct.WriteAndThen.html // @has - '//*[@id="synthetic-implementations-list"]/*[@class="impl"]//*/code' "impl<P1> Send for  // WriteAndThen<P1>  where  <P1 as Pattern>::Value: Send" pub struct WriteAndThen<P1>(pub P1::Value,pub <Constrain<P1, Wrapper<P1::Value>> as Pattern>::Value) where P1: Pattern; </ins>
Code change:
I came across . This is a "safe" feature of rust I didn't know about. I was at first confused about the docs for however. My main confusion was around the "deinitializing" word which made me think that is not consumed. It is consumed but it is not dropped, which is a subtle distinction. I propose here to remove the confusing language. Suggested new docs: Another possible option (I don't like it as much but it is more similar to the previous docs): As a side note, I have not seen the "deinitialized" qualifier in rust before. I don't think it is part of the standard rust lingo which is probably some of my confusion :smile:
Another option, which I think is the best of both worlds: The important points are to mention that is moved, and to use standard terminology rather than "deinitialized".
I like the third option the most:
I have to say I like yours the best. Maybe change "Moves behind the mutable reference" to "Moves into the mutable reference"? I'm not sure "behind" is standard lingo either :smile:
opened a pr

Related discussion:
text: } } <del> /// Replaces the value at a mutable location with a new one, returning the old value, without /// deinitializing either one. </del> <ins> /// Moves `src` into the referenced `dest`, returning the previous `dest` value. /// /// Neither value is dropped. </ins> /// /// # Examples ///
Code change:
I came across . This is a "safe" feature of rust I didn't know about. I was at first confused about the docs for however. My main confusion was around the "deinitializing" word which made me think that is not consumed. It is consumed but it is not dropped, which is a subtle distinction. I propose here to remove the confusing language. Suggested new docs: Another possible option (I don't like it as much but it is more similar to the previous docs): As a side note, I have not seen the "deinitialized" qualifier in rust before. I don't think it is part of the standard rust lingo which is probably some of my confusion :smile:
Another option, which I think is the best of both worlds: The important points are to mention that is moved, and to use standard terminology rather than "deinitialized".
I like the third option the most:
I have to say I like yours the best. Maybe change "Moves behind the mutable reference" to "Moves into the mutable reference"? I'm not sure "behind" is standard lingo either :smile:
opened a pr

Related discussion:
text: } } <del> /// Replaces the value at `dest` with `src`, returning the old /// value, without dropping either. </del> <ins> /// Moves `src` into the pointed `dest`, returning the previous `dest` value. /// /// Neither value is dropped. </ins> /// /// # Safety ///