jiebi/CodeConvo huggingface dataset:
Code change:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.

Related discussion:
text: ///     assert_eq!(rebuilt, [4, 5, 6]); /// } /// ``` <ins> /// /// Using memory that was allocated elsewhere: /// /// ```rust /// use std::alloc::{alloc, Layout}; /// /// fn main() { ///     let layout = Layout::array::<u32>(16).expect("overflow cannot happen"); ///     let vec = unsafe { ///         let mem = alloc(layout).cast::<u32>(); ///         if mem.is_null() { ///             return; ///         } /// ///         mem.write(1_000_000); /// ///         Vec::from_raw_parts(mem, 1, 16) ///     }; /// ///     assert_eq!(vec, &[1_000_000]); ///     assert_eq!(vec.capacity(), 16); /// } /// ``` </ins> #[inline] #[unstable(feature = "allocator_api", issue = "32838")] pub unsafe fn from_raw_parts_in(ptr: *mut T, length: usize, capacity: usize, alloc: A) -> Self {
Code change:
This perfectly wrong statement causes compiler to mention s, and even though nothing like this is written in the code: (here and after normal errors about argument number/type mismatch are not shown as they are not the problem) Originally I've found this while editing some async code and passing instead of . I was very confused and thought that it somehow relates to //etc but after some minification I was left with the snippet above. This error becomes less confusing after desugaring loop by hand: Note that using is required to trigger this bug, using doesn't trigger it for some reason. In fact, you don't even need a : So in the end, this can be triggered with an / one of branches on which is diverging expression with that is being passed to a function with wrong number of arguments. As I previously said, I've found this while working on async code and I think this is the main way how this error can be seen (let's be serious, nobody calls functions with loop arguments). The reason why it's easier to find this error with async is that blocks are commonly passed to functions (like ) and can contain loops inside them. In my case the code looked something like this: Which caused an error like this: ! Note that "expected because of this" points to the last statement in the block even though it has nothing to do, really, with the error. searched nightlies: from nightly-2022-04-10 to nightly-2022-05-09 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: : : </detailsBisection shows that this issue was introduced by which aligns with other observations. This is likely caused by the same underlying problem as : diagnostic code calls a second time which confuses different parts of the compiler. cc as they've worked on fixing issues caused by before This is reproducible with (2022-07-02 ) and with most nightly-es after (except for those that ICE). label +A-diagnostics +D-confusing +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I wonder if this is also fixed by -- I will check and/or fix this too. claim

Related discussion:
text: } #[instrument(skip(self, expr), level = "debug")] <del> pub(super) fn check_expr_kind( </del> <ins> fn check_expr_kind( </ins> &self, expr: &'tcx hir::Expr<'tcx>, expected: Expectation<'tcx>,
Code change:
This perfectly wrong statement causes compiler to mention s, and even though nothing like this is written in the code: (here and after normal errors about argument number/type mismatch are not shown as they are not the problem) Originally I've found this while editing some async code and passing instead of . I was very confused and thought that it somehow relates to //etc but after some minification I was left with the snippet above. This error becomes less confusing after desugaring loop by hand: Note that using is required to trigger this bug, using doesn't trigger it for some reason. In fact, you don't even need a : So in the end, this can be triggered with an / one of branches on which is diverging expression with that is being passed to a function with wrong number of arguments. As I previously said, I've found this while working on async code and I think this is the main way how this error can be seen (let's be serious, nobody calls functions with loop arguments). The reason why it's easier to find this error with async is that blocks are commonly passed to functions (like ) and can contain loops inside them. In my case the code looked something like this: Which caused an error like this: ! Note that "expected because of this" points to the last statement in the block even though it has nothing to do, really, with the error. searched nightlies: from nightly-2022-04-10 to nightly-2022-05-09 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: : : </detailsBisection shows that this issue was introduced by which aligns with other observations. This is likely caused by the same underlying problem as : diagnostic code calls a second time which confuses different parts of the compiler. cc as they've worked on fixing issues caused by before This is reproducible with (2022-07-02 ) and with most nightly-es after (except for those that ICE). label +A-diagnostics +D-confusing +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I wonder if this is also fixed by -- I will check and/or fix this too. claim

Related discussion:
text: self.set_tainted_by_errors(); let tcx = self.tcx; <ins> // Precompute the provided types and spans, since that's all we typically need for below let provided_arg_tys: IndexVec<ProvidedIdx, (Ty<'tcx>, Span)> = provided_args .iter() .map(|expr| { let ty = self .typeck_results .borrow() .expr_ty_adjusted_opt(*expr) .unwrap_or_else(|| tcx.ty_error()); (self.resolve_vars_if_possible(ty), expr.span) }) .collect(); </ins> // A "softer" version of the `demand_compatible`, which checks types without persisting them, // and treats error types differently // This will allow us to "probe" for other argument orders that would likely have been correct
Code change:
This perfectly wrong statement causes compiler to mention s, and even though nothing like this is written in the code: (here and after normal errors about argument number/type mismatch are not shown as they are not the problem) Originally I've found this while editing some async code and passing instead of . I was very confused and thought that it somehow relates to //etc but after some minification I was left with the snippet above. This error becomes less confusing after desugaring loop by hand: Note that using is required to trigger this bug, using doesn't trigger it for some reason. In fact, you don't even need a : So in the end, this can be triggered with an / one of branches on which is diverging expression with that is being passed to a function with wrong number of arguments. As I previously said, I've found this while working on async code and I think this is the main way how this error can be seen (let's be serious, nobody calls functions with loop arguments). The reason why it's easier to find this error with async is that blocks are commonly passed to functions (like ) and can contain loops inside them. In my case the code looked something like this: Which caused an error like this: ! Note that "expected because of this" points to the last statement in the block even though it has nothing to do, really, with the error. searched nightlies: from nightly-2022-04-10 to nightly-2022-05-09 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: : : </detailsBisection shows that this issue was introduced by which aligns with other observations. This is likely caused by the same underlying problem as : diagnostic code calls a second time which confuses different parts of the compiler. cc as they've worked on fixing issues caused by before This is reproducible with (2022-07-02 ) and with most nightly-es after (except for those that ICE). label +A-diagnostics +D-confusing +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I wonder if this is also fixed by -- I will check and/or fix this too. claim

Related discussion:
text: ArgMatrix::new(provided_args.len(), formal_and_expected_inputs.len(), check_compatible) .find_errors(); <del> // Precompute the provided types and spans, since that's all we typically need for below let provided_arg_tys: IndexVec<ProvidedIdx, (Ty<'tcx>, Span)> = provided_args .iter() .map(|expr| { let ty = self .typeck_results .borrow() .expr_ty_adjusted_opt(*expr) .unwrap_or_else(|| tcx.ty_error()); (self.resolve_vars_if_possible(ty), expr.span) }) .collect(); </del> // First, check if we just need to wrap some arguments in a tuple. if let Some((mismatch_idx, terr)) = compatibility_diagonal.iter().enumerate().find_map(|(i, c)| {
Code change:
This perfectly wrong statement causes compiler to mention s, and even though nothing like this is written in the code: (here and after normal errors about argument number/type mismatch are not shown as they are not the problem) Originally I've found this while editing some async code and passing instead of . I was very confused and thought that it somehow relates to //etc but after some minification I was left with the snippet above. This error becomes less confusing after desugaring loop by hand: Note that using is required to trigger this bug, using doesn't trigger it for some reason. In fact, you don't even need a : So in the end, this can be triggered with an / one of branches on which is diverging expression with that is being passed to a function with wrong number of arguments. As I previously said, I've found this while working on async code and I think this is the main way how this error can be seen (let's be serious, nobody calls functions with loop arguments). The reason why it's easier to find this error with async is that blocks are commonly passed to functions (like ) and can contain loops inside them. In my case the code looked something like this: Which caused an error like this: ! Note that "expected because of this" points to the last statement in the block even though it has nothing to do, really, with the error. searched nightlies: from nightly-2022-04-10 to nightly-2022-05-09 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: : : </detailsBisection shows that this issue was introduced by which aligns with other observations. This is likely caused by the same underlying problem as : diagnostic code calls a second time which confuses different parts of the compiler. cc as they've worked on fixing issues caused by before This is reproducible with (2022-07-02 ) and with most nightly-es after (except for those that ICE). label +A-diagnostics +D-confusing +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I wonder if this is also fixed by -- I will check and/or fix this too. claim

Related discussion:
text: fn main() { let needlesArr: Vec<char> = vec!['a', 'f']; needlesArr.iter().fold(|x, y| { <ins> //~^ ERROR this function takes 2 arguments but 1 argument was supplied </ins> }); <del> //~^^ ERROR mismatched types //~| ERROR this function takes 2 arguments but 1 argument was supplied </del> }
Code change:
This perfectly wrong statement causes compiler to mention s, and even though nothing like this is written in the code: (here and after normal errors about argument number/type mismatch are not shown as they are not the problem) Originally I've found this while editing some async code and passing instead of . I was very confused and thought that it somehow relates to //etc but after some minification I was left with the snippet above. This error becomes less confusing after desugaring loop by hand: Note that using is required to trigger this bug, using doesn't trigger it for some reason. In fact, you don't even need a : So in the end, this can be triggered with an / one of branches on which is diverging expression with that is being passed to a function with wrong number of arguments. As I previously said, I've found this while working on async code and I think this is the main way how this error can be seen (let's be serious, nobody calls functions with loop arguments). The reason why it's easier to find this error with async is that blocks are commonly passed to functions (like ) and can contain loops inside them. In my case the code looked something like this: Which caused an error like this: ! Note that "expected because of this" points to the last statement in the block even though it has nothing to do, really, with the error. searched nightlies: from nightly-2022-04-10 to nightly-2022-05-09 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: : : </detailsBisection shows that this issue was introduced by which aligns with other observations. This is likely caused by the same underlying problem as : diagnostic code calls a second time which confuses different parts of the compiler. cc as they've worked on fixing issues caused by before This is reproducible with (2022-07-02 ) and with most nightly-es after (except for those that ICE). label +A-diagnostics +D-confusing +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I wonder if this is also fixed by -- I will check and/or fix this too. claim

Related discussion:
text: <del> error[E0308]: mismatched types --> $DIR/issue-3044.rs:3:35 | LL |       needlesArr.iter().fold(|x, y| { |  ____________________________------_^ | |                            | | |                            the expected closure LL | |     }); | |_____^ expected closure, found `()` | = note: expected closure `[closure@$DIR/issue-3044.rs:3:28: 3:34]` found unit type `()` </del> error[E0061]: this function takes 2 arguments but 1 argument was supplied --> $DIR/issue-3044.rs:3:23 | LL |       needlesArr.iter().fold(|x, y| { |  _______________________^^^^- <ins> LL | | </ins> LL | |     }); | |______- an argument is missing |
Code change:
This perfectly wrong statement causes compiler to mention s, and even though nothing like this is written in the code: (here and after normal errors about argument number/type mismatch are not shown as they are not the problem) Originally I've found this while editing some async code and passing instead of . I was very confused and thought that it somehow relates to //etc but after some minification I was left with the snippet above. This error becomes less confusing after desugaring loop by hand: Note that using is required to trigger this bug, using doesn't trigger it for some reason. In fact, you don't even need a : So in the end, this can be triggered with an / one of branches on which is diverging expression with that is being passed to a function with wrong number of arguments. As I previously said, I've found this while working on async code and I think this is the main way how this error can be seen (let's be serious, nobody calls functions with loop arguments). The reason why it's easier to find this error with async is that blocks are commonly passed to functions (like ) and can contain loops inside them. In my case the code looked something like this: Which caused an error like this: ! Note that "expected because of this" points to the last statement in the block even though it has nothing to do, really, with the error. searched nightlies: from nightly-2022-04-10 to nightly-2022-05-09 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: : : </detailsBisection shows that this issue was introduced by which aligns with other observations. This is likely caused by the same underlying problem as : diagnostic code calls a second time which confuses different parts of the compiler. cc as they've worked on fixing issues caused by before This is reproducible with (2022-07-02 ) and with most nightly-es after (except for those that ICE). label +A-diagnostics +D-confusing +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I wonder if this is also fixed by -- I will check and/or fix this too. claim

Related discussion:
text: help: provide the argument | LL ~     needlesArr.iter().fold(|x, y| { <ins> LL + </ins> LL ~     }, /* value */); | <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins> <del> Some errors have detailed explanations: E0061, E0308. For more information about an error, try `rustc --explain E0061`. </del> <ins> For more information about this error, try `rustc --explain E0061`. </ins>
Code change:
Running clippy or build on the Vaultwarden code-base using breaks. It is broken since and still works on Tried to run before running this without luck. If you need any more information, please let me know. Vaultwarden: Working: Broken since: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like this is a duplicate of , , , , , and Sorry for the clutter ;)

Related discussion:
text: use rustc_lint_defs::builtin::NAMED_ARGUMENTS_USED_POSITIONALLY; use rustc_lint_defs::{BufferedEarlyLint, BuiltinLintDiagnostics, LintId}; <del> use rustc_parse_format::{Count, FormatSpec}; </del> <ins> use rustc_parse_format::Count; </ins> use std::borrow::Cow; use std::collections::hash_map::Entry;
Code change:
Running clippy or build on the Vaultwarden code-base using breaks. It is broken since and still works on Tried to run before running this without luck. If you need any more information, please let me know. Vaultwarden: Working: Broken since: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like this is a duplicate of , , , , , and Sorry for the clutter ;)

Related discussion:
text: } _ => {} }; <del> match a.format { FormatSpec { width: Count::CountIsName(s, _), .. } | FormatSpec { precision: Count::CountIsName(s, _), .. } => { used_argument_names.insert(s); } _ => {} }; </del> <ins> if let Count::CountIsName(s, _) = a.format.width { used_argument_names.insert(s); } if let Count::CountIsName(s, _) = a.format.precision { used_argument_names.insert(s); } </ins> } } for (symbol, (index, span)) in names { if !used_argument_names.contains(symbol.as_str()) { let msg = format!("named argument `{}` is not used by name", symbol.as_str()); <del> let arg_span = cx.arg_spans[index]; </del> <ins> let arg_span = cx.arg_spans.get(index).copied(); </ins> cx.ecx.buffered_early_lint.push(BufferedEarlyLint { span: MultiSpan::from_span(span), msg: msg.clone(),
Code change:
Running clippy or build on the Vaultwarden code-base using breaks. It is broken since and still works on Tried to run before running this without luck. If you need any more information, please let me know. Vaultwarden: Working: Broken since: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like this is a duplicate of , , , , , and Sorry for the clutter ;)

Related discussion:
text: }, BuiltinLintDiagnostics::NamedArgumentUsedPositionally(positional_arg, named_arg, name) => { db.span_label(named_arg, "this named argument is only referred to by position in formatting string"); <del> let msg = format!("this formatting argument uses named argument `{}` by position", name); db.span_label(positional_arg, msg); db.span_suggestion_verbose( positional_arg, "use the named argument by name to avoid ambiguity", format!("{{{}}}", name), Applicability::MaybeIncorrect, ); </del> <ins> if let Some(positional_arg) = positional_arg { let msg = format!("this formatting argument uses named argument `{}` by position", name); db.span_label(positional_arg, msg); db.span_suggestion_verbose( positional_arg, "use the named argument by name to avoid ambiguity", format!("{{{}}}", name), Applicability::MaybeIncorrect, ); } </ins> } } // Rewrap `db`, and pass control to the user.
Code change:
Running clippy or build on the Vaultwarden code-base using breaks. It is broken since and still works on Tried to run before running this without luck. If you need any more information, please let me know. Vaultwarden: Working: Broken since: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like this is a duplicate of , , , , , and Sorry for the clutter ;)

Related discussion:
text: /// If true, the lifetime will be fully elided. use_span: Option<(Span, bool)>, }, <del> NamedArgumentUsedPositionally(Span, Span, String), </del> <ins> NamedArgumentUsedPositionally(Option<Span>, Span, String), </ins> } /// Lints that are buffered up early on in the `Session` before the