[m-rev.] diff and proposal: check class decls before instance decls

[Zoltan Somogyi]

This diff just moves code around, so there is no need
for a review.

My next change to check_typeclass.m will move the checks
for duplicate typeclass decls there from add_class.m.
This will require a bit of finesse. The class table is now,
and should remain, a map from class_ids to hlds_class_defns,
but a class may, and often will, have two item_typeclass_infos,
each of which turns into a hlds_class_defn: an abstract declaration
in the interface section, and a concrete definition in the
implementation section. I propose to resolve this by
replacing the current classdefn_maybe_bad field in
hlds_class_defns with a list of hlds_class_defns.
This list would be used only for communication between
add_class.m and check_typeclass.m, but in a different way.
add_class.m would, when encountering any item_typeclass_info
for a class_id other than the first, construct a hlds_class_defn
from it and add it to the list hanging off the new field
in the first hlds_class_defn for the class_id (which would be
the entry for this class_id in the class table). check_typeclass.m
would set this field to [] when it is done, but before then,
as its first job, it would check for

1 illegal duplicate typeclass declarations for the same class_id;
2 legal but unusual duplicate declarations (two abstract decls
  in the same module, which should get a warning),
3 totally ok duplicate typeclass decls (one abstract and one concrete
  in the same module)
4 the absence of an expected declaration (the absence of a concrete
  class definition in the presence of an abstract declaration in the current
  module).

The current code generates errors in case 1, and of course handles
the ok situation (case 3). It handles case 2 without generating any
warning, and may or may not handle case 4: missing concrete
typeclass definitions are now detected when processing instance
declarations for the class_id, which means that case 4 won't be detected
if the class involved has no instances.

The code that now does those checks is clumsy, because it has to
work piecemeal; it handles each item_typeclass_info as it gets added
to the HLDS. Even when it has seen all the item_typeclass_infos for
a given class_id, it does not KNOW that it has seen them all. By moving
all these checks to the check_typeclass pass, the new code will work
with access to (the HLDS representations of) all the item_typeclass_infos,
which should simplify and clarify its logic considerably, besides fixing
the handling of cases 2 and 4 above.

We already have a pass in check_typeclass.m that does for instance items
all of what I propose to do above for typeclass items. I also intend to move
this pass to be part of the first pass in check_typeclass.m that works on
instance declarations.

If you object to any of the above, please do so before the end of today,
because I intend to start soon after midnight.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.ct3
Type: application/octet-stream
Size: 99 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20221125/97ad8ddd/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.ct3
Type: application/octet-stream
Size: 40824 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20221125/97ad8ddd/attachment-0003.obj>