Guillaume Martres

> It only sees A because the compiler aggressively dealiases the type projection to A That may be the case, but have you double-checked that Zinc is not the one...

> Zinc will fail because internal changes via ExtractAPI are not considered for the first iteration of the incremental compiler (when all the modified sources are compiled). I'm not exactly...

We constant fold in FirstTransform after pickler, but I don't see how constant folding is involved in the example you give, do you have a link to the "original code"...

OK, I understand what you mean now, it's just that we're using different vocabulary here. In the compiler, we *dealias* types but we *constant fold* terms and those are completely...

> should we take ownership of the full effort? Please go ahead and do that if you're interested!

I don't understand why this issue was closed. Regardless of which rules should be used the problem here is that metals-vscode overwrites any rule set by vscode-scala-syntax. The solution is...

> I am not sure if we should migrate it all to Scala syntax? I'm pretty sure we should, this is about syntax support and is completely independent of metals.

Especially now that scala is indentation-based, it's important that editors support scala editing correctly regardless of whether metals is enabled or not (for example, when editing code in a web-based...

Work is required in both repositories as mentioned in this issue: > Step 1 is to get a language-configuration.json in vscode-scala-syntax with the scaladoc rules, step 2 will be to...

> it could be Scala 3.0 or Scala 3.1. Note that Scala 3.1 won't break backwards binary-compatibility with Scala 3.0 (cf https://github.com/lampepfl/dotty/issues/10244)