Skip to content
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

Merged
merged 1 commit into from
Mar 6, 2024

Conversation

sjrd
Copy link
Member

@sjrd sjrd commented Mar 4, 2024

/cc @lbialy.

@sjrd sjrd requested review from SethTisue and Kordyjan March 4, 2024 17:11
Copy link
Contributor

@lbialy lbialy left a 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.
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo

Suggested change
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Contributor

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?

Suggested change
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.

@sjrd sjrd force-pushed the post-mortem-3.3.2 branch from a682387 to e17291f Compare March 5, 2024 08:25
@sjrd
Copy link
Member Author

sjrd commented Mar 5, 2024

All suggested changes applied. :)

@sjrd sjrd force-pushed the post-mortem-3.3.2 branch from e17291f to bb35692 Compare March 5, 2024 12:36
@sjrd sjrd requested a review from bishabosha March 5, 2024 12:36
@sjrd sjrd force-pushed the post-mortem-3.3.2 branch from bb35692 to 880c1ac Compare March 5, 2024 12:42
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

@sjrd sjrd force-pushed the post-mortem-3.3.2 branch from 880c1ac to cf4d088 Compare March 6, 2024 16:22
@sjrd sjrd merged commit d91a158 into scala:main Mar 6, 2024
1 check passed
@sjrd sjrd deleted the post-mortem-3.3.2 branch March 6, 2024 16:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants