Question:
See https://crater- This is a 1.62 regression, it seems, based on Crater. At the very least, it's a diagnostics issue that we're suggesting adding an already existing lifetime bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-04-01 to nightly-2022-05-31 regressed nightly: nightly-2022-05-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details, cc
The issue is that bound is causing the new wf check introduced in to fail. Regarding the diagnostics being weird, the issue is probably because we don't handle the case where a higher-ranked lifetime doesn't outlive itself. We just see a borrowck error, see that it's due to the binder's lifetime, and suggest adding it. Not sure if that needs fixed, personally think it's not worth it.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
This got fixed on nightly by enabling nll by default
claim For the test

<ins> // check-pass #[allow(unused)] fn test<T, F, U>(f: F) -> Box<dyn Fn(T) -> U + 'static> where F: 'static + Fn(T) -> U, for<'a> U: 'a, // < This is the problematic line, see #97607 { Box::new(move |t| f(t)) } fn main() {} </ins>


Question:
Building a simple fuzz target using --cfg fuzzing -Cpasses=sancov-module -Cllvm-args=-sanitizer-coverage-level=4 -Cllvm-args=-sanitizer-coverage-inline-8bit-counters results in a linker error: {symbol} referenced in section {section} at {rcgu}: defined in discarded section {other section} of {other rcgu}. One possible workaround is to set -Ccodegen-units=1 (any higher value triggers the error). Alternatively, -Znew-llvm-pass-manager=no and -Cpasses=sancov (instead of -Cpasses=sancov-module) will also result in a successful build. Repro steps: : Note: The same error also occurs with rustc 1.61.0 (stable channel). : Note: GNU ld is the default linker on this system. On another system where the linker is LLD, a similar error occurs, the message is just worded a bit differently.
We somehow end up running sancov-module on an input that already has defined. For the example IR below, the following happens: We generate a new which has a numeric suffix (".19" in the error message above). This is part of the $sancov.modulector8bitcounters (no suffix) comdat. The suffixed is to which already mentions and the original (no suffix). The .initarray.2 that is generated from is mentioned in two comdat groups: f and sancov.modulector8bitcounters. If we subsequently link this object with another object which also has a sancov.modulector8bitcounters comdat group, the linker will preserve only one of the sancov.modulector8bitcounters comdat groups. The error message shown earlier happens when the linker discards the comdat group that contains but keeps the .initarray.2 that references that symbol. It can do this because that .initarray.2 is also mentioned in comdat group f. LLVM IR before sancov-module: Some relevant sections of the IR after : After machine code generation, : There is an assert in CreateInitCallsForSections: This assert will trigger when is created. Of course, that only happens in LLVM builds with asserts enabled. What I don't yet know is why the sancov-module pass is being run on a module it has already been run for. I can see the multiple runs in the output if I pass in -Cllvm-args=-print-before-all, one of which creates the suffixed function, but I do not know what causes the pass to be run multiple times on the same module.
Passes configured with should probably be included only in pre-link optimization stage in: Similarly to sanitizer passes configured a few lines earlier: Otherwise they will be executed multiple times with LTO (a thin local LTO is enabled by default when using multiple codegen units).
Thank you. I was thinking along the same lines. I have a patch that does this, which I will send for review once I've tested it. I am wondering if there is value in also being able to specify passes specifically for the LTO stage; perhaps with a new -Zlink-passes flag. What do you think?

let llvm_selfprofiler = llvm_profiler.as_mut().map(|s| s as *mut _ as *mut c_void).unwrap_or(std::ptr::null_mut()); <del> let extra_passes = config.passes.join(","); </del> <ins> let extra_passes = if !is_lto { config.passes.join(",") } else { "".to_string() }; </ins> let llvm_plugins = config.llvm_plugins.join(",");


Question:
<!-- 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: I expected the compiler to let me know that function signature was wrong with the Result<, B`. Once I changed this, it compiled fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I've come up a solution with which the output of this test case will be like the following: It is cumbersome for still having E0391 printed, but it seems not easy to remove this without a significant code changes. I think the first message E0121 "the placeholder is not allowed within types on item signatures for return types" should have told the user enough information how to fix the problem. Any comments/suggestions?
having an early return for when there's no generics on will solve this problem.
Thanks a lot for the advise! After the following code change, the faulty message has gone way, and correct output generated.
The output of the test case after the fix is correct:
great, now you can send a pull request :).
Thanks for your work

} fn variances_of(tcx: TyCtxt<'_>, item_def_id: DefId) -> &[ty::Variance] { <ins> // Skip items with no generics - there's nothing to infer in them. if tcx.generics_of(item_def_id).count() == 0 { return &[]; } </ins> match tcx.def_kind(item_def_id) { DefKind::Fn | DefKind::AssocFn


Question:
<!-- 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: I expected the compiler to let me know that function signature was wrong with the Result<, B`. Once I changed this, it compiled fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I've come up a solution with which the output of this test case will be like the following: It is cumbersome for still having E0391 printed, but it seems not easy to remove this without a significant code changes. I think the first message E0121 "the placeholder is not allowed within types on item signatures for return types" should have told the user enough information how to fix the problem. Any comments/suggestions?
having an early return for when there's no generics on will solve this problem.
Thanks a lot for the advise! After the following code change, the faulty message has gone way, and correct output generated.
The output of the test case after the fix is correct:
great, now you can send a pull request :).
Thanks for your work

<ins> fn main() {} trait A { fn a(aa: B) -> Result<_, B> { //~^ ERROR: the placeholder `_` is not allowed within types on item signatures for return types [E0121] Ok(()) } } enum B {} </ins>


Question:
<!-- 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: I expected the compiler to let me know that function signature was wrong with the Result<, B`. Once I changed this, it compiled fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I've come up a solution with which the output of this test case will be like the following: It is cumbersome for still having E0391 printed, but it seems not easy to remove this without a significant code changes. I think the first message E0121 "the placeholder is not allowed within types on item signatures for return types" should have told the user enough information how to fix the problem. Any comments/suggestions?
having an early return for when there's no generics on will solve this problem.
Thanks a lot for the advise! After the following code change, the faulty message has gone way, and correct output generated.
The output of the test case after the fix is correct:
great, now you can send a pull request :).
Thanks for your work

<ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/issue-98260.rs:3:27 | LL |     fn a(aa: B) -> Result<_, B> { |                    -------^---- |                    |      | |                    |      not allowed in type signatures |                    help: replace with the correct return type: `Result<(), B>` error: aborting due to previous error For more information about this error, try `rustc --explain E0121`. </ins>


Question:
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.

Self::with_capacity_in(capacity, Global) } <del> /// Creates a `Vec<T>` directly from the raw components of another vector. </del> <ins> /// Creates a `Vec<T>` directly from a pointer, a capacity, and a length. </ins> /// /// # Safety /// /// This is highly unsafe, due to the number of invariants that aren't /// checked: /// <del> /// * `ptr` needs to have been previously allocated via [`String`]/`Vec<T>` ///   (at least, it's highly likely to be incorrect if it wasn't). </del> /// * `T` needs to have the same alignment as what `ptr` was allocated with. ///   (`T` having a less strict alignment is not sufficient, the alignment really ///   needs to be equal to satisfy the [`dealloc`] requirement that memory must be


Question:
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.

///   to be the same size as the pointer was allocated with. (Because similar to ///   alignment, [`dealloc`] must be called with the same layout `size`.) /// * `length` needs to be less than or equal to `capacity`. <ins> /// * The first `length` values must be properly initialized values of type `T`. /// * `capacity` needs to be the capacity that the pointer was allocated with. /// * The allocated size in bytes must be no larger than `isize::MAX`. ///   See the safety documentation of [`pointer::offset`]. /// /// These requirements are always upheld by any `ptr` that has been allocated /// via `Vec<T>`. Other allocation sources are allowed if the invariants are /// upheld. </ins> /// /// Violating these may cause problems like corrupting the allocator's /// internal data structures. For example it is normally **not** safe


Question:
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.

///     assert_eq!(rebuilt, [4, 5, 6]); /// } /// ``` <ins> /// /// Using memory that was allocated elsewhere: /// /// ```rust /// #![feature(allocator_api)] /// /// use std::alloc::{AllocError, Allocator, Global, Layout}; /// /// fn main() { ///     let layout = Layout::array::<u32>(16).expect("overflow cannot happen"); /// ///     let vec = unsafe { ///         let mem = match Global.allocate(layout) { ///             Ok(mem) => mem.cast::<u32>().as_ptr(), ///             Err(AllocError) => return, ///         }; /// ///         mem.write(1_000_000); /// ///         Vec::from_raw_parts_in(mem, 1, 16, Global) ///     }; /// ///     assert_eq!(vec, &[1_000_000]); ///     assert_eq!(vec.capacity(), 16); /// } /// ``` </ins> #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub unsafe fn from_raw_parts(ptr: *mut T, length: usize, capacity: usize) -> Self {


Question:
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.

Vec { buf: RawVec::with_capacity_in(capacity, alloc), len: 0 } } <del> /// Creates a `Vec<T, A>` directly from the raw components of another vector. </del> <ins> /// Creates a `Vec<T, A>` directly from a pointer, a capacity, a length, /// and an allocator. </ins> /// /// # Safety /// /// This is highly unsafe, due to the number of invariants that aren't /// checked: /// <del> /// * `ptr` needs to have been previously allocated via [`String`]/`Vec<T>` ///   (at least, it's highly likely to be incorrect if it wasn't). /// * `T` needs to have the same size and alignment as what `ptr` was allocated with. </del> <ins> /// * `T` needs to have the same alignment as what `ptr` was allocated with. </ins> ///   (`T` having a less strict alignment is not sufficient, the alignment really ///   needs to be equal to satisfy the [`dealloc`] requirement that memory must be ///   allocated and deallocated with the same layout.) <ins> /// * The size of `T` times the `capacity` (ie. the allocated size in bytes) needs ///   to be the same size as the pointer was allocated with. (Because similar to ///   alignment, [`dealloc`] must be called with the same layout `size`.) </ins> /// * `length` needs to be less than or equal to `capacity`. <del> /// * `capacity` needs to be the capacity that the pointer was allocated with. </del> <ins> /// * The first `length` values must be properly initialized values of type `T`. /// * `capacity` needs to [*fit*] the layout size that the pointer was allocated with. /// * The allocated size in bytes must be no larger than `isize::MAX`. ///   See the safety documentation of [`pointer::offset`]. /// /// These requirements are always upheld by any `ptr` that has been allocated /// via `Vec<T, A>`. Other allocation sources are allowed if the invariants are /// upheld. </ins> /// /// Violating these may cause problems like corrupting the allocator's /// internal data structures. For example it is **not** safe


Question:
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.

/// /// [`String`]: crate::string::String /// [`dealloc`]: crate::alloc::GlobalAlloc::dealloc <ins> /// [*fit*]: crate::alloc::Allocator#memory-fitting </ins> /// /// # Examples ///


Question:
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.

///     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 {


Question:
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

} #[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>,


Question:
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

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


Question:
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

return Compatibility::Incompatible(None); } <del> let provided_arg: &hir::Expr<'tcx> = &provided_args[provided_idx]; let expectation = Expectation::rvalue_hint(self, expected_input_ty); // FIXME: check that this is safe; I don't believe this commits any of the obligations, but I can't be sure. // //   I had another method of "soft" type checking before, //   but it was failing to find the type of some expressions (like "") //   so I prodded this method and made it pub(super) so I could call it, and it seems to work well. let checked_ty = self.check_expr_kind(provided_arg, expectation); </del> <ins> let (arg_ty, arg_span) = provided_arg_tys[provided_idx]; let expectation = Expectation::rvalue_hint(self, expected_input_ty); </ins> let coerced_ty = expectation.only_has_type(self).unwrap_or(formal_input_ty); <del> let can_coerce = self.can_coerce(checked_ty, coerced_ty); </del> <ins> let can_coerce = self.can_coerce(arg_ty, coerced_ty); </ins> if !can_coerce { return Compatibility::Incompatible(None); } // Using probe here, since we don't want this subtyping to affect inference. let subtyping_error = self.probe(|_| { <del> self.at(&self.misc(provided_arg.span), self.param_env) .sup(formal_input_ty, coerced_ty) .err() </del> <ins> self.at(&self.misc(arg_span), self.param_env).sup(formal_input_ty, coerced_ty).err() </ins> }); // Same as above: if either the coerce type or the checked type is an error type, // consider them *not* compatible. <del> let references_error = (coerced_ty, checked_ty).references_error(); </del> <ins> let references_error = (coerced_ty, arg_ty).references_error(); </ins> match (references_error, subtyping_error) { (false, None) => Compatibility::Compatible, (_, subtyping_error) => Compatibility::Incompatible(subtyping_error),


Question:
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

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)| {


Question:
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

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> }


Question:
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

<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 |


Question:
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

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>


Question:
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 ;)

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;


Question:
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 ;)

} _ => {} }; <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(),


Question:
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 ;)

}, 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.


Question:
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 ;)

/// 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


Question:
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 ;)

<ins> // check-pass #![deny(named_arguments_used_positionally)] fn main() { let value: f64 = 314.15926; let digits_before_decimal = 1; let digits_after_decimal = 2; let width = digits_before_decimal + 1 + digits_after_decimal; println!( "{value:0>width$.digits_after_decimal$}", value = value, width = width, digits_after_decimal = digits_after_decimal, ); } </ins>


Question:
<!-- 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: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Highlight to the user that the keywords and are mutually exclusive. Replace with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

/// Parses an enum declaration. fn parse_item_enum(&mut self) -> PResult<'a, ItemInfo> { <ins> if self.token.is_keyword(kw::Struct) { let mut err = self.struct_span_err( self.prev_token.span.to(self.token.span), "`enum` and `struct` are mutually exclusive", ); err.span_suggestion( self.prev_token.span.to(self.token.span), "replace `enum struct` with", "enum", Applicability::MachineApplicable, ); if self.look_ahead(1, |t| t.is_ident()) { self.bump(); err.emit(); } else { return Err(err); } } </ins> let id = self.parse_ident()?; let mut generics = self.parse_generics()?; generics.where_clause = self.parse_where_clause()?;


Question:
<!-- 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: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Highlight to the user that the keywords and are mutually exclusive. Replace with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> // run-rustfix pub enum Range { //~^ ERROR `enum` and `struct` are mutually exclusive Valid { begin: u32, len: u32, }, Out, } fn main() { } </ins>


Question:
<!-- 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: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Highlight to the user that the keywords and are mutually exclusive. Replace with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> // run-rustfix pub enum struct Range { //~^ ERROR `enum` and `struct` are mutually exclusive Valid { begin: u32, len: u32, }, Out, } fn main() { } </ins>


Question:
<!-- 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: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Highlight to the user that the keywords and are mutually exclusive. Replace with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> error: `enum` and `struct` are mutually exclusive --> $DIR/issue-99625-enum-struct-mutually-exclusive.rs:3:5 | LL | pub enum struct Range { |     ^^^^^^^^^^^ help: replace `enum struct` with: `enum` error: aborting due to previous error </ins>


Question:
<!-- 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-

} else { if matches!(def_kind, DefKind::AnonConst) && tcx.lazy_normalization() { let hir_id = tcx.hir().local_def_id_to_hir_id(def_id.expect_local()); <ins> let parent_def_id = tcx.hir().get_parent_item(hir_id); </ins> if tcx.hir().opt_const_param_default_param_hir_id(hir_id).is_some() { // In `generics_of` we set the generics' parent to be our parent's parent which means that // we lose out on the predicates of our actual parent if we dont return those predicates here.


Question:
<!-- 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-

//        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); } }


Question:
<!-- 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-

<ins> // check-pass #![crate_type = "lib"] #![feature(generic_const_exprs)] #![allow(incomplete_features)] pub trait MyIterator { type Output; } pub trait Foo { const ABC: usize; } pub struct IteratorStruct<const N: usize>{ } pub struct Bar<const N: usize> { pub data: [usize; N] } impl<const N: usize> MyIterator for IteratorStruct<N> { type Output = Bar<N>; } pub fn test1<T: Foo>() -> impl MyIterator<Output = Bar<{T::ABC}>> where [(); T::ABC]: Sized { IteratorStruct::<{T::ABC}>{} } pub trait Baz<const N: usize>{} impl<const N: usize> Baz<N> for Bar<N> {} pub fn test2<T: Foo>() -> impl MyIterator<Output = impl Baz<{ T::ABC }>> where [(); T::ABC]: Sized { IteratorStruct::<{T::ABC}>{} } </ins>


Question:
When using in the to enable profiling, having a local copy of is required. If no such copy is present, errors about missing libraries are emitted and the build fails. Expected behavior: Bootstrap initializes the submodule when is enabled. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This should be pretty easy to fix - call in if profiling is enabled.
claim

builder.update_submodule(&Path::new("library").join("stdarch")); <ins> // Profiler information requires LLVM's compiler-rt if builder.config.profiler { builder.update_submodule(&Path::new("src/llvm-project")); } </ins> let mut target_deps = builder.ensure(StartupObjects { compiler, target }); let compiler_to_use = builder.compiler_for(compiler.stage, compiler.host, target);