jiebi/CodeConvo huggingface dataset:
Change:
<ins> // run-rustfix fn main() { let _ = vec![vec![0, 1], vec![2]] .into_iter() .map(|y| y.iter().map(|x| x + 1)) //~^ ERROR cannot return value referencing function parameter `y` .collect::<Vec<_>>(); } </ins>

Discussion:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.
Change:
trait_obj.method_two(); ``` <del> You can read more about trait objects in the Trait Object section of the Reference: </del> <ins> You can read more about trait objects in the [Trait Objects] section of the Reference. </ins> <del> https://doc.rust-lang.org/reference.html#trait-objects </del> <ins> [Trait Objects]: https://doc.rust-lang.org/reference/types.html#trait-objects </ins> "##, E0034: r##"

Discussion:
The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker
Change:
<ins> //@ ignore-lldb // Test that static debug info is not collapsed with #[collapse_debuginfo(external)] //@ compile-flags:-g // === GDB TESTS =================================================================================== // gdb-command:info line collapse_debuginfo_static_external::FOO // gdb-check:[...]Line 15[...] #[collapse_debuginfo(external)] macro_rules! decl_foo { () => { static FOO: u32 = 0; }; } decl_foo!(); fn main() { // prevent FOO from getting optimized out std::hint::black_box(&FOO); } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: then shows I'd expect DWATdecl_line to be 9 (the line where the macro is called), not 5 (the line where the static is defined inside the macro). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
cc
Change:
<ins> error: unexpected `for_you` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:13:12 | LL |     if not for_you { |        ----^^^^^^^ |        | |        help: use `!` to perform logical negation error: unexpected `the_worst` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:21:15 | LL |     while not the_worst { |           ----^^^^^^^^^ |           | |           help: use `!` to perform logical negation error: unexpected `println` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:30:9 | LL |     if not  // lack of braces is [sic] |        ----- help: use `!` to perform logical negation LL |         println!("Then when?"); |         ^^^^^^^ error: expected `{`, found `;` --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:30:31 | LL |     if not  // lack of braces is [sic] |     -- this `if` statement has a condition, but no block LL |         println!("Then when?"); |                               ^ error: unexpected `2` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:36:24 | LL |     let resource = not 2; |                    ----^ |                    | |                    help: use `!` to perform logical negation error: unexpected `be_smothered_out_before` after identifier --> $DIR/issue-46836-identifier-not-instead-of-negation.rs:42:27 | LL |     let young_souls = not be_smothered_out_before; |                       ----^^^^^^^^^^^^^^^^^^^^^^^ |                       | |                       help: use `!` to perform logical negation error: aborting due to 6 previous errors </ins>

Discussion:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `
Change:
args: GenericArgsRef<'tcx>, ) -> FfiResult<'tcx> { let field_ty = field.ty(self.cx.tcx, args); <del> if field_ty.has_opaque_types() { self.check_type_for_ffi(cache, field_ty) } else { let field_ty = self.cx.tcx.normalize_erasing_regions(self.cx.param_env, field_ty); self.check_type_for_ffi(cache, field_ty) } </del> <ins> let field_ty = self .cx .tcx .try_normalize_erasing_regions(self.cx.param_env, field_ty) .unwrap_or(field_ty); self.check_type_for_ffi(cache, field_ty) </ins> } /// Checks if the given `VariantDef`'s field types are "ffi-safe".

Discussion:
Create an empty crate, add to dependencies, and . [ ] Previous Stable [ ] Current Stable [X] Current Beta [X] Current Nightly Discovered on since 1.72.0-nightly ( 2023-07-03). The previous version 2023-07-02 is good. The breaking day is the same as . I suspect this is also related to . But fix to that does NOT fix this ICE though. cc The error message is similar to , but that occurs on an earlier version 2023-06-28. I guess it's unrelated.
label regression-from-stable-to-beta
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> #![feature(generic_const_exprs)] #![allow(incomplete_features)] struct Combination<const STRATEGIES: usize>; impl<const STRATEGIES: usize> Combination<STRATEGIES> { fn and<M>(self) -> Combination<{ STRATEGIES + 1 }> { Combination } } pub fn main() { Combination::<0>.and::<_>().and::<_>(); //~^ ERROR: type annotations needed } </ins>

Discussion:
Continuation of . I minimized this together with thank you for your help and originally finding the issue! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: The first and most relevant delayed bug: All the delayed bugs and the usual backtrace: <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed the the PR: searched nightlies: from nightly-2021-01-01 to nightly-2022-12-12 regressed nightly: nightly-2022-11-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
<ins> error[E0308]: `?` operator has incompatible types --> $DIR/issue-100246.rs:28:24 | LL |     let other: Other = downcast()?; |                        ^^^^^^^^^^^ expected struct `Other`, found reference | = note: `?` operator cannot convert from `&_` to `Other` = note: expected struct `Other` found reference `&_` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
: and then if I increase the recursion limit enough... adding a backtrace gives nothing new, however, compiling on nightly gives the following: </p</detailsI strongly suspect this is related to , but that issue is now old and should have been solved. Perhaps a regression?
can you provide the you compiled that code snippet with? The provided code doesn't seem complete.
I can reproduce it with in the section of a , but this is not an ICE.
Change:
/// /// Behavior is undefined if any of the following conditions are violated: /// <del> /// * Both `x` and `y` must be [valid] for both reads and writes. </del> <ins> /// * Both `x` and `y` must be [valid] for both reads and writes. They must remain valid even when the ///   other pointer is written. (This means if the memory ranges overlap, the two pointers must not ///   be subject to aliasing restrictions relative to each other.) </ins> /// /// * Both `x` and `y` must be properly aligned. ///

Discussion:
The  function allows passed pointers to overlap, and its safety section is as follows: It says that both pointers must be "valid," but IIUC, the definition of validity becomes unclear under Stacked Borrows. Consider the following program (all code in this comment is checked using Miri with ): and are both "valid" at in the sense that this program is safe. is invalidated when we perform a write using , but it's ok because we don't use anymore. However, the following program exhibits UB in spite of the validity of and , because first reads from and the read invalidates . Note that the intermediate unique reference () is crucial for "separating" the two pointers. If we remove the intermediate reference, those pointers have the same capabilities. In other words, the following program does not exhibit UB: The difference between the two examples is so subtle that I'm not sure how to spell out the exact safety conditions for . This issue is found while formalizing the safety of in the Rustv project.
By the way, of contains unrelated UB. The example calls  twice, which accidentally invalidates the first pointer .
possibly related:
cc
The same argument seems to apply to . Miri (tracking raw pointers) reported undefined behavior for the following code: When I set the argument of the to 1, Miri did not report any undefined behavior. This may be an implementation detail. <details</detailsNote that the pointers are valid individually but not simultaneously in these examples. I found this distinction very interesting, but I don't know how to explain this without being too scholarly
Well, they are valid individually, but they are not "both valid at the same time". In separation logic terms, we have but we do not have . The issue is to find a way to express that without using separation logic terminology.^^ is entirely unrelated, as it concerns the safety invariant of and the soundness of its method in ways other than aliasing. is an example of code that uses* the wrong way, at least wrong under Stacked Borrows. So it is the dual issue -- it is a consumer if the spec which this issue points could needs to be made more precise.
Change:
--> $DIR/closures-in-loops.rs:13:16 | LL |         v.push(|| x = String::new()); <del> |                ^^ - borrows occur due to use of `x` in closure |                | |                `x` was mutably borrowed here in the previous iteration of the loop </del> <ins> |         -------^^------------------- |         |      |  | |         |      |  borrows occur due to use of `x` in closure |         |      `x` was mutably borrowed here in the previous iteration of the loop |         first borrow used here, in later iteration of loop </ins> error[E0524]: two closures require unique access to `x` at the same time --> $DIR/closures-in-loops.rs:20:16 | LL |         v.push(|| *x = String::new()); <del> |                ^^ -- borrows occur due to use of `x` in closure |                | |                closures are constructed here in different iterations of loop </del> <ins> |         -------^^-------------------- |         |      |  | |         |      |  borrows occur due to use of `x` in closure |         |      closures are constructed here in different iterations of loop |         first borrow used here, in later iteration of loop </ins> error: aborting due to 3 previous errors

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: It looks like the error is pointing to the wrong spot in the code and is quite misleading. Ideally the output should mention that is still mutably borrowed because it holds a reference to between loops. Or something, im not actually sure :P I have confirmed that this occurs in both the latest stable (1.62.1) and nightly () <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
With the proposed the output will be like this:
Change:
pub fn trait_has_default_impl(tcx: &ctxt, trait_def_id: DefId) -> bool { populate_implementations_for_trait_if_necessary(tcx, trait_def_id); <del> match tcx.lang_items.to_builtin_kind(trait_def_id) { Some(BoundSend) | Some(BoundSync) => true, _ => tcx.traits_with_default_impls.borrow().contains_key(&trait_def_id), } </del> <ins> tcx.traits_with_default_impls.borrow().contains_key(&trait_def_id) </ins> } /// Records a trait-to-implementation mapping.

Discussion:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.
Change:
/// ```ignore (it's a test) /// Let's say I'm just some text will ya? /// ``` <ins> /// /// An inlined `code`! </ins> pub fn foo() {} /// Just a normal struct.

Discussion:
My guess is that the yellow inline code style is incorrectly being applied to code blocks too. ! !
cc since you're knowledgeable about rustdoc's CSS
I'll send a fix shortly.
looks to be the likely cause. searched nightlies: from nightly-2021-07-01 to nightly-2021-08-25 regressed nightly: nightly-2021-08-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Change:
("y"), ) // Mobile view set-window-size: (600, 600) // staggered layout with 2em spacing

Discussion:
see <img width="1728" alt="image" src=""- Arc 0.108.1 () MacOS 13.2.1 (22D68)
this seems like a rustdoc issue, cc ?
( I couldn't quickly reproduce locally yet, need to figure out the arguments first )
Yep, rustdoc issue, I'll transfer it across. This should be improved by just reducing the number of features shown here with , since a lot of them are already active for the module, but that won't help with the compression/decompression modules in the top-level list. !
Actually, rather than this made me realise there's another issue around how we deal with inlined re-exports, opened for that.
It's also kinda related to

I think long cfg expressions should be broken across multiple lines. I saw this cause issues : !
Do you have an idea on how to improve this maybe
What if we inserted zero width spaces after the keywords? So after each we insert a zero width space (see the ). Maybe we would have to wrap each name in a too but I would have to experiment a bit. Then each expression would try to stay as an inline-block and then break the line on the keywords (like , , , ...)
If we start having "groups", not sure if it'll work well. But definitely worth a try!
I started a test case with a long and complicated expression that results in this image: ! Currently combining a lot of short features is very unreadable and not's are hard to spot. With just it gets a lot more readable, but since the braces get lost in translation it is not clear which flags are binding with , or respectively. ! What if we display a little tree diagram? For most cases that would probably result in a short list with an or an in the beginning. Another idea could be to not draw the tree but to have visible boxes encasing the respective flags. What do you think?
I need to see things to be able to make my own opinion on which approach is better. :smile: But maybe has an idea?
Maybe it could show "any of"/"all of" on longer chains (say 3+)? I don't think there's a ton that can realistically be done here — a long cfg is going to result in a long doc cfg.
There are a lot of things that can be done. For example, for more than 3 items, we could show only the 3 first and show the rest on click. It's mostly about how to display things.
The original case has gotten a lot better, the actual doc string now gets ~60% of the horizontal space rather than ~30%: !
Rendering has degraded again (even though the documented cfg expressions themselves have become shorter): !
Change:
<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. struct vec2 { y: f32 } struct vec3 { y: f32, z: f32 } fn make(v: vec2) { let vec3 { y: _, z: _ } = v; //~^ ERROR mismatched types: expected `vec2` but found `vec3` //~^^ ERROR struct `vec2` does not have a field named `z` } fn main() { } </ins>  No newline at end of file

Discussion:
This is one of those bugs where an earlier error is leading to poor error reporting later on in the output. So it should not be considered high priority. Nonetheless, it would be nice if we could strive for error messages to be sane when considered in isolation, which this example violates: Transcript: The issue is that the second message claims that does not have a field named , but it clearly does. I could understand this message if it said vec2 does not have a field named .
Change:
use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use rustc_infer::infer::{DefineOpaqueTypes, InferOk, LateBoundRegionConversionTime}; use rustc_middle::hir::map; <ins> use rustc_middle::traits::IsConstable; </ins> use rustc_middle::ty::error::TypeError::{self, Sorts}; use rustc_middle::ty::{ self, suggest_arbitrary_trait_bound, suggest_constraining_type_param, AdtKind,

Discussion:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.
Change:
//        parent of generics returned by `generics_of` // // In the above code we want the anon const to have predicates in its param env for `T: Trait` <del> let item_def_id = tcx.hir().get_parent_item(hir_id); // In the above code example we would be calling `explicit_predicates_of(Foo)` here </del> <ins> // and we would be calling `explicit_predicates_of(Foo)` here return tcx.explicit_predicates_of(parent_def_id); } let parent_def_kind = tcx.def_kind(parent_def_id); if matches!(parent_def_kind, DefKind::OpaqueTy) { // In `instantiate_identity` we inherit the predicates of our parent. // However, opaque types do not have a parent (see `gather_explicit_predicates_of`), which means // that we lose out on the predicates of our actual parent if we dont return those predicates here. // // // fn foo<T: Trait>() -> impl Iterator<Output = Another<{ <T as Trait>::ASSOC }> > { todo!() } //                                                        ^^^^^^^^^^^^^^^^^^^ the def id we are calling //                                                                            explicit_predicates_of on // // In the above code we want the anon const to have predicates in its param env for `T: Trait`. // However, the anon const cannot inherit predicates from its parent since it's opaque. // // To fix this, we call `explicit_predicates_of` directly on `foo`, the parent's parent. // In the above example this is `foo::{opaque#0}` or `impl Iterator` let parent_hir_id = tcx.hir().local_def_id_to_hir_id(parent_def_id.def_id); // In the above example this is the function `foo` let item_def_id = tcx.hir().get_parent_item(parent_hir_id); // In the above code example we would be calling `explicit_predicates_of(foo)` here </ins> return tcx.explicit_predicates_of(item_def_id); } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: This code should compile normally. Instead, this happened: In the function, T was already bounded by the trait which does have an associated item named . However, Rust complains that no associated item named was found for . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
I did some digging and this might be related to Mind taking a look?
A fix exists here at but we're waiting on 's pending RPIT refactor work to fix this. In the mean time, developers who need this feature can use the branch in . https://rust-
Change:
pat_src: PatternSource, bindings: &mut SmallVec<[(PatBoundCtx, FxHashSet<Ident>); 1]>, ) { <ins> let is_tuple_struct_pat = matches!(pat.kind, PatKind::TupleStruct(_, _)); </ins> // Visit all direct subpatterns of this pattern. pat.walk(&mut |pat| { debug!("resolve_pattern pat={:?} node={:?}", pat, pat.kind); match pat.kind { <del> PatKind::Ident(bmode, ident, ref sub) => { </del> <ins> // In tuple struct patterns ignore the invalid `ident @ ...`. // It will be handled as an error by the AST lowering. PatKind::Ident(bmode, ident, ref sub) if !(is_tuple_struct_pat && sub.as_ref().filter(|p| p.is_rest()).is_some()) => { </ins> // First try to resolve the identifier as some existing entity, // then fall back to a fresh binding. let has_sub = sub.is_some();

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --The bug exists in the beta, nightly, and stable build channels. : The error and the backtrace provided are produced by the stable build. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced: Edit: you can actually omit the enum declaration and it still crashes :thinking: `
oh, sorry, I've already got a fix. I'll post it soon. Though it may not be the best one.
Great! You should tweak not losing diags. For further reference, you could do when you work on an issue to avoid conflicts.
okay, thanks. Better late than never… claim
This is caused by , I believe. 1.44 emits errors w/o ICE'ing but 1.45 hits it. godbolt (1.44): godbolt (1.45):
Let's keep this open to track stable/beta backports.
The reference suggested this to be possible, which is how I came to suggest it to OP. We wanted to avoid naming them to not suggest any specific content.
here is another one: (assuming related)
The stable fix is reverted, and the nightly one is also but introduced another fix. I keep this open when that PR is beta-nominated, just in case.
We don't backport the fix in favor of this comment: So I'm just going to close this as fixed.