Jurgen J. Vinju

* the current version loops through `pcfg.libs` to find if certain files exist, while the last version that takes 60 minutes does not do that. could that be the cause?...

That is a different project. I'm talking about `rascal-core`

there is the `compiler` and `typechecker` labels and also `rascal-core` is mentioned in the subject line

rascal-core is a temporary project for the sake of independent progress, which will be merged into the `rascal` project sometime in the future. But I'd rather keep the issues together;...

BTW we are catching up with months of progress in rascal-core, which is why we are now registering lots of new issues there.

I think someone is filtering references for extended modules with warnings or errors; maybe just not filter the references if the module name is resolved but not used?

Having fixed this, another bug is slightly more insidious: ``` data F[&T] = F(&T t, &T x = t); rascal>F(1) F[int]: F(1) rascal>F(1).x &T: 1 rascal>F(1,x=3).x &T: 3 ``` Apparantly,...

Ooo.. nasty. The problem is caused by the field type not being instantiated at the right time. It remains `&T` throughout the construction of the Result object (factory method `makeResult`)...

To fix this, the code could become really expensive to run. You see the `&T` could be shared in complex ways between both normal fields and keyword fields. To find...

Right! thanks. It's all instances of the same bug; but there are different places in the implementation of ConstructorResult.fieldAccess that each of these examples trigger. A simple fix would fix...