-
Erwan Jahier authored
t, and a node returning such a t, the compiler was actually returning the type definition of t (instead of the abstract type). In order to fix that, it was necessary to add in argument of Lazycompiler.solve_x_idref a flag (named provide_flag) indicating whether the item being compiled appears in the provide, or in the body part of the package. This fix triggered another bug that we also fix: indeed, it is not correct to return a compile error when the provided parameters of a node is not equal to its implementation. Indeed, such parameters can be abstract type that are defined in that package. The test "should_work/packEnvTest/packages.lus" is now ok.
Erwan Jahier authoredt, and a node returning such a t, the compiler was actually returning the type definition of t (instead of the abstract type). In order to fix that, it was necessary to add in argument of Lazycompiler.solve_x_idref a flag (named provide_flag) indicating whether the item being compiled appears in the provide, or in the body part of the package. This fix triggered another bug that we also fix: indeed, it is not correct to return a compile error when the provided parameters of a node is not equal to its implementation. Indeed, such parameters can be abstract type that are defined in that package. The test "should_work/packEnvTest/packages.lus" is now ok.