Skip to content

Safer Exceptions throws clauses have stopped working #17040

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
reftrans opened this issue Mar 3, 2023 · 6 comments
Open

Safer Exceptions throws clauses have stopped working #17040

reftrans opened this issue Mar 3, 2023 · 6 comments

Comments

@reftrans
Copy link

reftrans commented Mar 3, 2023

Compiler version

The problem is introduced in e422066.

Minimized code

import language.experimental.saferExceptions
def fail(): Unit throws Exception = throw Exception()

Output

3 |def fail(): Unit throws Exception = throw Exception()
  |                                    ^^^^^^^^^^^^^^^^^
  |                                    The capability to throw exception Exception is missing.
  |                                    The capability can be provided by one of the following:
  |                                     - Adding a using clause `(using CanThrow[Exception])` to the definition of the enclosing method
  |                                     - Adding `throws Exception` clause after the result type of the enclosing method
  |                                     - Wrapping this piece of code with a `try` block that catches Exception
  |
  |                                    The following import might fix the problem:
  |
  |                                      import unsafeExceptions.canThrowAny
  |
1 error found

It compiles normally with a using CanThrow[Exception] clause instead of throws Exception.

Expectation

Same behavior as for using clause.

@reftrans reftrans added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Mar 3, 2023
@odersky odersky added area:experimental:erased-definitions and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Mar 5, 2023
@natsukagami
Copy link
Contributor

Can you provide me with more details?
I cannot produce a compilation error with your minimized example (both on e422066 and on latest main)

@reftrans
Copy link
Author

reftrans commented Mar 7, 2023

I tried it again, and it was still broken for me so I looked a bit deeper: The problem is reproducible only after an incremental build of Dotty from an earlier commit. The following should show the problem with fail.scala is the minimised code above:

# inside lampepfl/dotty repo:
git checkout f02f7dda64
bin/scalac fail.scala
# builds previous version of scalac and compiles successfully
git checkout e422066c3d
bin/scalac fail.scala
# builds "next" version of scalac and and shows the error message above

I was able to avoid the problem by cloning a fresh Dotty repository and rebuilding from clean.

So, you're right, the error is not reproducible in general. Sorry for wasting your time, @natsukagami. Hopefully this is useful for anyone else who is building Dotty from source, though.

@reftrans reftrans closed this as completed Mar 7, 2023
@natsukagami
Copy link
Contributor

natsukagami commented Mar 7, 2023 via email

@odersky
Copy link
Contributor

odersky commented Mar 7, 2023

One should never require a clean build. Something must be wrong with the logic that requires this. It's usually some piece of state that should not exist.

@odersky odersky reopened this Mar 7, 2023
@natsukagami
Copy link
Contributor

What happened was that the cached $throws[T, E] in the library was previously compiled into scala.ErasedContextFunction1[CanThrow[E], T]; and is compiled into a scala.runtime.ErasedFunction now.
I wonder how would the incremental compilation would deal with this (since there is no change to the library, just how it was compiled).
In fact, following the above mentioned step with a definition that would not throw a TypeError, such as

import language.experimental.saferExeptions

def fail: Int throws Exception = ???

will cause the compiler to crash, since scala.ErasedContextFunction1 is no longer a thing.

@natsukagami
Copy link
Contributor

I think this is a TASTy incompatibility problem...?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants