Apply refactorings blocked previously #6791
Conversation
Apply refactorings that were not possible before because bootstrap compiler had problems with them.
This is necessary so that enum constants come with the class not the companion object which was in turn necessary to let the bootstrapped build pass. Two questions: 1) It seems the bootstrapped build got confused. It seemed it compiled against the previous ErrorMesssageID.java and ran against the ErrorMessageID.scala. 2) In any case, it would be good if enum constants were always generated at the same place, no matter whether we extend java.lang.Enum or not.
Allow use of `result` instead of having to pass a lambda.
| // DOTTY TODO: replace previous 2 lines with | ||
| // export opaques.FlagSet | ||
| // once 0.17 is released and #6721 is in the bootstrap | ||
| export opaques.FlagSet | ||
|
|
||
| type Flag = opaques.Flag |
There was a problem hiding this comment.
Can this also be exported?
There was a problem hiding this comment.
export opaques.Flag would also export the def Flag, rendering it public. This is not what we want.
There was a problem hiding this comment.
Is that method not defined as private? What happens when you export a private method?
There was a problem hiding this comment.
Even though it is private[Flags] and is exported into Flags object, this is technically fine with the contract of the private[Flags](namely that it should not be exposed outside Flags). If we don't want it in Flags either, shouldn't it be private[opaques]?
There was a problem hiding this comment.
(except that we're using it in Flags, e.g. in newFlags:
opaques.Flag(KINDFLAGS | bits), opaques.Flag(TERMS | bits), opaques.Flag(TYPES | bits)This would have been simplified if we exported the method)
There was a problem hiding this comment.
An exported member is always public.
There was a problem hiding this comment.
That does create problems when doing export x._. It can well become an antipattern as you must now be concerned with the private details of the implementation of x to do the export correctly. I don't know of any other case where this insight into private members would be required.
There was a problem hiding this comment.
An export only exports members that are visible at the point of export. But then the forwarders become public. I think that's the right tradeoff.
There was a problem hiding this comment.
Yes, that makes sense
We can't have WrappedResult in tools itself, since that gives a CyclicReference error in some situations. Specifically, if tools.WrappedResult is compiled first, we complete its paackage, which means we complete tools/package.scala which means we enter its members which means we process the WrappedResult export which means we complete WrappedResult which gives a CyclicReference An alternative fix would be to avoid the export and use explicit forwarders instead.
This allows us to put WrappedResult directly in the tools package object.
Apply refactorings that were not possible before because bootstrap compiler
had problems with them.