[Haskell-cafe] Core optimizations affected by package provenance

[Li-yao Xia]

Dear Café,

The reasonable explanation for this issue is that changing where 
splitmix comes from changes the version of random.

When using only dependencies from Hackage, I got random-1.2 (latest 
version).

When depending on splitmix locally (same version), I got random-1.1. 
cabal refuses to upgrade to 1.2, presumably because it sees a spurious 
cyclic dependency: random-1.2 depends on splitmix whose test suite 
depends on random.

So there is a discrepancy in how cabal handles local packages, but at 
least it's not as weird as my previous hypothesis of building with 
different compiler flags.

Li-yao

On 8/6/2020 9:52 PM, Li-yao Xia wrote:
> Hello Café,
> 
> I've been testing properties of some optimized Core using the 
> inspection-testing library. Some functions appear to be optimized 
> differently depending on whether one of the package dependencies comes 
> from Hackage or elsewhere. As far as I can tell, the source code is 
> identical, and the only difference is whether or not I add the path to 
> the local package in my cabal.project.
> 
> Why would a dependency be compiled differently depending on where it 
> comes from?
> Any suggestions on how to troubleshoot this?
> 
> To be more concrete, the relevant packages are generic-random and 
> splitmix. The following commands should reproduce the issue:
> 
> 
> git clone https://github.com/Lysxia/generic-random
> git clone https://github.com/phadej/splitmix
> cd generic-random
> 
> # With local splitmix
> echo "packages: . ../splitmix" > cabal.project
> cabal test --flags="enable-inspect"
> # PASS
> 
> # With remote splitmix
> echo "packages: ." > cabal.project
> cabal test --flags="enable-inspect"
> # FAIL
> 
> 
> It would be useful to know whether anyone can reproduce this behavior or 
> not.
> 
> Cheers,
> Li-yao
> 
> PS, link to Github issue: 
> https://github.com/Lysxia/generic-random/issues/22