-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Skip over JEP 445 compact compilation units #11066
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
base: 2.13.x
Are you sure you want to change the base?
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.
There is a Peanuts cartoon (as I recall from childhood) in which Linus explains that when he's reading the Bible and encounters a word he doesn't know, he just "bloops right over it".
test/files/pos/t12878/T.java
Outdated
//> using javacOpt --enable-preview --release 21 | ||
|
||
int k = 0; | ||
// This should work as compact units have an implicit `import module java.base`, but that doesn't seem to be the case with Java 21 preview |
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.
could use 25 directly, as no one cares about regression on old preview
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.
I recognize you might wish to see it run and pass today, however.
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.
Right, though we run 25 already on CI. I'll do that.
val ts = termDecl(mods, CLASS) | ||
if (ts.nonEmpty) compact = true | ||
Nil | ||
} |
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.
I might have generalized typeDeclOrCompactTerm(mods)(orElse: Tree)
which typeDecl
would call.
I might have orElse throw here to long jump back to a try in compilationUnit.
That would be to avoid listing tokens at L1097. OTOH, the method is so small this is fine.
There is a return
in that interactive
code, so maybe I have early return on the brain.
TIL OED notes intransitive "reference" having to do with (I think) cataloguing properties which must be acquired by eminent domain for a railroad. That strikes me as a very British coinage, that is, putting that disruptive practice behind a neutral term that doesn't even take a direct object. In the U.S., it's just called capitalism. To make too fine a distinction, does "reference" imply authoritative reference? Then one could reference a stable reference (in our terminology). Or perhaps conversely, every reference in computing is authoritative to mean correct and not erroneous, and therefore can be referenced. From C pointer days, we would say "dereference" for this action of actually finding the referent. That is at runtime. That might imply that at compiletime, one does not reference simply any identifier, but only identifiers with the strongest guarantees (that they are not null, perhaps). The weak sense is that referrible means in the namespace and accessible. |
Compact compilation units are not referencable, so we can skip over them.
Compact compilation units are not referenceable, so we can skip over them.
Fixes scala/bug#12878