kennytm

I think we only need one more LGTM from `sig-approver-parser` i.e. @bb7133 / @BornChanger / @tangenta ? Or do we also need additional approval from `sig-critical-approvers-parser` i.e. @yudongusa / @easonn7...

looks like approval from `sig-critical-approvers-parser` is required.

> `use … in` note that if an additional indentation + lexical scope is acceptable you could already do ```rust let foo = { use std::cmp::Ordering::*; Foo { a: Greater,...

> ... detecting infinite loops. there are two kinds of "non-totality" (expressions with type `!`, excluding `return`/`break`/`continue`) 1. those that kills the execution: `panic!()`, `abort()`, `exit()`, infinite recursion (stack overflow)...

> `bit_width` can be used to calculate the index of the most significant set bit with `num.bit_width() - 1` (if nonzero). This is just [`num.ilog2()`](https://doc.rust-lang.org/std/primitive.usize.html#method.ilog2).

I think `prev_power_of_two` makes sense but like `next_power_of_two` there should be checked/wrapping variants regarding 0. | u64 | prev_power_of_two | checked_prev_power_of_two | wrapping_prev_power_of_two | |-|-|-|-| | 264 - 1 |...

While it is not spelled out, I suppose unpacking `...expr` to the surrounding which *length is not uniquely determined* is still allowed when type of `expr` is known, right? Example...

I hope that this won't affect feasibility of #2884 (basically unsized_return).

> ```rust > pub (crate if cfg!(not(feature = "internals"))) mod internal_api { > ``` Maybe more natural as ```rust pub(#[cfg(not(feature = "internals"))] crate) mod internal_api ``` assuming we accept `pub()`...

> So even in an attribute, I'd argue that `&&` should have higher precedence than the `key=value` operator. But that's the opposite of what this RFC proposes. GitHub really needs...