[m-rev.] for (possibly post-commit) review: simplify the creation of .int files

[Peter Wang]

On Mon, 18 Feb 2019 18:10:09 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Mon, 18 Feb 2019 05:58:40 +0000 (UTC), Julien Fischer <jfischer at opturion.com> wrote:
> > > Would an explicit proposal for a "MAYBE_larger_than_word_sized_type"
> > > attribute in the comment, together with an acknowledgement that
> > > sizes may vary across platforms, including wrt word sizes, address
> > > your concern?
> > 
> > Sure.
> 
> I committed the attached diff.
> 
> Zoltan.

> diff --git a/compiler/comp_unit_interface.m b/compiler/comp_unit_interface.m
> index e9d7e20..9202a99 100644
> --- a/compiler/comp_unit_interface.m
> +++ b/compiler/comp_unit_interface.m
> @@ -1464,8 +1464,13 @@ accumulate_abs_imp_exported_type_lhs_2(IntTypesMap, BothTypesMap,
>              % because the only foreign types that *need* the same treatment
>              % as equivalence types are foreign types that are bigger than
>              % one word in size. These should be extremely rare, so it should
> -            % be ok to require programmers to signal them with a specific
> -            % attribute on the foreign type definition.
> +            % be ok for us to require programmers to add a new attribute
> +            % (named something like "may_be_larger_than_word") on the
> +            % definitions of foreign types that may be larger than a word
> +            % on *some* platforms (not necessarily *all* platforms).
> +            % For example, a type that is defined to be implemented by
> +            % the C type int64_t will be word sized on x86_64, but will be
> +            % larger than word sized on plain on 32 bit x86.
>              set.insert(TypeCtor, !AbsExpEqvLhsTypeCtors)
>          else
>              true

What will happen if the programmer forgets to add the attribute on a
foreign type that is larger than one word? Because programmers WILL
forget, precisely because such types are rare. Not to mention existing
code that is not necessarily upgraded when switching compilers
(and you can't always force users to update to a compiler that
recognises the new attribute, though this is not a concern for most
Mercury programs).

Peter