For troubleshooting compiler, add -Vdebug-type-error (and remove -Yissue-debug)

[tribbloid]

-Vdebug-type-error prints a stacktrace if an error is discovered inside a typer context

-Yissue-debug has been removed because it has no effect on compiler's behavior

[tribbloid]

Oops, looks like my test condition is too rigorous (the stacktrace has to be identical every time), is there a way in DirectTest to make validation looser? (e.g. by only matching the first few rows)

[tribbloid]

muhaha, found the solution (filter: header). Should pass this time

[tribbloid]

Nice, all passed. I only have one test case:

object Example
{
  val a: org.dummy.Dummy = ???
}

@lrytz @ira19921 : should I add more?

[som-snytt]

I have forgotten again how -Wconf works (sorry @lrytz !) but a different idea is to make tracing an action like "silent" so that I could specify a Wconf that shows a trace, -Wconf:cat=something:t would mean show me a compiler stack trace when that message is issued. Then an option -Werror-trace (which I have renamed, apologies in advance) would just augment the -Wconf config.

The problem is that warnings are issued lazily, so capturing stack trace context might require a few LOC.

Whether to use -Y or -W suggests asking if it is "private to EPFL" or "a useful tool for warning about things". I propose the latter. Maybe rewrite all the options as -U if they are useful (kidding of course!).

[lrytz]

I don't think a compiler stack trace should be part of Wconf, it's something that should only be useful to compiler (and maybe plugin) devs. So in principle -Y seems good, though the other debug options we have are -V.

So I'd go for -Vdebug-typer-errors (debug-error seems a bit too generic).

[tribbloid]

Sounds easy. Just want to remind you that dotty is already using -Ydebug-error. Should we maintain that consistency just to facilitate cross-compilation build?

…

________________________________ From: Lukas Rytz ***@***.***> Sent: Wednesday, December 15, 2021 5:35:32 AM To: scala/scala ***@***.***> Cc: Peng Cheng ***@***.***>; State change ***@***.***> Subject: Re: [scala/scala] Add "-Ydebug-error" option and delete "-Yissue-debug" option of scala compiler (PR #9824) I don't think a compiler stack trace should be part of Wconf, it's something that should only be useful to compiler (and maybe plugin) devs. So in principle -Y seems good, though the other debug options we have are -V. So I'd go for -Vdebug-typer-errors (debug-error seems a bit too generic). — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub<https://protect-au.mimecast.com/s/AFP_C6XQ88i0oD0Ecpj1K7?domain=github.com>, or unsubscribe<https://protect-au.mimecast.com/s/YAY2C71R33TVmqVvSW1wiy?domain=github.com>.

[lrytz]

dotty is already using -Ydebug-error

I wasn't aware, thanks. Unfortunately there's still mismatch between the flags of Scala 2 and 3. A cleanup of Scala 2 flags (which introduced -V) happened after Scala 3 forked off, and that's still missing.

So either we align with Scala 3 but use the old scheme (-Y), or we align with the other Scala 2 flags and use the new scheme (-V). Since this flag is not intended for wide use or cross-building, I think we better do the latter.

[som-snytt]

FWIW, my rule for -V: was it something a user might enable? -Vtyper? It's a category of verbose options to ask for more output, even if it's just to post it in a ticket. Then -Y is for behaviors.

[tribbloid]

@lrytz sounds like a good idea. should I ask the feature owner from dotty team for their roadmap? (Or you have already done so)

[SethTisue]

I'm firmly in favor of the -V route here. Alignment can come later on the Scala 3 side.

@tribbloid Since it seems this will be merged, and it'll be in the release notes, can you write a nice user-facing PR description?

[tribbloid]

@SethTisue sorry for the late reply. Yes I'll do BOTH immediately.

I trust your roadmap and coordination with the Scala 3 team.

[tribbloid]

DONE. Hope the new PR title meets your standard.

I still have 2 questions:

1. In ScalaSettings, Should the withAbbreviation "-Ydebug-type-error" be added?
2. In ScalaOptionParser.booleanSettingNames, only the token "-Ydebug" is defined, should it also include "-Ydebug-tasty" which is another abbreviation?

[SethTisue]

Can you edit the PR description to indicate why -Yissue-debug was removed?

[tribbloid]

No problem. The only reason is that it wasn’t used anywhere in the code

…

________________________________ From: Seth Tisue ***@***.***> Sent: Saturday, February 19, 2022 9:27:16 PM To: scala/scala ***@***.***> Cc: Peng Cheng ***@***.***>; Mention ***@***.***> Subject: Re: [scala/scala] For troubleshooting compiler, add `-Vdebug-type-error` (and remove `-Yissue-debug`) (PR #9824) Can you edit the PR description to indicate why -Yissue-debug was removed? — Reply to this email directly, view it on GitHub<https://protect-au.mimecast.com/s/f3BpC5QPyyHpGjv3UzWtUN?domain=github.com>, or unsubscribe<https://protect-au.mimecast.com/s/Xk_vC6XQ88i0KOD7U6wQM5?domain=github.com>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[tribbloid]

@SethTisue thanks a lot, hope it looks ready now

[SethTisue]

I think we've been making edits at cross-purposes because I haven't been precise in my wording. I'm not sure what the official terminology is, but to me the "PR description" is the top comment, separately from the PR's "title".

We like to keep the title short and sweet, and then explain further in the description.

[SethTisue]

I think the title is now good, but the description could use more explanation and perhaps an example. Imagine you're a random Scala programmer and you've never heard of this new flag before and you have no idea whether you even need to know about it, and when you might want to use it, and what it will do if enabled.

Who is this new flag useful for? Is it only useful to compiler hackers? If so, you should say that (and we probably won't release-note it). Note that "Inside a typer context" isn't meaningful to the average Scala programmer, that's compiler-hacker talk.

The PR description should explain all of that, at least briefly. You can go on at length at you want, but the minimum we're looking for is a paragraph or two that answers these questions.

If it's only useful to compiler hackers, less documentation is needed. But if it's sometimes useful to end users, it's important to write something that is clear for that audience.

[som-snytt]

I guess the difference between -V and -Y is that Seth goads us into producing doc for -V.

[tribbloid]

Sorry hope it is not too late to change the PR description (wasn't able to find that option in github web UI).

@som-snytt I already have a short description in the code:

  val VdebugTypeError = BooleanSetting("-Vdebug-type-error", "Print the stack trace when any error is caught.") withAbbreviation "-Ydebug-type-error"

Other descriptions in the sourcecode are identical to the doc at https://docs.scala-lang.org/overviews/compiler-options/index.html. SO I assume that the later was compiled from the former. I wasn't able to successfully Google any longer version. So at this moment I'm going to assume that it will only exist in the PR or the release note

[SethTisue]

hope it is not too late to change the PR description

not too late! you should see a pencil icon, like this:

if you don't, that could be because I'm running Refined GitHub, so I'm never sure whether what I'm seeing was tweaked by that or not. but even if you don't see the pencil icon, there should be an "Edit" option in the little "..." menu next to it

So at this moment I'm going to assume that it will only exist in the PR or the release note

in the long run, hopefully we'll copy the PR description into the compiler options doc, but our automation for updating that doc isn't working currently, as per scala/docs.scala-lang#1711, so at the moment there's no point in doing that