Frank Steffahn

I’ve started working on differentiating between constructors and non-constructors, however, it’s running into problems in the ui test that runs `rustc` with `RUSTC_LOG=debug`, i.e. `src/test/ui/rustc-rust-log.rs`. Some kind of infinite looping...

Indeed, I just overlooked `DefKind::AssocFn`. I’ll push new commits soon, and then upload screenshots of the highlighting, too. For now, I’ve used `[constructor of {Foo}: fn() -> Foo]`-style printing for...

Here’s screenshots: ```rs fn foo() { fn f() {} fn g() {} fn g2() -> u8 { 0 } fn g3(_: u8) {} fn h() {} fn h2(_: T) {}...

CI is passing @rustbot ready I can re-order and squash some commits before merging if that’s desired

> All those "bless"/"update" commits could get squashed into their parents, since those aren't really functional changes. I know. Also the multiple iterations on the highlighting logic aren’t really valuable...

@compiler-errors Upon second read, what do you mean “into their parents”? I think it makes it *easier* to understand what’s going on if automatically-generated changes by `--bless` are kept separate...

I just recalled why I remembered the highlighting logic that’s supposed to make comparing something like `fn(u8)` to `[fn item {foo}: fn()]` easier (in this case by highlighting the parentheses...

Oh well… I think “fixing” the logic becomes unnecessarily complicated. For more context, I thought that a diff like fn() \[fn item {foo}: fn(u32)] would be nicer than fn() \[fn...

Screenshots, updated (same tests as before… perhaps some are slightly redundant now, since those were designed to *also* showcase some cases of the parentheses-highlighting logic, but more tests don’t hurt):...

> It seems like [the output for the case in line 17 is slightly easier to understand today](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3dabd539a774ac2b921602700db04045) than with the new output. I think we can improve the output...