Make coverage/alloc work without turning off inlining

[timholy]

Now with our improved meta information, I wonder if in principle it's possible to make coverage analysis work properly without --inline=no. Ref c68a2cd

[wookay]

I'm glad to hear that. +1. thanks

[timholy]

This may already be well-known, but I just (re)discovered an interesting problem while working on an upcoming package, IndirectArrays, in which running our tests with --inline=no causes an actual problem. Here and here I'm exploiting/testing our snazzy @boundscheck functionality. But that functionality relies on inlining, so turning it off causes Travis tests to fail. Consequently, this seems to force one to choose between testing the boundcheck removal and getting good coverage statistics.

CC @blakejohnson, in case you haven't discovered this issue yet. (To be clear, I think the fix is to improve the way we measure coverage, not to change how @boundscheck and associated infrastructure works.)

[blakejohnson]

@timholy right, we go through some hoops to run the base boundscheck tests 3 different ways to test all code paths. As a first step, to get the test to pass with or without inlining, you can modify the test based upon the value of Base.JLOptions().can_inline, but that is obviously not ideal.