[m-rev.] for review: fix foreign_decls in the LLDS grades

[Peter Ross]

On Thu, Aug 01, 2002 at 08:23:00AM +1000, Fergus Henderson wrote:
> On 31-Jul-2002, Peter Ross <petdr at cs.mu.OZ.AU> wrote:
> > 
> > Record foreign_decls in the .mh file in the LLDS grades.  This allows
> > these declarations to be reused in different modules by just adding a
> > foreign_import_module declaration, rather than duplicating the
> > declarations using intermodule optimization.
> 
> I don't really understand the rationale here.
> Could you explain in more detail?

This patch was originally to fix the problem with foreign types and
pragma exports.  The problem was that the pragma export was placed in
the .mh file while the definition of any pragma foreign_type was in the
.c file, hence when parsing the .mh file an undefined type would be
seen.

I tried to fix this by placing the foreign_decls in the .mh file when
the module contained a foreign_type.  Unfortunately because of intermodule
optimization you ended up with the same foreign_decls in more than one
header file, and duplicate error problems so at this point I realised
that the only sensible solution was to place the decls in one place and
use the foreign_import_module mechanism to obtain these decls as needed.

So in summary the problem is that once you place one declaration in a
header file then you need to place all declarations in the header file
to avoid duplicate definition problems.

> Is this patch changing something user-visible?
> If so, there should be a test case for it.
> 
Yes it will fix the problem with pragma export and pragma foreign_type,
I will reenable the test case for this.

> What exactly is the current status, and how does your patch compare with it?
> And how does it compare with what happens for MLDS grades?
> 
It brings it into sync with what happens in the MLDS grades, in that
foreign_decls are placed into a header file and to obtain the
foreign_decls you just need to include the .mih file.

> > compiler/intermod.m:
> >     Don't add pragma foreign_code to .opt files until the limitation
> >     with foreign_import_module documented in
> >     intermod__write_intermod_info_2 is fixed.
> 
> That looks like it could cause a serious performance regression
> for a lot of programs.  Is this really needed?
> 
Well according to the XXX in intermod__write_intermod_info_2, using
foreign_include_module causes the library not to compile, so yes it is
needed.

I intend to look at fixing this problem as a seperate change.

> If it fixes a bug, then the patch should include a regression test.
> 
Yes I will add some.

> > compiler/mercury_compile.m:
> >     Guard the declarations output in the C file with decl_guard.  We
> >     output this second copy because it uses the line numbers of the
> >     source file for the declarations allowing one to debug problems more
> >     easily.
> 
> The patch should include a regression test in tests/invalid
> to check that the C compiler gives the correct line number for errors
> in such declarations.
> 
Will do.

Actually I have had to change a few things so that it bootstraps on the
hlc.gc grade, interdiff to follow.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------