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

Cross-build to Scala 3 #78

Open
SethTisue opened this issue Oct 29, 2021 · 3 comments
Open

Cross-build to Scala 3 #78

SethTisue opened this issue Oct 29, 2021 · 3 comments

Comments

@SethTisue
Copy link
Member

Currently this isn't trivially possible because TypeTag is used. Needs some investigation to see what it's being used for and what replacing it would look like.

@SethTisue
Copy link
Member Author

is there someone from the @scala/collections who might like to tackle this?

@Ichoran what can you tell us about how TypeTag is being used?

@SethTisue
Copy link
Member Author

SethTisue commented Jan 24, 2022

Looked at this a bit.

It appears to me that TypeTag is used only in Instantiator which is used only during code generation.

So it ought to be possible to run the code generator on Scala 2 only, and then test the generated code with both Scala 2 and Scala 3.

I got most of the way through performing this separation, but there is one (only one?) remaining roadblock. Generator.scala contains a series of singletons such as object AllLongStrGenerators which mix code used at generation time with code used at testing time. Those two kinds of code need to be kept separate for my scheme to work.

wip branch: https://github.com/SethTisue/scala-collections-laws/tree/scala3

@Ichoran
Copy link
Contributor

Ichoran commented Jan 25, 2022

I think I used TypeTag to get Scala-code-compatible method names and know which ones were actually public (instead of package private or whatever). A ClassTag could be used instead with name-demangling to get the names, but I'm not sure how to know which ones are Scala-public.

I am not sure separation is easily possible. My dim recollection is that the code generation and the singletons are matched. I suppose the code generation could generate the singleton hooks instead (filling in any TypeTag stuff if needed). I think the type tags were used possibly at runtime to generate informative messages, but it should work just as well to use code generation to build the strings.

Maybe it would make more sense to do it the other way: Scala 3 should generate the code and let Scala 2 run it. Then when Scala 3 drops library compatibility, you just stop testing Scala 2 code. More work, but maybe not that much more work.

I haven't yet figured out how to get things like public method names and full class names with types out of Scala 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants