Question:
I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).

// be added explicitly if necessary, see the error in `fn link_rlib`) compiled // as an executable due to `--test`. Use whole-archive implicitly, like before // the introduction of native lib modifiers. <del> || (bundle != Some(false) && sess.opts.test) </del> <ins> || (whole_archive == None && bundle != Some(false) && sess.opts.test) </ins> { cmd.link_whole_staticlib( name,


Question:
I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).

# ignore-cross-compile -- compiling C++ code does not work well when cross-compiling <del> # This test case makes sure that native libraries are linked with --whole-archive semantics # when the `-bundle,+whole-archive` modifiers are applied to them. </del> <ins> # This test case makes sure that native libraries are linked with appropriate semantics # when the `[+-]bundle,[+-]whole-archive` modifiers are applied to them. </ins> # # The test works by checking that the resulting executables produce the expected output, # part of which is emitted by otherwise unreferenced C code. If +whole-archive didn't work


Question:
I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).

-include ../../run-make-fulldeps/tools.mk <del> all: $(TMPDIR)/$(call BIN,directly_linked) $(TMPDIR)/$(call BIN,indirectly_linked) $(TMPDIR)/$(call BIN,indirectly_linked_via_attr) </del> <ins> all: $(TMPDIR)/$(call BIN,directly_linked)  $(TMPDIR)/$(call BIN,directly_linked_test_plus_whole_archive)  $(TMPDIR)/$(call BIN,directly_linked_test_minus_whole_archive)  $(TMPDIR)/$(call BIN,indirectly_linked)  $(TMPDIR)/$(call BIN,indirectly_linked_via_attr) </ins> $(call RUN,directly_linked) | $(CGREP) 'static-initializer.directly_linked.' <ins> $(call RUN,directly_linked_test_plus_whole_archive) --nocapture | $(CGREP) 'static-initializer.' $(call RUN,directly_linked_test_minus_whole_archive) --nocapture | $(CGREP) -v 'static-initializer.' </ins> $(call RUN,indirectly_linked) | $(CGREP) 'static-initializer.indirectly_linked.' $(call RUN,indirectly_linked_via_attr) | $(CGREP) 'static-initializer.native_lib_in_src.'


Question:
I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).

$(TMPDIR)/$(call BIN,directly_linked): $(call NATIVE_STATICLIB,c_static_lib_with_constructor) $(RUSTC) directly_linked.rs -l static:+whole-archive=c_static_lib_with_constructor <ins> # Native lib linked into test executable, +whole-archive $(TMPDIR)/$(call BIN,directly_linked_test_plus_whole_archive): $(call NATIVE_STATICLIB,c_static_lib_with_constructor) $(RUSTC) directly_linked_test_plus_whole_archive.rs --test -l static:+whole-archive=c_static_lib_with_constructor # Native lib linked into test executable, -whole-archive $(TMPDIR)/$(call BIN,directly_linked_test_minus_whole_archive): $(call NATIVE_STATICLIB,c_static_lib_with_constructor) $(RUSTC) directly_linked_test_minus_whole_archive.rs --test -l static:-whole-archive=c_static_lib_with_constructor </ins> # Native lib linked into RLIB via `-l static:-bundle,+whole-archive`, RLIB linked into executable $(TMPDIR)/$(call BIN,indirectly_linked): $(TMPDIR)/librlib_with_cmdline_native_lib.rlib $(RUSTC) indirectly_linked.rs


Question:
I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).

<ins> use std::io::Write; #[test] fn test_thing() { print!("ran the test"); std::io::stdout().flush().unwrap(); } </ins>


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

} } Err(coercion_error) => { <ins> // Mark that we've failed to coerce the types here to suppress // any superfluous errors we might encounter while trying to // emit or provide suggestions on how to fix the initial error. fcx.set_tainted_by_errors(); </ins> let (expected, found) = if label_expression_as_expected { // In the case where this is a "forced unit", like // `break`, we want to call the `()` "expected"


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

<ins> #![recursion_limit = "5"] // To reduce noise //expect incompatible type error when ambiguous traits are in scope //and not an overflow error on the span in the main function. struct Ratio<T>(T); pub trait Pow { fn pow(self) -> Self; } impl<'a, T> Pow for &'a Ratio<T> where &'a T: Pow, { fn pow(self) -> Self { self } } fn downcast<'a, W: ?Sized>() -> std::io::Result<&'a W> { todo!() } struct Other; fn main() -> std::io::Result<()> { let other: Other = downcast()?;//~ERROR 28:24: 28:35: `?` operator has incompatible types Ok(()) } </ins>


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

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


Question:
Currently we have , should and also be implemented for where ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Can you help me with runnable code to understand why the will be useful and what can be a use case for it? label +T-libs-api
Ah ok, maybe I understand what do you mean, currently we can do And your proposal is to support
I don’t have a use case for , adding it is just for matching existing . But for , I want to be able to write: instead of

} #[cfg(not(no_global_oom_handling))] <ins> #[stable(feature = "vec_from_array_ref", since = "CURRENT_RUSTC_VERSION")] impl<T: Clone, const N: usize> From<&[T; N]> for Vec<T> { /// Allocate a `Vec<T>` and fill it by cloning `s`'s items. /// /// # Examples /// /// ``` /// assert_eq!(Vec::from(&[1, 2, 3]), vec![1, 2, 3]); /// ``` fn from(s: &[T; N]) -> Vec<T> { Self::from(s.as_slice()) } } #[cfg(not(no_global_oom_handling))] #[stable(feature = "vec_from_array_ref", since = "CURRENT_RUSTC_VERSION")] impl<T: Clone, const N: usize> From<&mut [T; N]> for Vec<T> { /// Allocate a `Vec<T>` and fill it by cloning `s`'s items. /// /// # Examples /// /// ``` /// assert_eq!(Vec::from(&mut [1, 2, 3]), vec![1, 2, 3]); /// ``` fn from(s: &mut [T; N]) -> Vec<T> { Self::from(s.as_mut_slice()) } } #[cfg(not(no_global_oom_handling))] </ins> #[stable(feature = "vec_from_array", since = "1.44.0")] impl<T, const N: usize> From<[T; N]> for Vec<T> { /// Allocate a `Vec<T>` and move `s`'s items into it.


Question:
Currently we have , should and also be implemented for where ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Can you help me with runnable code to understand why the will be useful and what can be a use case for it? label +T-libs-api
Ah ok, maybe I understand what do you mean, currently we can do And your proposal is to support
I don’t have a use case for , adding it is just for matching existing . But for , I want to be able to write: instead of

// Ensure all ZSTs have been freed. assert!(alloc.state.borrow().0.is_empty()); } <ins> #[test] fn test_vec_from_array_ref() { assert_eq!(Vec::from(&[1, 2, 3]), vec![1, 2, 3]); } #[test] fn test_vec_from_array_mut_ref() { assert_eq!(Vec::from(&mut [1, 2, 3]), vec![1, 2, 3]); } </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: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.

let ai = &self.expected_indices; let ii = &self.provided_indices; <ins> // Issue: 100478, when we end the iteration, // `next_unmatched_idx` will point to the index of the first unmatched let mut next_unmatched_idx = 0; </ins> for i in 0..cmp::max(ai.len(), ii.len()) { <del> // If we eliminate the last row, any left-over inputs are considered missing </del> <ins> // If we eliminate the last row, any left-over arguments are considered missing </ins> if i >= mat.len() { <del> return Some(Issue::Missing(i)); </del> <ins> return Some(Issue::Missing(next_unmatched_idx)); </ins> } <del> // If we eliminate the last column, any left-over arguments are extra </del> <ins> // If we eliminate the last column, any left-over inputs are extra </ins> if mat[i].len() == 0 { <del> return Some(Issue::Extra(i)); </del> <ins> return Some(Issue::Extra(next_unmatched_idx)); </ins> } // Make sure we don't pass the bounds of our matrix


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: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.

let is_input = i < ii.len(); if is_arg && is_input && matches!(mat[i][i], Compatibility::Compatible) { // This is a satisfied input, so move along <ins> next_unmatched_idx += 1; </ins> continue; }


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: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.

if is_input { for j in 0..ai.len() { // If we find at least one argument that could satisfy this input <del> // this argument isn't useless </del> <ins> // this input isn't useless </ins> if matches!(mat[i][j], Compatibility::Compatible) { useless = false; break;


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: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.

if matches!(c, Compatibility::Compatible) { Some(i) } else { None } }) .collect(); <del> if compat.len() != 1 { // this could go into multiple slots, don't bother exploring both </del> <ins> if compat.len() < 1 { // try to find a cycle even when this could go into multiple slots, see #101097 </ins> is_cycle = false; break; }


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: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.

} while !self.provided_indices.is_empty() || !self.expected_indices.is_empty() { <del> match self.find_issue() { </del> <ins> let res = self.find_issue(); match res { </ins> Some(Issue::Invalid(idx)) => { let compatibility = self.compatibility_matrix[idx][idx].clone(); let input_idx = self.provided_indices[idx];


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: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.

None => { // We didn't find any issues, so we need to push the algorithm forward // First, eliminate any arguments that currently satisfy their inputs <del> for (inp, arg) in self.eliminate_satisfied() { </del> <ins> let eliminated = self.eliminate_satisfied(); assert!(!eliminated.is_empty(), "didn't eliminated any indice in this round"); for (inp, arg) in eliminated { </ins> matched_inputs[arg] = Some(inp); } }


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: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.

<ins> use std::sync::Arc; macro_rules! GenT { ($name:tt) => { #[derive(Default, Debug)] struct $name { #[allow(unused)] val: i32, } impl $name { #[allow(unused)] fn new(val: i32) -> Self { $name { val } } } }; } GenT!(T1); GenT!(T2); GenT!(T3); GenT!(T4); GenT!(T5); GenT!(T6); GenT!(T7); GenT!(T8); #[allow(unused)] fn foo(p1: T1, p2: Arc<T2>, p3: T3, p4: Arc<T4>, p5: T5, p6: T6, p7: T7, p8: Arc<T8>) {} fn three_diff(_a: T1, _b: T2, _c: T3) {} fn four_shuffle(_a: T1, _b: T2, _c: T3, _d: T4) {} fn main() { three_diff(T2::new(0)); //~ ERROR this function takes four_shuffle(T3::default(), T4::default(), T1::default(), T2::default()); //~ ERROR 35:5: 35:17: arguments to this function are incorrect [E0308] four_shuffle(T3::default(), T2::default(), T1::default(), T3::default()); //~ ERROR 36:5: 36:17: arguments to this function are incorrect [E0308] let p1 = T1::new(0); let p2 = Arc::new(T2::new(0)); let p3 = T3::new(0); let p4 = Arc::new(T4::new(1)); let p5 = T5::new(0); let p6 = T6::new(0); let p7 = T7::new(0); let p8 = Arc::default(); foo( //~^ 47:5: 47:8: this function takes 8 arguments but 7 arguments were supplied [E0061] p1, //p2, p3, p4, p5, p6, p7, p8, ); } </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: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.

<ins> error[E0061]: this function takes 3 arguments but 1 argument was supplied --> $DIR/issue-100478.rs:34:5 | LL |     three_diff(T2::new(0)); |     ^^^^^^^^^^------------ |               || |               |an argument of type `T1` is missing |               an argument of type `T3` is missing | note: function defined here --> $DIR/issue-100478.rs:30:4 | LL | fn three_diff(_a: T1, _b: T2, _c: T3) {} |    ^^^^^^^^^^ ------  ------  ------ help: provide the arguments | LL |     three_diff(/* T1 */, T2::new(0), /* T3 */); |               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error[E0308]: arguments to this function are incorrect --> $DIR/issue-100478.rs:35:5 | LL |     four_shuffle(T3::default(), T4::default(), T1::default(), T2::default()); |     ^^^^^^^^^^^^ -------------  -------------  -------------  ------------- expected `T4`, found `T2` |                  |              |              | |                  |              |              expected `T3`, found `T1` |                  |              expected `T2`, found `T4` |                  expected `T1`, found `T3` | note: function defined here --> $DIR/issue-100478.rs:31:4 | LL | fn four_shuffle(_a: T1, _b: T2, _c: T3, _d: T4) {} |    ^^^^^^^^^^^^ ------  ------  ------  ------ help: did you mean | LL |     four_shuffle(T1::default(), T2::default(), T3::default(), T4::default()); |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error[E0308]: arguments to this function are incorrect --> $DIR/issue-100478.rs:36:5 | LL |     four_shuffle(T3::default(), T2::default(), T1::default(), T3::default()); |     ^^^^^^^^^^^^ -------------                 -------------  ------------- expected struct `T4`, found struct `T3` |                  |                             | |                  |                             expected `T3`, found `T1` |                  expected `T1`, found `T3` | note: function defined here --> $DIR/issue-100478.rs:31:4 | LL | fn four_shuffle(_a: T1, _b: T2, _c: T3, _d: T4) {} |    ^^^^^^^^^^^^ ------  ------  ------  ------ help: swap these arguments | LL |     four_shuffle(T1::default(), T2::default(), T3::default(), /* T4 */); |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error[E0061]: this function takes 8 arguments but 7 arguments were supplied --> $DIR/issue-100478.rs:47:5 | LL |     foo( |     ^^^ ... LL |         p3, p4, p5, p6, p7, p8, |         -- an argument of type `Arc<T2>` is missing | note: function defined here --> $DIR/issue-100478.rs:29:4 | LL | fn foo(p1: T1, p2: Arc<T2>, p3: T3, p4: Arc<T4>, p5: T5, p6: T6, p7: T7, p8: Arc<T8>) {} |    ^^^ ------  -----------  ------  -----------  ------  ------  ------  ----------- help: provide the argument | LL |     foo(p1, /* Arc<T2> */, p3, p4, p5, p6, p7, p8); |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to 4 previous errors Some errors have detailed explanations: E0061, E0308. For more information about an error, try `rustc --explain E0061`. </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: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.

<ins> struct A; struct B; struct C; struct D; fn f( a1: A, a2: A, b1: B, b2: B, c1: C, c2: C, ) {} fn main() { f(C, A, A, A, B, B, C); //~ ERROR this function takes 6 arguments but 7 arguments were supplied [E0061] f(C, C, A, A, B, B);  //~ ERROR arguments to this function are incorrect [E0308] f(A, A, D, D, B, B);  //~ arguments to this function are incorrect [E0308] f(C, C, B, B, A, A);  //~ arguments to this function are incorrect [E0308] f(C, C, A, B, A, A);  //~ arguments to this function are incorrect [E0308] } </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: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.

<ins> error[E0061]: this function takes 6 arguments but 7 arguments were supplied --> $DIR/issue-101097.rs:16:5 | LL |     f(C, A, A, A, B, B, C); |     ^ -     -  -  - expected `C`, found `B` |       |     |  | |       |     |  argument of type `A` unexpected |       |     expected `B`, found `A` |       expected `A`, found `C` | note: function defined here --> $DIR/issue-101097.rs:6:4 | LL | fn f( |    ^ LL |     a1: A, |     ----- LL |     a2: A, |     ----- LL |     b1: B, |     ----- LL |     b2: B, |     ----- LL |     c1: C, |     ----- LL |     c2: C, |     ----- help: did you mean | LL |     f(A, A, B, B, C, C); |      ~~~~~~~~~~~~~~~~~~ error[E0308]: arguments to this function are incorrect --> $DIR/issue-101097.rs:17:5 | LL |     f(C, C, A, A, B, B); |     ^ | note: function defined here --> $DIR/issue-101097.rs:6:4 | LL | fn f( |    ^ LL |     a1: A, |     ----- LL |     a2: A, |     ----- LL |     b1: B, |     ----- LL |     b2: B, |     ----- LL |     c1: C, |     ----- LL |     c2: C, |     ----- help: did you mean | LL |     f(A, A, B, B, C, C); |      ~~~~~~~~~~~~~~~~~~ error[E0308]: arguments to this function are incorrect --> $DIR/issue-101097.rs:18:5 | LL |     f(A, A, D, D, B, B); |     ^       -  -  ---- two arguments of type `C` and `C` are missing |             |  | |             |  argument of type `D` unexpected |             argument of type `D` unexpected | note: function defined here --> $DIR/issue-101097.rs:6:4 | LL | fn f( |    ^ LL |     a1: A, |     ----- LL |     a2: A, |     ----- LL |     b1: B, |     ----- LL |     b2: B, |     ----- LL |     c1: C, |     ----- LL |     c2: C, |     ----- help: did you mean | LL |     f(A, A, B, B, /* C */, /* C */); |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error[E0308]: arguments to this function are incorrect --> $DIR/issue-101097.rs:19:5 | LL |     f(C, C, B, B, A, A); |     ^ -  -        -  - expected `C`, found `A` |       |  |        | |       |  |        expected `C`, found `A` |       |  expected `A`, found `C` |       expected `A`, found `C` | note: function defined here --> $DIR/issue-101097.rs:6:4 | LL | fn f( |    ^ LL |     a1: A, |     ----- LL |     a2: A, |     ----- LL |     b1: B, |     ----- LL |     b2: B, |     ----- LL |     c1: C, |     ----- LL |     c2: C, |     ----- help: did you mean | LL |     f(A, A, B, B, C, C); |      ~~~~~~~~~~~~~~~~~~ error[E0308]: arguments to this function are incorrect --> $DIR/issue-101097.rs:20:5 | LL |     f(C, C, A, B, A, A); |     ^ -  -  -     -  - expected `C`, found `A` |       |  |  |     | |       |  |  |     expected `C`, found `A` |       |  |  expected struct `B`, found struct `A` |       |  expected `A`, found `C` |       expected `A`, found `C` | note: function defined here --> $DIR/issue-101097.rs:6:4 | LL | fn f( |    ^ LL |     a1: A, |     ----- LL |     a2: A, |     ----- LL |     b1: B, |     ----- LL |     b2: B, |     ----- LL |     c1: C, |     ----- LL |     c2: C, |     ----- help: did you mean | LL |     f(A, A, /* B */, B, C, C); |      ~~~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to 5 previous errors Some errors have detailed explanations: E0061, E0308. For more information about an error, try `rustc --explain E0061`. </ins>


Question:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

// NOTE: generics must be cleaned before args let generics = clean_generics(generics, cx); let args = clean_args_from_types_and_body_id(cx, sig.decl.inputs, body_id); <del> let decl = clean_fn_decl_with_args(cx, sig.decl, args); </del> <ins> let mut decl = clean_fn_decl_with_args(cx, sig.decl, args); if sig.header.is_async() { decl.output = decl.sugared_async_return_type(); } </ins> (generics, decl) }); Box::new(Function { decl, generics })


Question:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

///   <br>Used to determine line-wrapping. /// * `indent`: The number of spaces to indent each successive line with, if line-wrapping is ///   necessary. <del> /// * `asyncness`: Whether the function is async or not. </del> pub(crate) fn full_print<'a, 'tcx: 'a>( &'a self, header_len: usize, indent: usize, <del> asyncness: hir::IsAsync, </del> cx: &'a Context<'tcx>, ) -> impl fmt::Display + 'a + Captures<'tcx> { <del> display_fn(move |f| self.inner_full_print(header_len, indent, asyncness, f, cx)) </del> <ins> display_fn(move |f| self.inner_full_print(header_len, indent, f, cx)) </ins> } fn inner_full_print( &self, header_len: usize, indent: usize, <del> asyncness: hir::IsAsync, </del> f: &mut fmt::Formatter<'_>, cx: &Context<'_>, ) -> fmt::Result {


Question:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

args_plain.push_str(", ..."); } <del> let arrow_plain; let arrow = if let hir::IsAsync::Async = asyncness { let output = self.sugared_async_return_type(); arrow_plain = format!("{:#}", output.print(cx)); if f.alternate() { arrow_plain.clone() } else { format!("{}", output.print(cx)) } } else { arrow_plain = format!("{:#}", self.output.print(cx)); if f.alternate() { arrow_plain.clone() } else { format!("{}", self.output.print(cx)) } }; </del> <ins> let arrow_plain = format!("{:#}", self.output.print(cx)); let arrow = if f.alternate() { arrow_plain.clone() } else { format!("{}", self.output.print(cx)) }; </ins> let declaration_len = header_len + args_plain.len() + arrow_plain.len(); let output = if declaration_len > 80 {


Question:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

href = href, name = name, generics = g.print(cx), <del> decl = d.full_print(header_len, indent, header.asyncness, cx), </del> <ins> decl = d.full_print(header_len, indent, cx), </ins> notable_traits = notable_traits_decl(d, cx), where_clause = print_where_clause(g, cx, indent, end_newline), )


Question:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

name = name, generics = f.generics.print(cx), where_clause = print_where_clause(&f.generics, cx, 0, Ending::Newline), <del> decl = f.decl.full_print(header_len, 0, header.asyncness, cx), </del> <ins> decl = f.decl.full_print(header_len, 0, cx), </ins> notable_traits = notable_traits_decl(&f.decl, cx), ); });


Question:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

<ins> // edition:2021 // ignore-tidy-linelength // Regression test for <https://github.com/rust-lang/rust/issues/101199> use std::future::Future; // @is "$.index[*][?(@.name=='get_int')].inner.decl.output" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int')].inner.header.async" false pub fn get_int() -> i32 { 42 } // @is "$.index[*][?(@.name=='get_int_async')].inner.decl.output" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int_async')].inner.header.async" true pub async fn get_int_async() -> i32 { 42 } // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.kind" '"impl_trait"' // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.inner[0].trait_bound.trait.name" '"Future"' // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].name" '"Output"' // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].binding.equality.type" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int_future')].inner.header.async" false pub fn get_int_future() -> impl Future<Output = i32> { async { 42 } } // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.kind" '"impl_trait"' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.inner[0].trait_bound.trait.name" '"Future"' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].name" '"Output"' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].binding.equality.type" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.header.async" true pub async fn get_int_future_async() -> impl Future<Output = i32> { async { 42 } } </ins>


Question:
I tried -ing this proc macro crate: rust /// pub extern crate procmacrocrate; /// /// #[macroexport] /// macrorules! foo { /// (path:ident)::) =( /// $crate::procmacrocrate::identity!{ /// path):: /// } /// ) /// } /// /// #[macroexport] /// macrorules! baz { /// () =( /// crate::BAR) /// ) /// } /// /// pub const BAR: u32 = 19; /// /// fn main(){ /// println!("{}", crate::baz!()); /// } /// /// I expected to see this happen: The test completes successfully Instead, this happened: The test fails compilation with this error: It most recently worked on: : This also fails in 1.62 and 1.63. This appears to be fixed in the beta channel, but I could not find a mention of this bug or a related one. It's entirely possible that the bug will trigger again in future versions if this code isn't used in tests. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisection shows it regressed in and got fixed in . Looks like this issue wasn’t deliberately fixed, since doesn’t call out any issue being fixed. Also did involve minor breakage, as discussed in its thread, but I haven’t looked into it enough to tell whether those cases of breakage were similar to this issue or different.
label A-macros, A-proc-macros
cc (author of ) and (author of ) (read above to see how these PRs are relevant)
Looking at the code changes from it makes sense that this regressed, as the call to () would have done a check and rejected creating . The code (which was originally introduced in : ), should've probably avoided the constructor from the get-go, but it wasn't an issue because wasn't a possible identifier in that case previously. In , I changed the logic there to avoid going through that constructor when re-building the tokens internally, so we don't do the broken validation on that side anymore, and the problem wouldn't happen anymore. I don't think there's much more to be done here, as it's fixed already on beta, and isn't likely to regress with the new design.
Thanks a lot for your insights!
label E-easy. (We only need a test to close this issue.)
For someone wanting to add a test for this, you should be able to add the use code in . You can see for an idea of what the test might look like.
claim

<ins> // check-pass // edition:2021 // aux-build:test-macros.rs #![no_std] // Don't load unnecessary hygiene information from std extern crate std; #[macro_use] extern crate test_macros; macro_rules! foo { ($($path:ident)::*) => ( test_macros::recollect!( $($path)::* ) ) } macro_rules! baz { () => ( foo!($crate::BAR) ) } pub const BAR: u32 = 19; fn main(){ std::println!("{}", baz!()); } </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 on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- 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 --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.
Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection

kw::Extern, kw::Impl, kw::Unsafe, <ins> kw::Const, </ins> kw::Static, kw::Union, kw::Macro,


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 on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- 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 --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.
Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection

<ins> // run-rustfix mod test { pub const X: i32 = 123; //~^ ERROR expected one of `!` or `::`, found keyword `const` } fn main() { println!("{}", test::X); } </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 on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- 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 --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.
Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection

<ins> // run-rustfix mod test { public const X: i32 = 123; //~^ ERROR expected one of `!` or `::`, found keyword `const` } fn main() { println!("{}", test::X); } </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 on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- 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 --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.
Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection

<ins> error: expected one of `!` or `::`, found keyword `const` --> $DIR/public-instead-of-pub-3.rs:3:12 | LL |     public const X: i32 = 123; |            ^^^^^ expected one of `!` or `::` | help: write `pub` instead of `public` to make the item public | LL |     pub const X: i32 = 123; |     ~~~ 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. 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. --should suggest if the argument is a closure instead of suggesting to call the closure 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: <!-- 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
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.

} /// When encountering an fn-like type, try accessing the output of the type <del> /// // and suggesting calling it if it satisfies a predicate (i.e. if the </del> <ins> /// and suggesting calling it if it satisfies a predicate (i.e. if the </ins> /// output has a method or a field): /// ```compile_fail,E0308 /// fn foo(x: usize) -> usize { x }


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. --should suggest if the argument is a closure instead of suggesting to call the closure 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: <!-- 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
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.

} else { err.span_suggestion(sp, &msg, suggestion, applicability); } <ins> } else if self.suggest_else_fn_with_closure(err, expr, found, expected) { </ins> } else if self.suggest_fn_call(err, expr, found, |output| self.can_coerce(output, expected)) && let ty::FnDef(def_id, ..) = &found.kind() && let Some(sp) = self.tcx.hir().span_if_local(*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. 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. --should suggest if the argument is a closure instead of suggesting to call the closure 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: <!-- 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
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.

} } <ins> /// issue #102320, for `unwrap_or` with closure as argument, suggest `unwrap_or_else` /// FIXME: currently not working for suggesting `map_or_else`, see #102408 pub(crate) fn suggest_else_fn_with_closure( &self, err: &mut Diagnostic, expr: &hir::Expr<'_>, found: Ty<'tcx>, expected: Ty<'tcx>, ) -> bool { let Some((_def_id_or_name, output, _inputs)) = self.extract_callable_info(expr, found) else { return false; }; if !self.can_coerce(output, expected) { return false; } let parent = self.tcx.hir().get_parent_node(expr.hir_id); if  let Some(Node::Expr(call_expr)) = self.tcx.hir().find(parent) && let hir::ExprKind::MethodCall( hir::PathSegment { ident: method_name, .. }, self_expr, args, .., ) = call_expr.kind && let Some(self_ty) = self.typeck_results.borrow().expr_ty_opt(self_expr) { let new_name = Ident { name: Symbol::intern(&format!("{}_else", method_name.as_str())), span: method_name.span, }; let probe = self.lookup_probe( expr.span, new_name, self_ty, self_expr, ProbeScope::TraitsInScope, ); // check the method arguments number if let Ok(pick) = probe && let fn_sig = self.tcx.fn_sig(pick.item.def_id) && let fn_args = fn_sig.skip_binder().inputs() && fn_args.len() == args.len() + 1 { err.span_suggestion_verbose( method_name.span.shrink_to_hi(), &format!("try calling `{}` instead", new_name.name.as_str()), "_else", Applicability::MaybeIncorrect, ); return true; } } false } </ins> /// Checks whether there is a local type somewhere in the chain of /// autoderefs of `rcvr_ty`. fn type_derefs_to_local(


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. --should suggest if the argument is a closure instead of suggesting to call the closure 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: <!-- 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
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.

<ins> // run-rustfix fn main() { let x = "com.example.app"; let y: Option<&str> = None; let _s = y.unwrap_or_else(|| x.split('.').nth(1).unwrap()); //~^ ERROR: mismatched types [E0308] } </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. --should suggest if the argument is a closure instead of suggesting to call the closure 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: <!-- 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
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.

<ins> // run-rustfix fn main() { let x = "com.example.app"; let y: Option<&str> = None; let _s = y.unwrap_or(|| x.split('.').nth(1).unwrap()); //~^ ERROR: mismatched types [E0308] } </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. --should suggest if the argument is a closure instead of suggesting to call the closure 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: <!-- 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
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.

<ins> error[E0308]: mismatched types --> $DIR/sugg-else-for-closure.rs:6:26 | LL |     let _s = y.unwrap_or(|| x.split('.').nth(1).unwrap()); |                --------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `&str`, found closure |                | |                arguments to this function are incorrect | = note: expected reference `&str` found closure `[closure@$DIR/sugg-else-for-closure.rs:6:26: 6:28]` note: associated function defined here --> $SRC_DIR/core/src/option.rs:LL:COL | LL |     pub const fn unwrap_or(self, default: T) -> T |                  ^^^^^^^^^ help: try calling `unwrap_or_else` instead | LL |     let _s = y.unwrap_or_else(|| x.split('.').nth(1).unwrap()); |                         +++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>


Question:
with synchronization assumes that does not panic. This assumption is however not correct. For instance, a panic occurs if the TLS key used to store the thread info , , , and . The code examples above all use intrusive lists and have to wait on a condition to before destroying the list nodes. If panics, the nodes will be dropped during stack unwinding without checking that condition, leading to undefined behaviour (some of these cases are in , so I'm marking this as a soundness problem with ). Fixing this would either require guarding against panics in each of these cases or ensuring that never panics. label +I-unsound +A-atomic +T-libs +T-libs-api
Thanks for bringing this up! I agree this is a problem. In general, the pattern with parking is: Unwinding would mean leaving that loop even though the condition isn't true. While code right after the loop isn't executed, there are many cases where leaving the current frame before the condition is true is problematic, as all your examples show. I think it's not reasonable to expect every user of to take this subtle pitfall into account. Instead, I believe we should guarantee that never unwinds.
All the situations in which can currently panic are very unusual things that are most likely unrecoverable errors. So I think it'd be fine to just never let unwind, and instead always on panic.
I think Rust should allocate the needed resources eagerly when creating a new thread, to avoid this problem.
It actually does most of the time, as always creates a . However, if the thread is created through other means, the struct needs to be lazily allocated, which can of course fail. Either way, we also need to protect against the case where fails - it should not, but who knows what some obscure system might do (the UNIX parking implementation is used on systems like L4RE and 3DS/Horizon). In general, I think it is easier for maintainability if we just always convert panics to aborts in / rather than going through every system and abstraction to ensure no panics are caused. Still, this is possible to do in the future (as is returning instantly).
I just tripped over an issue in this area. I'm trying to put together a userspace mutex for learning and it works fine apart from when there is a panic. If there has been a panic, then I get a panic when handling panic and fall over with this stack trace: Note that at 18, some destructors are run, that appear to be releasing Thread local storage. By the time I try to run , at 7, the thread is already invalid (although , I don't know that). I tried: But, I get the same problem. I presume because of raciness between the check for panicking and the panic actually starting.
It looks like you're implementing a global allocator using your thread::park_timeout-based mutex? That's going to be problematic, since the thread parking data is stored in a heap allocation (an ) that gets deallocated on thread destruction.
Thank you. I have an approach to the problem which works as a spinlock, but I was experimenting to see if I could do something more efficient using . It's one of those where I wasn't sure if it was interesting to report, but I thought I'd mention it.

use crate::fmt; use crate::io; use crate::marker::PhantomData; <del> use crate::mem; </del> <ins> use crate::mem::{self, forget}; </ins> use crate::num::NonZeroU64; use crate::num::NonZeroUsize; use crate::panic;


Question:
with synchronization assumes that does not panic. This assumption is however not correct. For instance, a panic occurs if the TLS key used to store the thread info , , , and . The code examples above all use intrusive lists and have to wait on a condition to before destroying the list nodes. If panics, the nodes will be dropped during stack unwinding without checking that condition, leading to undefined behaviour (some of these cases are in , so I'm marking this as a soundness problem with ). Fixing this would either require guarding against panics in each of these cases or ensuring that never panics. label +I-unsound +A-atomic +T-libs +T-libs-api
Thanks for bringing this up! I agree this is a problem. In general, the pattern with parking is: Unwinding would mean leaving that loop even though the condition isn't true. While code right after the loop isn't executed, there are many cases where leaving the current frame before the condition is true is problematic, as all your examples show. I think it's not reasonable to expect every user of to take this subtle pitfall into account. Instead, I believe we should guarantee that never unwinds.
All the situations in which can currently panic are very unusual things that are most likely unrecoverable errors. So I think it'd be fine to just never let unwind, and instead always on panic.
I think Rust should allocate the needed resources eagerly when creating a new thread, to avoid this problem.
It actually does most of the time, as always creates a . However, if the thread is created through other means, the struct needs to be lazily allocated, which can of course fail. Either way, we also need to protect against the case where fails - it should not, but who knows what some obscure system might do (the UNIX parking implementation is used on systems like L4RE and 3DS/Horizon). In general, I think it is easier for maintainability if we just always convert panics to aborts in / rather than going through every system and abstraction to ensure no panics are caused. Still, this is possible to do in the future (as is returning instantly).
I just tripped over an issue in this area. I'm trying to put together a userspace mutex for learning and it works fine apart from when there is a panic. If there has been a panic, then I get a panic when handling panic and fall over with this stack trace: Note that at 18, some destructors are run, that appear to be releasing Thread local storage. By the time I try to run , at 7, the thread is already invalid (although , I don't know that). I tried: But, I get the same problem. I presume because of raciness between the check for panicking and the panic actually starting.
It looks like you're implementing a global allocator using your thread::park_timeout-based mutex? That's going to be problematic, since the thread parking data is stored in a heap allocation (an ) that gets deallocated on thread destruction.
Thank you. I have an approach to the problem which works as a spinlock, but I was experimenting to see if I could do something more efficient using . It's one of those where I wasn't sure if it was interesting to report, but I thought I'd mention it.

imp::Thread::sleep(dur) } <ins> /// Used to ensure that `park` and `park_timeout` do not unwind, as that can /// cause undefined behaviour if not handled correctly (see #102398 for context). struct PanicGuard; impl Drop for PanicGuard { fn drop(&mut self) { rtabort!("an irrecoverable error occurred while synchronizing threads") } } </ins> /// Blocks unless or until the current thread's token is made available. /// /// A call to `park` does not guarantee that the thread will remain parked <del> /// forever, and callers should be prepared for this possibility. </del> <ins> /// forever, and callers should be prepared for this possibility. However, /// it is guaranteed that this function will not panic (it may abort the /// process if the implementation encounters some rare errors). </ins> /// /// # park and unpark ///


Question:
with synchronization assumes that does not panic. This assumption is however not correct. For instance, a panic occurs if the TLS key used to store the thread info , , , and . The code examples above all use intrusive lists and have to wait on a condition to before destroying the list nodes. If panics, the nodes will be dropped during stack unwinding without checking that condition, leading to undefined behaviour (some of these cases are in , so I'm marking this as a soundness problem with ). Fixing this would either require guarding against panics in each of these cases or ensuring that never panics. label +I-unsound +A-atomic +T-libs +T-libs-api
Thanks for bringing this up! I agree this is a problem. In general, the pattern with parking is: Unwinding would mean leaving that loop even though the condition isn't true. While code right after the loop isn't executed, there are many cases where leaving the current frame before the condition is true is problematic, as all your examples show. I think it's not reasonable to expect every user of to take this subtle pitfall into account. Instead, I believe we should guarantee that never unwinds.
All the situations in which can currently panic are very unusual things that are most likely unrecoverable errors. So I think it'd be fine to just never let unwind, and instead always on panic.
I think Rust should allocate the needed resources eagerly when creating a new thread, to avoid this problem.
It actually does most of the time, as always creates a . However, if the thread is created through other means, the struct needs to be lazily allocated, which can of course fail. Either way, we also need to protect against the case where fails - it should not, but who knows what some obscure system might do (the UNIX parking implementation is used on systems like L4RE and 3DS/Horizon). In general, I think it is easier for maintainability if we just always convert panics to aborts in / rather than going through every system and abstraction to ensure no panics are caused. Still, this is possible to do in the future (as is returning instantly).
I just tripped over an issue in this area. I'm trying to put together a userspace mutex for learning and it works fine apart from when there is a panic. If there has been a panic, then I get a panic when handling panic and fall over with this stack trace: Note that at 18, some destructors are run, that appear to be releasing Thread local storage. By the time I try to run , at 7, the thread is already invalid (although , I don't know that). I tried: But, I get the same problem. I presume because of raciness between the check for panicking and the panic actually starting.
It looks like you're implementing a global allocator using your thread::park_timeout-based mutex? That's going to be problematic, since the thread parking data is stored in a heap allocation (an ) that gets deallocated on thread destruction.
Thank you. I have an approach to the problem which works as a spinlock, but I was experimenting to see if I could do something more efficient using . It's one of those where I wasn't sure if it was interesting to report, but I thought I'd mention it.

/// [`thread::park_timeout`]: park_timeout #[stable(feature = "rust1", since = "1.0.0")] pub fn park() { <ins> let guard = PanicGuard; </ins> // SAFETY: park_timeout is called on the parker owned by this thread. unsafe { current().inner.as_ref().parker().park(); } <ins> // No panic occurred, do not abort. forget(guard); </ins> } /// Use [`park_timeout`].


Question:
with synchronization assumes that does not panic. This assumption is however not correct. For instance, a panic occurs if the TLS key used to store the thread info , , , and . The code examples above all use intrusive lists and have to wait on a condition to before destroying the list nodes. If panics, the nodes will be dropped during stack unwinding without checking that condition, leading to undefined behaviour (some of these cases are in , so I'm marking this as a soundness problem with ). Fixing this would either require guarding against panics in each of these cases or ensuring that never panics. label +I-unsound +A-atomic +T-libs +T-libs-api
Thanks for bringing this up! I agree this is a problem. In general, the pattern with parking is: Unwinding would mean leaving that loop even though the condition isn't true. While code right after the loop isn't executed, there are many cases where leaving the current frame before the condition is true is problematic, as all your examples show. I think it's not reasonable to expect every user of to take this subtle pitfall into account. Instead, I believe we should guarantee that never unwinds.
All the situations in which can currently panic are very unusual things that are most likely unrecoverable errors. So I think it'd be fine to just never let unwind, and instead always on panic.
I think Rust should allocate the needed resources eagerly when creating a new thread, to avoid this problem.
It actually does most of the time, as always creates a . However, if the thread is created through other means, the struct needs to be lazily allocated, which can of course fail. Either way, we also need to protect against the case where fails - it should not, but who knows what some obscure system might do (the UNIX parking implementation is used on systems like L4RE and 3DS/Horizon). In general, I think it is easier for maintainability if we just always convert panics to aborts in / rather than going through every system and abstraction to ensure no panics are caused. Still, this is possible to do in the future (as is returning instantly).
I just tripped over an issue in this area. I'm trying to put together a userspace mutex for learning and it works fine apart from when there is a panic. If there has been a panic, then I get a panic when handling panic and fall over with this stack trace: Note that at 18, some destructors are run, that appear to be releasing Thread local storage. By the time I try to run , at 7, the thread is already invalid (although , I don't know that). I tried: But, I get the same problem. I presume because of raciness between the check for panicking and the panic actually starting.
It looks like you're implementing a global allocator using your thread::park_timeout-based mutex? That's going to be problematic, since the thread parking data is stored in a heap allocation (an ) that gets deallocated on thread destruction.
Thank you. I have an approach to the problem which works as a spinlock, but I was experimenting to see if I could do something more efficient using . It's one of those where I wasn't sure if it was interesting to report, but I thought I'd mention it.

/// ``` #[stable(feature = "park_timeout", since = "1.4.0")] pub fn park_timeout(dur: Duration) { <ins> let guard = PanicGuard; </ins> // SAFETY: park_timeout is called on the parker owned by this thread. unsafe { current().inner.as_ref().parker().park_timeout(dur); } <ins> // No panic occurred, do not abort. forget(guard); </ins> } ////////////////////////////////////////////////////////////////////////////////


Question:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 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
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

span: Span, origin: &hir::OpaqueTyOrigin, ) { <del> let hidden_type = tcx.bound_type_of(def_id.to_def_id()).subst(tcx, substs); </del> let hir_id = tcx.hir().local_def_id_to_hir_id(def_id); let defining_use_anchor = match *origin { hir::OpaqueTyOrigin::FnReturn(did) | hir::OpaqueTyOrigin::AsyncFn(did) => did,


Question:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 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
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

let ocx = ObligationCtxt::new(&infcx); let opaque_ty = tcx.mk_opaque(def_id.to_def_id(), substs); <ins> // `ReErased` regions appear in the "parent_substs" of closures/generators. // We're ignoring them here and replacing them with fresh region variables. // See tests in ui/type-alias-impl-trait/closure_{parent_substs,wf_outlives}.rs. // // FIXME: Consider wrapping the hidden type in an existential `Binder` and instantiating it // here rather than using ReErased. let hidden_ty = tcx.bound_type_of(def_id.to_def_id()).subst(tcx, substs); let hidden_ty = tcx.fold_regions(hidden_ty, |re, _dbi| match re.kind() { ty::ReErased => infcx.next_region_var(RegionVariableOrigin::MiscVariable(span)), _ => re, }); </ins> let misc_cause = traits::ObligationCause::misc(span, hir_id); <del> match infcx.at(&misc_cause, param_env).eq(opaque_ty, hidden_type) { </del> <ins> match infcx.at(&misc_cause, param_env).eq(opaque_ty, hidden_ty) { </ins> Ok(infer_ok) => ocx.register_infer_ok_obligations(infer_ok), Err(ty_err) => { tcx.sess.delay_span_bug( span, <del> &format!("could not unify `{hidden_type}` with revealed type:n{ty_err}"), </del> <ins> &format!("could not unify `{hidden_ty}` with revealed type:n{ty_err}"), </ins> ); } }


Question:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 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
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

// Defining use functions may have more bounds than the opaque type, which is ok, as long as the // hidden type is well formed even without those bounds. let predicate = <del> ty::Binder::dummy(ty::PredicateKind::WellFormed(hidden_type.into())).to_predicate(tcx); </del> <ins> ty::Binder::dummy(ty::PredicateKind::WellFormed(hidden_ty.into())).to_predicate(tcx); </ins> ocx.register_obligation(Obligation::new(misc_cause, param_env, predicate)); // Check that all obligations are satisfied by the implementation's


Question:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 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
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

<ins> // When WF checking the hidden type in the ParamEnv of the opaque type, // one complication arises when the hidden type is a closure/generator: // the "parent_substs" of the type may reference lifetime parameters // not present in the opaque type. // These region parameters are not really useful in this check. // So here we ignore them and replace them with fresh region variables. // check-pass #![feature(type_alias_impl_trait)] #![allow(dead_code)] // Basic test mod test1 { // Hidden type = Closure['_#0r] type Opaque = impl Sized; fn define<'a: 'a>() -> Opaque { || {} } } // the region vars cannot both be equal to `'static` or `'empty` mod test2 { trait Trait {} // Hidden type = Closure['a, '_#0r, '_#1r] // Constraints = [('_#0r: 'a), ('a: '_#1r)] type Opaque<'a> where &'a (): Trait, = impl Sized + 'a; fn define<'a, 'x, 'y>() -> Opaque<'a> where &'a (): Trait, 'x: 'a, 'a: 'y, { || {} } } // the region var cannot be equal to `'a` or `'b` mod test3 { trait Trait {} // Hidden type = Closure['a, 'b, '_#0r] // Constraints = [('_#0r: 'a), ('_#0r: 'b)] type Opaque<'a, 'b> where (&'a (), &'b ()): Trait, = impl Sized + 'a + 'b; fn define<'a, 'b, 'x>() -> Opaque<'a, 'b> where (&'a (), &'b ()): Trait, 'x: 'a, 'x: 'b, { || {} } } fn main() {} </ins>


Question:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 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
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

<ins> // If the hidden type is a closure, we require the "outlives" bounds that appear on the // defining site to also appear on the opaque type. // // It's not clear if this is the desired behavior but at least // it's consistent and has no back-compat risk. // check-fail #![feature(type_alias_impl_trait)] #![allow(dead_code)] // requires `'a: 'b` bound mod test1 { type Opaque<'a, 'b> = impl Sized + 'a + 'b; //~^ ERROR lifetime bound not satisfied fn define<'a, 'b>() -> Opaque<'a, 'b> where 'a: 'b, { || {} } } // Same as the above but through indirection `'x` mod test2 { type Opaque<'a, 'b> = impl Sized + 'a + 'b; //~^ ERROR cannot infer an appropriate lifetime fn define<'a, 'b, 'x>() -> Opaque<'a, 'b> where 'a: 'x, 'x: 'b, { || {} } } // fixed version of the above mod test2_fixed { type Opaque<'a: 'b, 'b> = impl Sized + 'a + 'b; fn define<'a, 'b, 'x>() -> Opaque<'a, 'b> where 'a: 'x, 'x: 'b, { || {} } } // requires `T: 'static` mod test3 { type Opaque<T> = impl Sized; //~^ ERROR the parameter type `T` may not live long enough fn define<T>() -> Opaque<T> where T: 'static, { || {} } } fn main() {} </ins>


Question:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 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
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

<ins> error[E0478]: lifetime bound not satisfied --> $DIR/closure_wf_outlives.rs:14:27 | LL |     type Opaque<'a, 'b> = impl Sized + 'a + 'b; |                           ^^^^^^^^^^^^^^^^^^^^ | note: lifetime parameter instantiated with the lifetime `'a` as defined here --> $DIR/closure_wf_outlives.rs:14:17 | LL |     type Opaque<'a, 'b> = impl Sized + 'a + 'b; |                 ^^ note: but lifetime parameter must outlive the lifetime `'b` as defined here --> $DIR/closure_wf_outlives.rs:14:21 | LL |     type Opaque<'a, 'b> = impl Sized + 'a + 'b; |                     ^^ error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements --> $DIR/closure_wf_outlives.rs:27:27 | LL |     type Opaque<'a, 'b> = impl Sized + 'a + 'b; |                           ^^^^^^^^^^^^^^^^^^^^ | note: first, the lifetime cannot outlive the lifetime `'a` as defined here... --> $DIR/closure_wf_outlives.rs:27:17 | LL |     type Opaque<'a, 'b> = impl Sized + 'a + 'b; |                 ^^ note: ...so that the declared lifetime parameter bounds are satisfied --> $DIR/closure_wf_outlives.rs:27:27 | LL |     type Opaque<'a, 'b> = impl Sized + 'a + 'b; |                           ^^^^^^^^^^^^^^^^^^^^ note: but, the lifetime must be valid for the lifetime `'b` as defined here... --> $DIR/closure_wf_outlives.rs:27:21 | LL |     type Opaque<'a, 'b> = impl Sized + 'a + 'b; |                     ^^ note: ...so that the declared lifetime parameter bounds are satisfied --> $DIR/closure_wf_outlives.rs:27:27 | LL |     type Opaque<'a, 'b> = impl Sized + 'a + 'b; |                           ^^^^^^^^^^^^^^^^^^^^ error[E0310]: the parameter type `T` may not live long enough --> $DIR/closure_wf_outlives.rs:54:22 | LL |     type Opaque<T> = impl Sized; |                      ^^^^^^^^^^ ...so that the type `T` will meet its required lifetime bounds... | note: ...that is required by this bound --> $DIR/closure_wf_outlives.rs:59:12 | LL |         T: 'static, |            ^^^^^^^ help: consider adding an explicit lifetime bound... | LL |     type Opaque<T: 'static> = impl Sized; |                  +++++++++ error: aborting due to 3 previous errors Some errors have detailed explanations: E0310, E0478, E0495. For more information about an error, try `rustc --explain E0310`. </ins>


Question:
While working on an experimental runtime and using a couple of experimental features I found that the compiler while in resolving the async call on a trait crash badly. This is a minimal reproducible example and this is the stacktrace generated N.B: I guess this happens with any runtime? BTW also if happens only with rio the compiler should not crash, but I do not think this is related to a specific runtime, but I guess instead, the runtime triggers the resolution of the futures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +T-compiler
In the meanwhile, I will try to swim inside the codebase to catch the problem! claim
this is fixed by .
Minimized so it doesn't depend on rio:
Cool great work :)

let ocx = ObligationCtxt::new(infcx); let norm_cause = ObligationCause::misc(return_span, impl_m_hir_id); <del> let impl_return_ty = ocx.normalize( </del> <ins> let impl_sig = ocx.normalize( </ins> norm_cause.clone(), param_env, <del> infcx .replace_bound_vars_with_fresh_vars( return_span, infer::HigherRankedType, tcx.fn_sig(impl_m.def_id), ) .output(), </del> <ins> infcx.replace_bound_vars_with_fresh_vars( return_span, infer::HigherRankedType, tcx.fn_sig(impl_m.def_id), ), </ins> ); <ins> let impl_return_ty = impl_sig.output(); </ins> let mut collector = ImplTraitInTraitCollector::new(&ocx, return_span, param_env, impl_m_hir_id); <del> let unnormalized_trait_return_ty = tcx </del> <ins> let unnormalized_trait_sig = tcx </ins> .liberate_late_bound_regions( impl_m.def_id, tcx.bound_fn_sig(trait_m.def_id).subst(tcx, trait_to_placeholder_substs), ) <del> .output() </del> .fold_with(&mut collector); <del> let trait_return_ty = ocx.normalize(norm_cause.clone(), param_env, unnormalized_trait_return_ty); </del> <ins> let trait_sig = ocx.normalize(norm_cause.clone(), param_env, unnormalized_trait_sig); let trait_return_ty = trait_sig.output(); </ins> <del> let wf_tys = FxHashSet::from_iter([unnormalized_trait_return_ty, trait_return_ty]); </del> <ins> let wf_tys = FxHashSet::from_iter( unnormalized_trait_sig.inputs_and_output.iter().chain(trait_sig.inputs_and_output.iter()), ); </ins> match infcx.at(&cause, param_env).eq(trait_return_ty, impl_return_ty) { Ok(infer::InferOk { value: (), obligations }) => {


Question:
While working on an experimental runtime and using a couple of experimental features I found that the compiler while in resolving the async call on a trait crash badly. This is a minimal reproducible example and this is the stacktrace generated N.B: I guess this happens with any runtime? BTW also if happens only with rio the compiler should not crash, but I do not think this is related to a specific runtime, but I guess instead, the runtime triggers the resolution of the futures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +T-compiler
In the meanwhile, I will try to swim inside the codebase to catch the problem! claim
this is fixed by .
Minimized so it doesn't depend on rio:
Cool great work :)

} } <ins> // Unify the whole function signature. We need to do this to fully infer // the lifetimes of the return type, but do this after unifying just the // return types, since we want to avoid duplicating errors from // `compare_predicate_entailment`. match infcx .at(&cause, param_env) .eq(tcx.mk_fn_ptr(ty::Binder::dummy(trait_sig)), tcx.mk_fn_ptr(ty::Binder::dummy(impl_sig))) { Ok(infer::InferOk { value: (), obligations }) => { ocx.register_obligations(obligations); } Err(terr) => { let guar = tcx.sess.delay_span_bug( return_span, format!("could not unify `{trait_sig}` and `{impl_sig}`: {terr:?}"), ); return Err(guar); } } </ins> // Check that all obligations are satisfied by the implementation's // RPITs. let errors = ocx.select_all_or_error();