Help out with some small tasks

Compiler
1

Hi,

I have some free time at the moment so would love to help out with some issues. I was thinking of doing this : https://github.com/scala/bug/issues/10737
Does that sound like an okay task to get started with? I am not sure if these kind of messages are easy to add tests for?

I have a few years of experience with Scala and also loads of experience with BASH, Python, C, Linux, etc. If there is another area that I could help out that is higher priority, please let me know.

Thanks,
jmf

3 Likes
2

:+1: Thanks for your interest!

I think it would be a good first issue (but I labelled it as such :P). I recommend you read the contributing guide first. The README also has instructions on how to use the (idiosyncratic) sbt build.

Adding tests for error messages is pretty simple, using partest: you can create a file in test/files/neg, and the tests will assert that it doesn’t compile, with a given error message. There’s an incoming change to the guide that explains how partest is and how to use it.

I’d recommend starting with Parsers.scala, which is where most of the parsing lives. Feel free to ask here or on the ticket if you get stuck.

2 Likes
3

Great! Thanks for the quick reply. I have been able to add a new test in that folder and verified that it does not pass.

Do you think the following would be an improvement?

func-max-args.scala:1: error: Functions can not have more than 26 arguments
trait T { val x: (a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z) => Int }
                                                                       ^
one error found

Or do we want something more prescriptive than this?

Also, looking at the code, the chain of function calls that causes this looks like the following:

scala.tools.nsc.ast.parser.Parsers -> scala.tools.nsc.ast.parser.TreeBuilder.makeFunctionTypeTree -> scala.reflect.internal.TreeGen.mkFunctionTypeTree

It looks like the transformation is happening in TreeGen.mkFunctionTypeTree and this is bubbling up to Parsers, which is why the error message is so strange. I think the best thing to do would be to handle this case explicitly in Parsers as that seems to be the place where most errors are caught explicitly. I think the easiest way is to add a helper function in Parsers to check the length of the argument list and to throw an error if this is above the threshold. This will require changing a few calls to TreeBuilder.makeFunctionTypeTree in Parsers but I think it should not be too bad.

Does this sound reasonable?

4

Ah, I have just found the makeSafeTupleTerm method in Parsers which is along the same lines as what I was thinking.

5

Another good “welcome to scala” question is, “Do I have to understand all the words used in a ticket before I try to contribute?”