-
Notifications
You must be signed in to change notification settings - Fork 322
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
Add blog post on the Scala 3.3.2 post-mortem. #1603
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor grammar related things, otherwise lgtm.
As we mentioned in the previous section, the main point of failure was a lack of tests for forward compatibility scenarios. | ||
Our most important fix to the process will therefore be to add adequate forward compatibility tests in the compiler's test suite. | ||
|
||
In addition, this particular bug highlights the importance of accurately following the specificiation of the TASTy format. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specification
|
||
## Conclusion | ||
|
||
In this post, we examined in detail the bug and events that led to the abandon of the Scala 3.3.2 release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Abandonment? To 3.3.2 being abandoned?
Between 3.3.1 and 3.3.2, we merged [PR #18280](https://github.com/lampepfl/dotty/pull/18280). | ||
That PR starts with what appeared to be a *refactoring* commit that renamed some `NameKind`s and their associated strings. | ||
Unfortunately, that means the 3.3.2 compiler started emitting `UniqueName`s with the string `"contextual$"`. | ||
When the 3.3.1 compiler reads that structured name, it tries to find the cached instance of `NameKind` that it should use for `"constextual$"`, and does not find any, because it did not use to generate that string. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo
When the 3.3.1 compiler reads that structured name, it tries to find the cached instance of `NameKind` that it should use for `"constextual$"`, and does not find any, because it did not use to generate that string. | |
When the 3.3.1 compiler reads that structured name, it tries to find the cached instance of `NameKind` that it should use for `"contextual$"`, and does not find any, because it did not use to generate that string. |
The RC cycles failed to surface the issue as well, for a similar reason. | ||
When trying out an RC, users rarely publish the product, even locally, then use it with an older compiler. | ||
|
||
Fortunately, as a last line of defense, the issue was caught by the Play! framework, in-between the release of the 3.3.2 artifacts on Maven Central and the official announcement of the release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fortunately, as a last line of defense, the issue was caught by the Play! framework, in-between the release of the 3.3.2 artifacts on Maven Central and the official announcement of the release. | |
Fortunately, as a last line of defense, the issue was caught by the Play Framework, in-between the release of the 3.3.2 artifacts on Maven Central and the official announcement of the release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe reference the GitHub issue?
Fortunately, as a last line of defense, the issue was caught by the Play! framework, in-between the release of the 3.3.2 artifacts on Maven Central and the official announcement of the release. | |
Fortunately, as a last line of defense, [the issue was caught](https://github.com/playframework/playframework/issues/12418) by the Play Framework in-between the release of the 3.3.2 artifacts on Maven Central and the official announcement of the release. |
All suggested changes applied. :) |
For example, the name of the class behind an `object Foo` definition has a structured name `ModuleClass("Foo")`, instead of the string `"Foo$"`. | ||
|
||
Likewise, generated names for anonymous entites, such as `implicit` parameters, have the structured name `UniqueName("evidence$", 1)`. | ||
The string `"evidence$"` used in the equality definition of names, so that `UniqueName("evidence$", 1)` is not the same name as `UniqueName("foo$", 1)`, but it does not otherwise have any semantic meaning in TASTy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The string `"evidence$"` used in the equality definition of names, so that `UniqueName("evidence$", 1)` is not the same name as `UniqueName("foo$", 1)`, but it does not otherwise have any semantic meaning in TASTy. | |
The string `"evidence$"` is used in the equality definition of names, so that `UniqueName("evidence$", 1)` is not the same name as `UniqueName("foo$", 1)`, but it does not otherwise have any semantic meaning in TASTy. |
Our most important fix to the process will therefore be to add adequate forward compatibility tests in the compiler's test suite. | ||
|
||
In addition, this particular bug highlights the importance of accurately following the specification of the TASTy format. | ||
Making additional assumptions on the *origin* of TASTy file---namely that only our own compiler can produce them---leads to problems like this issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making additional assumptions on the *origin* of TASTy file---namely that only our own compiler can produce them---leads to problems like this issue. | |
Making additional assumptions on the *origin* of TASTy files---namely that only our own compiler can produce them---leads to problems like this issue. |
/cc @lbialy.