compiler: undercover(aged)

On Sun, Feb 13, 2011 at 8:48 AM, Paul Phillips wrote:
> I declare a contest.  Find the most surprising chunk of dead code in that
> coverage report, where the definition of surprising is intentionally
> underspecified.

This surely doesn't fall into the most surprising section but it still
seems unnecessary complicated:

Parsers.scala, condExpr:

1161 def condExpr(): Tree = {
1162 if (in.token == LPAREN) {
1163 in.nextToken()
1164 val r = expr()
1165 accept(RPAREN)
1166 r
1167 } else {
1168 accept(LPAREN)
1169 Literal(true)
1170 }
1171 }

Couldn't that be simply written as:

def condExpr(): Tree = {
accept(LPAREN)
val r = expr()
accept(RPAREN)
r
}

Le 13/02/2011 08:48, Paul Phillips a écrit :
> With a bit of fiddling I got scct running on the compiler. Here is the
> report from the compiler about the compiler after compiling itself.
>
> http://paulp.github.com/scct/scalac-coverage-report/

That's quite an hard exercise for someone who don't know compiler
internal at all. Discovery #1: there is a lot of branches, in a lot of
places, never taken (in Type en Pattern especially). Let say it isn't
dead code, just rare cases not tested.

Discovery #2: nothing amazing from me, juste these two things:

​scala/​tools/​nsc/​matching/​PatternBindings.scala l. 121 :
=> private def deepstrip
dead code

​scala/​tools/​nsc/​symtab/​StdNames.scala
=> def segments(name: String, assumeTerm: Boolean)
seems to never be called (but it's public, and I don't know at all
compiler API so perhaps it's a feature. But it looked like a method the
compiler would want to call, perhaps.)

Hope others will find more surprising things.

Cheers,

On 02/13/2011 12:33 PM, Francois Armand wrote:
> Le 13/02/2011 08:48, Paul Phillips a écrit :
>> With a bit of fiddling I got scct running on the compiler. Here is the
>> report from the compiler about the compiler after compiling itself.
>>
>> http://paulp.github.com/scct/scalac-coverage-report/
>
>
> That's quite an hard exercise for someone who don't know compiler
> internal at all. Discovery #1: there is a lot of branches, in a lot of
> places, never taken (in Type en Pattern especially). Let say it isn't
> dead code, just rare cases not tested.

Note, this is is compiler compiling itself. Not really running our
test-suite.

hubert

>
> Discovery #2: nothing amazing from me, juste these two things:
>
> ​scala/​tools/​nsc/​matching/​PatternBindings.scala l. 121 :
> => private def deepstrip
> dead code
>
> ​scala/​tools/​nsc/​symtab/​StdNames.scala
> => def segments(name: String, assumeTerm: Boolean)
> seems to never be called (but it's public, and I don't know at all
> compiler API so perhaps it's a feature. But it looked like a method
> the compiler would want to call, perhaps.)
>
>
> Hope others will find more surprising things.
>
> Cheers,
>

Le 13/02/2011 13:41, Hubert Plociniczak a écrit :
>> That's quite an hard exercise for someone who don't know compiler
>> internal at all. Discovery #1: there is a lot of branches, in a lot of
>> places, never taken (in Type en Pattern especially). Let say it isn't
>> dead code, just rare cases not tested.
>
> Note, this is is compiler compiling itself. Not really running our
> test-suite.

Yes, sorry for the phrasing, it should have been "not taken in the
compilation of the compiler".

On Sun, Feb 13, 2011 at 11:30 AM, Johannes Rudolph
wrote:
> On Sun, Feb 13, 2011 at 8:48 AM, Paul Phillips wrote:
>> I declare a contest.  Find the most surprising chunk of dead code in that
>> coverage report, where the definition of surprising is intentionally
>> underspecified.
>
> This surely doesn't fall into the most surprising section but it still
> seems unnecessary complicated:
>
> Parsers.scala, condExpr:
>
> 1161        def condExpr(): Tree = {
> 1162          if (in.token == LPAREN) {
> 1163            in.nextToken()
> 1164            val r = expr()
> 1165            accept(RPAREN)
> 1166            r
> 1167          } else {
> 1168            accept(LPAREN)
> 1169            Literal(true)
> 1170          }
> 1171        }
>
> Couldn't that be simply written as:
>
>    def condExpr(): Tree = {
>      accept(LPAREN)
>      val r = expr()
>      accept(RPAREN)
>      r
>    }
>
The rewrite would behave worse in the case of syntax errors.

Cheers

On Sun, Feb 13, 2011 at 2:48 AM, Paul Phillips <paulp@improving.org> wrote:

With a bit of fiddling I got scct running on the compiler.  Here is the report from the compiler about the compiler after compiling itself.

 http://paulp.github.com/scct/scalac-coverage-report/

Neat! So, 43% of the compiler is used to compile itself.
Skimming it, some of the chunks of functionality not used are not surprising at all. For example: scaladoc, the Java parser, and the interpreter all got 0% coverage. Also, icode.analysis is only 5%, presumably because you compiled it without optimization.
Some parts are more interesting at first blush, but make more sense on drilling in. For example, icode is only 46% covered. If you look inside, though, parts that aren't used include alternate linearizers and pretty printers. (Though if you wanted something that could be lived without, are linearizers well understood enough now to just pick one and make it the only option?) The nsc.ast package is only 40% covered. Looking inside, though, for example scaladoc AST nodes are not covered, and the swing-browser code is not covered. (Please don't delete the swing browser!)
As another random observation, the absolute highest coverage for any package is nsc.matching, and it's at 76%. So there's no one package in there that gets full coverage.
Anyway, neat report! If I were the type to ask for ponies, I would ask about coverage for the standard library and for the test suite. Anything not covered by those is well worth attention. At the very least there should be a test case covering everything. And if it's hard to craft such a test case, then perhaps the code in question really is unreachable.
Thanks for sharing, and I look forward to the results of the competition! From my quick scanning, I'm utterly failing to find any code that looks worth cutting. I examined 20-30 red-highlighted parts, and they all looked useful for other compiles. For example, not much constant folding happened, but that's not unusual -- constant folders have a zillion cases and any one compile will only use a few of them. The Cleanup module has lots of code for structural-type method calls that wasn't used, but that's not surprising since the compiler doesn't use many such calls. And so on.
Lex