-
Notifications
You must be signed in to change notification settings - Fork 280
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
Remove warnings #1994
base: main
Are you sure you want to change the base?
Remove warnings #1994
Conversation
As compiler option is used for the same effect. The advantage is that removing these import get rid of unused import messages.
Modify the code where it is possible. Add the scalac option -no-link-warnings for the remaining warnings.
The only breaking thing here is that it used to throw a |
På lørdag 11. desember 2021 kl. 14:48:52, skrev Antonio Salazar Cardozo <
***@***.*** ***@***.***>>:
Add default case in pattern matching, by throwing an IllegalArgumentException
exception, to satisfy the compiler. This could be a breaking change? Better to
add ***@***.*** <https://github.com/unchecked> annotation?
The only breaking thing here is that it used to throw a scala.MatchError. Can
we throw that explicitly instead ofIllegalArgumentException, or is that error
also deprecated?
I'd go for @unchecked
…--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
***@***.*** ***@***.***>
www.visena.com <https://www.visena.com>
<https://www.visena.com>
|
I didn't think of using MatchError. It is not deprecated and it could be used instead of IllegalArgumentException. I'll wait the decision between @unchecked and an exception, and change the code accordingly. |
Replace the added default case in pattern matching throwing an IllegalArgumentException by an unchecked annotation. Let the runtime throw the standard MatchError as previously, if the case ever happens.
I replaced throwing of IllegalArgumentException by the @unchecked annotation, for non exhaustive pattern matches. I updated the pull request comment. This lets the runtime throw the MatchError exception as previously. |
Previously, pf4 was just created and his type was given. So I suppose that the check is if it has the correct type. The check is now added explicitely.
Do you have any updates on this PR? I'm looking forward to use Lift with Scala 3. |
No, I didn't put more time in this PR. I am waiting a reaction from the Lift maintainers, which don't have time to work on this project anymore. My purpose was also to use Lift with Scala 3. I was hopping that this PR would be integrated in the master branch, as a first step. By the way, I think that libraries compiled with Scala 2.13 can be used with Scala 3. So it depends on which modules of Lift you need. The basic modules compile fine in Scala 3. The squeryl modules cannot be compiled for Scala 2.13, it must first be adapted to a more recent version of squeryl. In the persistence module, I only use db (I was using Mapper but I removed it, using my own code). |
Currently we only need the core and webkit modules. Maybe it is also possible to create some kind of "lift-light" that does not include any of the database extensions. |
I'll spend some time on this PR this week |
@dpp That's excellent news! It'd be awesome to have Lift working with Scala-3. |
If I can do more to advance this PR, don't hesitate to ask. |
@dpp @Shadowfiend Can this PR be merged? |
I don't expect anymore that this PR will be included in the master branch of the main repository. On my fork, I created a new branch |
It's a shame nobody has time for this, me included. Please don't give up on this:-) I have some suggested changes to Lift in my local fork which I'd also like to have included. It'd be really cool if we could team up and get Lift ready for use with Scala >= 3.2. My company would be willing to sponsor work on this. |
Mailing List thread:
The purpose of this pull request is to remove as much warnings as possible. This pull request is maybe a bit huge.
A summary of the modifications made: