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

Preparations before reading Java annotations #388

Merged
merged 6 commits into from
Nov 18, 2023

Conversation

sjrd
Copy link
Contributor

@sjrd sjrd commented Nov 14, 2023

No description provided.

sjrd added 4 commits November 14, 2023 16:43
There is only ever one `ConstantPool` per class file, so all these
singleton type parameters are type-level busywork more than any
real added safety.
We basically fuse the content of the old loop into `loadMembers()`
and then into `createMember()`. There was no reason to buffer the
list of read members in the middle.

This has the added benefit that we can accurately compute
`isSignaturePolymorphic` from the start, rather than guessing-and-
checking.
Its body consisted of an only immediately-applied local def. We
inline the def to get rid of the artificial nesting.
@sjrd sjrd requested a review from bishabosha November 14, 2023 17:22
sjrd added 2 commits November 15, 2023 10:26
It did not contain any own state, so the singleton object is
enough.
First, we read the structure of a classfile, independently of its
class kind.

Then, for a top-level class, we detect its class kind. At that
point, we only look at the `Scala`, `ScalaSig` and `TASTY`
attributes. We do not store any reference to other specific
attributes.

Third, the Loaders switch on the kind to use the appropriate
loading functions. The loading function for Scala 2 rescans the
attributes to find the signature annotation. The loading function
for Java creates a map of all the available attributes, from which
it uses--for now--the `InnerClasses` and `Signature` attributes.

This frees the `Loaders` from manipulating specific sets of
attributes that are needed by the loading functions. It will also
be necessary for reading Java annotations, since they are stored
in more attributes than were currently identified.
@sjrd sjrd mentioned this pull request Nov 16, 2023
@bishabosha bishabosha merged commit 57e818f into scalacenter:main Nov 18, 2023
4 checks passed
@sjrd sjrd deleted the prepare-java-annotations branch November 18, 2023 12:45
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.

2 participants