2022-05-17 17:02 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000556mercuryBugpublic2022-04-07 12:56
Reporterjuliensf 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000556: Stage 2 compiler does not build with --intermod-opt -O5 and rotd-2022-04-04
DescriptionFrom testing.mercurylang.org

fact_table.m:2543: error: the user defined inst
fact_table.m:2553: error: the user defined inst
fact_table.m:3400: error: the user defined inst
building of stage 2 compiler not successful

In non-truncated form it is:

fact_table.m:2543: In the second argument of predicate `get_hash_table_type'/2:
fact_table.m:2543: error: the user defined inst
fact_table.m:2543: `ll_backend.fact_table.key_char'/0
fact_table.m:2543: is declared to be applicable only to values of type
fact_table.m:2543: `char.char'/0,
fact_table.m:2543: but here it is applied to values of type
fact_table.m:2543: `character'/0.
fact_table.m:2553: In the third argument of predicate
fact_table.m:2553: `get_hash_table_type_loop'/3:
fact_table.m:2553: error: the user defined inst
fact_table.m:2553: `ll_backend.fact_table.key_char'/0
fact_table.m:2553: is declared to be applicable only to values of type
fact_table.m:2553: `char.char'/0,
fact_table.m:2553: but here it is applied to values of type
fact_table.m:2553: `character'/0.
fact_table.m:3400: In the fifth argument of predicate
fact_table.m:3400: `generate_hash_lookup_code'/7:
fact_table.m:3400: error: the user defined inst
fact_table.m:3400: `ll_backend.fact_table.key_char'/0
fact_table.m:3400: is declared to be applicable only to values of type
fact_table.m:3400: `char.char'/0,
fact_table.m:3400: but here it is applied to values of type
fact_table.m:3400: `character'/0.

It looks like equivalence types are not being expanded in insts correctly.




TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0001187

zs (developer)

I started fixing this by expanding type_ctors in inst definitions,
but realised that this is wrong approach. The reason is that the inst
will (in virtually all cases) contain function symbols of the named type,
and thus makes sense only if the user who wrote the inst knows the
ultimate expansion of the "for typector". If they know it, why not write it?

Therefore I propose to fix this bug in two ways.

- Replace char with character in the inst definition in fact_table.m.

- Add code that detects when the "for type_ctor" part of an inst defn
  is an equivalence type, and generates a version of the error messag
  above that mentions this fact.
  
Any objections?

~0001188

juliensf (administrator)

I don't have any particularly strong objections. Your proposed fix does introduce a certain lack
of uniformity with respect to how equivalence types are treated by different parts of the language.
(It's probably not too bad in presence of an error message describing what is wrong.)

As to "if they know, why not write it?", I think this bug answers that question. It wasn't written because the equivalence type is the preferred name for the type in question. When deprecating a type name we quite often start by introducing an equivalence that defines the new name and then swapping them around later, before finally (after a respectable interval) deleting the original name. (That isn't quite the story with character / char, but it's close.)

Another reason a user may have used char instead of character here, is that they may have read the library documentation. It is fairly emphatic on the point:

    Originally we used `character' rather than `char' for the type name
    because `char' was used by NU-Prolog to mean something different.
    But now we use `char' and the use of `character' is discouraged.

~0001189

zs (developer)

Fix committed 2022 apr 7.
+Notes

-Issue History
Date Modified Username Field Change
2022-04-06 12:10 juliensf New Issue
2022-04-06 12:22 zs Assigned To => zs
2022-04-06 12:22 zs Status new => assigned
2022-04-06 15:18 zs Note Added: 0001187
2022-04-06 15:37 juliensf Note Added: 0001188
2022-04-07 12:56 zs Status assigned => resolved
2022-04-07 12:56 zs Resolution open => fixed
2022-04-07 12:56 zs Note Added: 0001189
+Issue History