jiebi/CodeConvo huggingface dataset:
Change:
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:

Discussion:
} let fmtstr = p.parse_expr()?; <ins> let mut first = true; </ins> let mut named = false; while p.token != token::Eof { if !p.eat(&token::Comma) { <del> let mut err = ecx.struct_span_err(p.token.span, "expected token: `,`"); err.span_label(p.token.span, "expected `,`"); p.maybe_annotate_with_ascription(&mut err, false); return Err(err); </del> <ins> if first { // After `format!(""` we always expect *only* a comma... let mut err = ecx.struct_span_err(p.token.span, "expected token: `,`"); err.span_label(p.token.span, "expected `,`"); p.maybe_annotate_with_ascription(&mut err, false); return Err(err); } else { // ...after that delegate to `expect` to also include the other expected tokens. return Err(p.expect(&token::Comma).err().unwrap()); } </ins> } <ins> first = false; </ins> if p.token == token::Eof { break; } // accept trailing commas

fn main() { format!(); //~ ERROR requires at least a format string argument format!("" 1); //~ ERROR expected token: `,` <del> format!("", 1 1); //~ ERROR expected token: `,` </del> <ins> format!("", 1 1); //~ ERROR expected one of </ins> }

LL |     format!("" 1); |                ^ expected `,` <del> error: expected token: `,` </del> <ins> error: expected one of `,`, `.`, `?`, or an operator, found `1` </ins> --> $DIR/bad-format-args.rs:4:19 | LL |     format!("", 1 1); <del> |                   ^ expected `,` </del> <ins> |                   ^ expected one of `,`, `.`, `?`, or an operator here </ins> error: aborting due to 3 previous errors

fn main() { println!("{}", std::mem:size_of::<BTreeMap<u32, u32>>()); <del> //~^ ERROR expected token: `,` </del> <ins> //~^ ERROR expected one of </ins> }

<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: `::` |
Change:
The code below yields two errors: field is private error in if expression because type is instead of This means a user can observe the type of a private field of a dependency in their error messages. It doesn't mean they can actually use that information, but it seems weird at least. Is this actually an issue? If you don't consider it one, feel free to close this. - - (originally seen )
I won't close the ticket as this deserves a conversation to be had, but I personally don't consider it to be a big problem. Parsing x.len as when we suggest that would be nice, but in this case it would lead to confusing errors if we don't annotate the compiler state with something along the lines of
Hi Do any of you have opinions on this matter? I lean towards closing as "wontfix" because I feel the current behavior is acceptable.
I agree, like you mentioned , there are some improvements we could make, but I think the current behaviour is fine.

Discussion:
self.tcx.check_stability(field.did, Some(expr.hir_id), expr.span, None); return field_ty; } <del> private_candidate = Some((adjustments, base_def.did(), field_ty)); </del> <ins> private_candidate = Some((adjustments, base_def.did())); </ins> } } ty::Tuple(tys) => {

} self.structurally_resolved_type(autoderef.span(), autoderef.final_ty(false)); <del> if let Some((adjustments, did, field_ty)) = private_candidate { </del> <ins> if let Some((adjustments, did)) = private_candidate { </ins> // (#90483) apply adjustments to avoid ExprUseVisitor from // creating erroneous projection. self.apply_adjustments(base, adjustments); self.ban_private_field_access(expr, base_ty, field, did); <del> return field_ty; </del> <ins> return self.tcx().ty_error(); </ins> } if field.name == kw::Empty {

fn main() { let item = stuff::Item::new(); println!("{}", check_ptr_exist!(item, name)); <del> //~^ ERROR field `name` of struct `CObj` is private </del> }

| = note: this error originates in the macro `check_ptr_exist` (in Nightly builds, run with -Z macro-backtrace for more info) <del> error[E0616]: field `name` of struct `CObj` is private --> $DIR/issue-25386.rs:26:43 | LL |     println!("{}", check_ptr_exist!(item, name)); |                                           ^^^^ private field error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins> For more information about this error, try `rustc --explain E0616`.

<ins> fn main() { let x = foo::Foo::default(); if x.len { //~^ ERROR field `len` of struct `Foo` is private println!("foo"); } } mod foo { #[derive(Default)] pub struct Foo { len: String, } impl Foo { pub fn len(&self) -> usize { 42 } } } </ins>

<ins> error[E0616]: field `len` of struct `Foo` is private --> $DIR/private-field-ty-err.rs:3:10 | LL |     if x.len { |          ^^^ private field | help: a method `len` also exists, call it with parentheses | LL |     if x.len() { |             ++ error: aborting due to previous error For more information about this error, try `rustc --explain E0616`. </ins>
Change:
Issue had to do with inference failures around reborrowed pointers, but I neglected to handle reborrowed slices. As a result, tests like this: fail to compile. I have a patch coming soon.

Discussion:
///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }

!preds.is_empty() && { let ty_empty_region = cx.tcx.mk_imm_ref(cx.tcx.lifetimes.re_root_empty, ty); preds.iter().all(|t| { <del> let ty_params = &t.skip_binder().trait_ref.substs.iter().skip(1).collect::<Vec<_>>(); </del> <ins> let ty_params = &t .skip_binder() .trait_ref .substs .iter() .skip(1) .collect::<Vec<_>>(); </ins> implements_trait(cx, ty_empty_region, t.def_id(), ty_params) }) },

/// /// **Example:** /// ```rust <del> /// // Bad </del> /// println!(""); <del> /// /// // Good /// println!(); </del> /// ``` pub PRINTLN_EMPTY_STRING, style,

declare_clippy_lint! { /// **What it does:** This lint warns when you use `print!()` with a format <del> /// string that ends in a newline. </del> <ins> /// string that /// ends in a newline. </ins> /// /// **Why is this bad?** You should use `println!()` instead, which appends the /// newline.

/// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, ""); <del> /// /// // Good /// writeln!(buf); </del> /// ``` pub WRITELN_EMPTY_STRING, style,

/// # use std::fmt::Write; /// # let mut buf = String::new(); /// # let name = "World"; <del> /// /// // Bad </del> /// write!(buf, "Hello {}!n", name); <del> /// /// // Good /// writeln!(buf, "Hello {}!", name); </del> /// ``` pub WRITE_WITH_NEWLINE, style,

/// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, "{}", "foo"); <del> /// /// // Good /// writeln!(buf, "foo"); </del> /// ``` pub WRITE_LITERAL, style,

if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(

} fn run_ui_cargo(config: &mut compiletest::Config) { <ins> if cargo::is_rustc_test_suite() { return; } </ins> fn run_tests( config: &compiletest::Config, filter: &Option<String>,

<ins> #!/bin/sh CARGO_TARGET_DIR=$(pwd)/target/ export CARGO_TARGET_DIR echo 'Deprecated! `util/dev` usage is deprecated, please use `cargo dev` instead.' cd clippy_dev && cargo run -- "$@" </ins>
Change:
Reduced example
e
The first compilation error -- the example with looks fine to me. Types used for static variables must outlive the lifetime. The compiler can prove that outlives only if . Hence lifetimes are inferred in lieu of the anonymous lifetimes. Since your variable does not live for the whole lifetime, it cannot be used as you are trying to. Maybe the actual bug is that should desugar to , as it would be for ? It may be weird to special-case only the traits though -- i.e. if you define your own trait , then just means for some lifetime to be inferred by the compiler, it does not mean . Your reduced example is actually different since it actually does not involve static data. It seems to be the same bug as in , and hence is a bug with the feature. Going from to (note the tuple of size ) makes the ICE go away.
Fixed by

Discussion:
<ins> #![feature(unboxed_closures)] #![feature(fn_traits)] fn main() { let handlers: Option<Box<dyn for<'a> FnMut<&'a mut (), Output=()>>> = None; handlers.unwrap().as_mut().call_mut(&mut ()); //~ ERROR: `&mut ()` is not a tuple } </ins>

<ins> error[E0277]: `&mut ()` is not a tuple --> $DIR/issue-57404.rs:6:41 | LL |     handlers.unwrap().as_mut().call_mut(&mut ()); |                                -------- -^^^^^^ |                                |        | |                                |        the trait `Tuple` is not implemented for `&mut ()` |                                |        help: consider removing the leading `&`-reference |                                required by a bound introduced by this call | note: required by a bound in `call_mut` --> $SRC_DIR/core/src/ops/function.rs:LL:COL error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Change:
The following sample crashed rustc: Removing the , or unwrapping the (leaving only ), or replacing the predicate (leaving ), solves the crash. Reproduced on Windows 64-bit, Fedora 32-bit, Ubuntu 64-bit. Full crash log (thanks to ) @ Short crash message:
Fixed pending
Fixed in

Discussion:
///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }

!preds.is_empty() && { let ty_empty_region = cx.tcx.mk_imm_ref(cx.tcx.lifetimes.re_root_empty, ty); preds.iter().all(|t| { <del> let ty_params = &t.skip_binder().trait_ref.substs.iter().skip(1).collect::<Vec<_>>(); </del> <ins> let ty_params = &t .skip_binder() .trait_ref .substs .iter() .skip(1) .collect::<Vec<_>>(); </ins> implements_trait(cx, ty_empty_region, t.def_id(), ty_params) }) },

/// /// **Example:** /// ```rust <del> /// // Bad </del> /// println!(""); <del> /// /// // Good /// println!(); </del> /// ``` pub PRINTLN_EMPTY_STRING, style,

declare_clippy_lint! { /// **What it does:** This lint warns when you use `print!()` with a format <del> /// string that ends in a newline. </del> <ins> /// string that /// ends in a newline. </ins> /// /// **Why is this bad?** You should use `println!()` instead, which appends the /// newline.

/// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, ""); <del> /// /// // Good /// writeln!(buf); </del> /// ``` pub WRITELN_EMPTY_STRING, style,

/// # use std::fmt::Write; /// # let mut buf = String::new(); /// # let name = "World"; <del> /// /// // Bad </del> /// write!(buf, "Hello {}!n", name); <del> /// /// // Good /// writeln!(buf, "Hello {}!", name); </del> /// ``` pub WRITE_WITH_NEWLINE, style,

/// ```rust /// # use std::fmt::Write; /// # let mut buf = String::new(); <del> /// /// // Bad </del> /// writeln!(buf, "{}", "foo"); <del> /// /// // Good /// writeln!(buf, "foo"); </del> /// ``` pub WRITE_LITERAL, style,

if let (Some(fmt_str), expr) = self.check_tts(cx, &mac.args.inner_tokens(), true) { if fmt_str.symbol == Symbol::intern("") { let mut applicability = Applicability::MachineApplicable; <del> let suggestion = if let Some(e) = expr { snippet_with_applicability(cx, e.span, "v", &mut applicability) } else { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") </del> <ins> let suggestion = match expr { Some(expr) => snippet_with_applicability(cx, expr.span, "v", &mut applicability), None => { applicability = Applicability::HasPlaceholders; Cow::Borrowed("v") }, </ins> }; span_lint_and_sugg(

} fn run_ui_cargo(config: &mut compiletest::Config) { <ins> if cargo::is_rustc_test_suite() { return; } </ins> fn run_tests( config: &compiletest::Config, filter: &Option<String>,

<ins> #!/bin/sh CARGO_TARGET_DIR=$(pwd)/target/ export CARGO_TARGET_DIR echo 'Deprecated! `util/dev` usage is deprecated, please use `cargo dev` instead.' cd clippy_dev && cargo run -- "$@" </ins>
Change:
Here's a small testcase: If you run this through and look at the save-analysis JSON file, you'll see that there is no entry for the part of . This seems like a bug.
/cc
According to the expression is a where the part would be a with two s. This seems to be processed in . Not obvious to me why it would fail, since the at the end looks like it should deal with the first path segment.
cc me
I'm taking a look at this, fwiw. does nothing with the segment, looks like it should.
Oh, it's a bit more subtle, but I see what's going on now.
I got a fix, testing to see if I can remove hacks to existing code now.
Fix is at , but it's unclear to me how to add a test for this. Any doc I could look at?

Discussion:
Node::Visibility(&Spanned { node: hir::VisibilityKind::Restricted { ref path, .. }, .. }) => path.def, <del> Node::PathSegment(seg) => match seg.def { Some(def) => def, None => HirDef::Err, </del> <ins> Node::PathSegment(seg) => { match seg.def { Some(def) if def != HirDef::Err => def, _ => self.get_path_def(self.tcx.hir().get_parent_node(id)), } </ins> }, Node::Expr(&hir::Expr { node: hir::ExprKind::Struct(ref qpath, ..),
Change:
On stable and the code compiles successfully. On the code fails to compile with: At first I thought this was part of but now I think it is different because it started happening on whereas that issue is from November. This is currently causing ggez to fail to compile on nightly:
With uniform paths, which will be in 1.32, this compiles, so this should resolve itself I think. cc
So, this is indeed a regression from Looks like you missed the part, I'm still able to reproduce the error with .
It's not obvious to me right away what behavior is right here, pre- or post-. I'll look in more detail.
The ambiguity is reported correctly. I.e. it's obvious that there's an ambiguity (the error message says what exactly), but before the ambiguity wasn't detected due to "self-confirming" import "standing in the way". It's great that the fix got into 1.32 stable, so the time for which the issue existed on stable was minimized. Minimized reproduction:
Test in

Discussion:
<ins> // edition:2018 mod core { use core; //~ ERROR `core` is ambiguous use crate::*; } fn main() {} </ins>

<ins> error[E0659]: `core` is ambiguous (name vs any other name during import resolution) --> $DIR/issue-57539.rs:4:9 | LL |     use core; //~ ERROR `core` is ambiguous |         ^^^^ ambiguous name | = note: `core` could refer to a built-in extern crate = help: use `::core` to refer to this extern crate unambiguously note: `core` could also refer to the module imported here --> $DIR/issue-57539.rs:5:9 | LL |     use crate::*; |         ^^^^^^^^ = help: use `self::core` to refer to this module unambiguously error: aborting due to previous error For more information about this error, try `rustc --explain E0659`. </ins>
Change:
's implementation just forwards to the 's implementation, which will simply print , because the was locked (by that very same ). Effectively, this means that the current implementation of is equivalent to: f.write_str("MutexGuard { lock: Mutex { data: <locked} }") Instead, it should not try to lock the mutex, but use its own implementation to print the contents of the mutex.

Discussion:
#[stable(feature = "std_debug", since = "1.16.0")] impl<T: fmt::Debug> fmt::Debug for RwLockReadGuard<'_, T> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { <del> f.debug_struct("RwLockReadGuard").field("lock", &self.lock).finish() </del> <ins> (**self).fmt(f) </ins> } }

#[stable(feature = "std_debug", since = "1.16.0")] impl<T: fmt::Debug> fmt::Debug for RwLockWriteGuard<'_, T> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { <del> f.debug_struct("RwLockWriteGuard").field("lock", &self.lock).finish() </del> <ins> (**self).fmt(f) </ins> } }
Change:
The following code fails to compile (): with the following error If you make this modification, it compiles fine:
I think maybe cc or ?
I wonder whether this is a dupe of ?

Discussion:
<ins> // Regression test for issue #57611 // Ensures that we don't ICE // FIXME: This should compile, but it currently doesn't #![feature(trait_alias)] #![feature(type_alias_impl_trait)] trait Foo { type Bar: Baz<Self, Self>; fn bar(&self) -> Self::Bar; } struct X; impl Foo for X { type Bar = impl Baz<Self, Self>; //~ ERROR type mismatch in closure arguments //~^ ERROR type mismatch resolving fn bar(&self) -> Self::Bar { |x| x } } trait Baz<A, B> = Fn(&A) -> &B; fn main() {} </ins>

<ins> error[E0631]: type mismatch in closure arguments --> $DIR/issue-57611-trait-alias.rs:17:5 | LL |     type Bar = impl Baz<Self, Self>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected signature of `for<'r> fn(&'r X) -> _` ... LL |         |x| x |         ----- found signature of `fn(_) -> _` | = note: the return type of a function must have a statically known size error[E0271]: type mismatch resolving `for<'r> <[closure@$DIR/issue-57611-trait-alias.rs:21:9: 21:14] as std::ops::FnOnce<(&'r X,)>>::Output == &'r X` --> $DIR/issue-57611-trait-alias.rs:17:5 | LL |     type Bar = impl Baz<Self, Self>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected bound lifetime parameter, found concrete lifetime | = note: the return type of a function must have a statically known size error: aborting due to 2 previous errors Some errors have detailed explanations: E0271, E0631. For more information about an error, try `rustc --explain E0271`. </ins>

<ins> // Regression test for issue #57807 - ensure // that we properly unify associated types within // a type alias impl trait // check-pass #![feature(type_alias_impl_trait)] trait Bar { type A; } impl Bar for () { type A = (); } trait Foo { type A; type B: Bar<A = Self::A>; fn foo() -> Self::B; } impl Foo for () { type A = (); type B = impl Bar<A = Self::A>; fn foo() -> Self::B { () } } fn main() {} </ins>
Change:
This program works as expected: Uncomment that line and something goofy happens: The second print will be a different number every time it is run. This feels quite dangerous. And if you try to use , even in the first program, you get a segfault. But that might be a separate bug.
Can't reproduce. By default, this no longer typechecks, since the type of the second closure is inferred as a stack closure. If I annotate it, any combination of sigils that makes it compile seems to work properly. Lightly modernized code as follows:
I expect might have fixed a bug in closure lifetime inference that recently fixed this bug?
Same. Needstest.

Discussion:
<ins> // Copyright 2013 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. // Issue #5783 // Nondeterministic behavior when referencing a closure more than once fn main() { let a: &fn(int) -> @fn(int) -> int = |x:int| |y:int| -> int x + y; let b = a(2); assert!(a(2)(3) == 5); assert!(b(6) == 8); } </ins>
Change:
What state(s) are iterator adapters allowed to be in after a panic, Obviously they need to memory safe, but how many items are they expected to have consumed? Is it even allowed to call on an (un-fused) iterator after you called, say, on it with a closure that panicked? Asking because this has just come up in two PRs:
I think I personally see this as an edge case a bit like leaking and the like. We definitely need to avoid allowing memory unsafety, but otherwise I think it's reasonable for the iterator to be in an unspecified state. could continue to return values, it could return None, etc. In particular, I'd be fine with this behavior changing over time based on how we adjust the iterator's internal implementation.
I personally feel the same way as I don't think we need to hold ourselves to any particular standard in the standard library other then "stay memory safe"
I agree. I would like for this to be called out briefly in the std::iter module doc, which currently does not mention panic.

Discussion:
//! Common iterator adapters include [`map`], [`take`], and [`filter`]. //! For more, see their documentation. //! <ins> //! If an iterator adapter panics, the iterator will be in an unspecified (but //! memory safe) state.  This state is also not guaranteed to stay the same //! across versions of Rust, so you should avoid relying on the exact values //! returned by an iterator which panicked. //! </ins> //! [`map`]: trait.Iterator.html#method.map //! [`take`]: trait.Iterator.html#method.take //! [`filter`]: trait.Iterator.html#method.filter
Change:
This is a tracking issue for : Implemented in
Given that the implementation is trivial I don’t think letting it "bake" in Nightly is any use. And since already has this method and already has the version of this, I don’t expect this to be controversial at all. Still, let’s go through the usual dance: 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] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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.

Discussion:
/// modified in a way that it remains valid UTF-8. /// /// [`u8`]: primitive.u8.html <del> #[unstable(feature = "str_as_mut_ptr", issue = "58215")] </del> <ins> #[stable(feature = "str_as_mut_ptr", since = "1.36.0")] </ins> #[inline] pub fn as_mut_ptr(&mut self) -> *mut u8 { self as *mut str as *mut u8