Deprecation warnings for old syntax: var x = _
#18821
Conversation
nicolasstucki
force-pushed
the
uninitialized-migration-warning
branch
from
3b6b55f
to
a748129
Compare
nicolasstucki
changed the title
var syntax a migration warningvar x = _
This comment was marked as outdated.
This comment was marked as outdated.
nicolasstucki
force-pushed
the
uninitialized-migration-warning
branch
from
a748129
to
0343a75
Compare
|
In this week's Dotty meeting we decided to do the rewrite as it is implemented here. |
nicolasstucki
changed the title
var x = _ var x = _
nicolasstucki
force-pushed
the
uninitialized-migration-warning
branch
4 times, most recently
from
bb3e2f9
to
cfe81d4
Compare
project/Build.scala
Outdated
| @@ -578,7 +578,8 @@ object Build { | |||
| lazy val commonDottyCompilerSettings = Seq( | |||
| // Note: bench/profiles/projects.yml should be updated accordingly. | |||
| Compile / scalacOptions ++= Seq("-Yexplicit-nulls", "-Ysafe-init"), | |||
|
|
|||
| // Use source 3.3 to avoid fatal migration warnings on scalajs-ir | |||
| scalacOptions ++= Seq("-source", "3.3"), | |||
There was a problem hiding this comment.
@sjrd where can I add this options to enable them only when compiling the scalajs-ir?
See https://github.com/lampepfl/dotty/actions/runs/6784134103/job/18439824856
There was a problem hiding this comment.
I don't think you can. The scalajs-ir sources are built as part of scala3-compiler itself, so they must share their flags.
nicolasstucki
force-pushed
the
uninitialized-migration-warning
branch
from
cfe81d4
to
8d922ff
Compare
nicolasstucki
force-pushed
the
uninitialized-migration-warning
branch
from
8d922ff
to
5c35b48
Compare
nicolasstucki
force-pushed
the
uninitialized-migration-warning
branch
2 times, most recently
from
252b4b6
to
b80e474
Compare
* In `3.4` we emit the deprecation warning * In `future` we emit we make this syntax an error * Add patch. Not ideal because we need to use the full path of `uninitialized`
nicolasstucki
force-pushed
the
uninitialized-migration-warning
branch
from
b80e474
to
951bbae
Compare
|
I know this is pretty after-the-fact, but this change did remove the unique error id that was associated with this error in the past, which was sort of a bummer. Since now if there was any automated tooling that could try to fix this that was utilizing that before, it's not longer present. 
In the future as these are done, could they be done in a way that still retains the unique error id or adds a new one if it now has a new meaning. If not all the work that went into ensuring that these unique ids were there across the entire ecosystem was sort of for nothing. EDIT: I know this was probably not done intentionally. I just bring it up since it'd be great to have something that prevented this sort of thing. |
First part #18861
3.4we emit the deprecation warningfuturewe emit we make this syntax an erroruninitialized