Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Rewriting tool should warn on extending DelayedInit
See original GitHub issueOut of 1500 run tests that fail, 900 fail due to them extending scala.App, which relies on DelayedInit, that is not supported.
Issue Analytics
- State:
- Created 8 years ago
- Comments:26 (19 by maintainers)
Top Results From Across the Web
Allow by-name repeated parameters · Issue #499 - GitHub
But I can't see a good reason why this combination should be disallowed. ... Rewriting tool should warn on extending DelayedInit #559.
Read more >Scala 3.0.0-RC1 – first release candidate is here - EPFL
Allow secondary type parameter list in extension methods ... As the warning suggests, now you should write Foo.apply instead of Foo .
Read more >Scala Compiler Options
In Scala 2, default paths can be listed by running a tool in the ... Emit warning and location for usages of features...
Read more >6 Best Content Rewriter Tools To Try In 2022 - TextCortex AI
Chrome extension - You can rewrite right within any platform without going from one platform to another. Saving up to 80% of rewriting...
Read more >Useful Scala Compiler Options (Part 3) - DZone
As we have seen before, this warning can be triggered by trying to pass a ... class PGRow extends Row { override def...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Maybe we can allow top-level methods in some form (e.g. automatically wrap them into objects internally). This way it won’t be confusing and will still be low-overhead syntax-wise.
Good catch @sjrd I opened https://github.com/scalacenter/scalafix/issues/215, let’s move the discussion there. It should be possible to keep overriden members in the object’s template body, although care needs to be taken with eagerly evaluated vals/vars.