Re: C++: Anticipated declaration of builtins.

[Roger Sayle <roger@eyesopen.com>]

> | > 1) Shouldn't we pre-declare the function at global scope, then
> | >    do a using-declaration at the standard scope?
> |
> | The problem here is that they need to be treated as two independent
> | pre-declarations.  If a prototype or declaration is given for
> | one, it does not automatically anticipate/declare the other.  Hence,
> | we require separate DECLs with independent DECL_ANTICIPATED flags.
>
> Hmm, why do we need to have two independent declarations for the same
> builtin?

Because of the way that duplicate_decls overwrites the original
decl when redeclaring a declaration, such as when an anticipated
built-in function is prototyped.

If a single decl was shared between ::strlen and std::strlen, then
the destructive modification of the first decl would side-effect
the second.  I'd hoped this was clear from my reference to the
DECL_ANTICIPATED flag.  Setting it to true for the decl in the
first namespace should not automatically set the DECL_ANTICIPATED
field of the pre-declaration in the second namespace.


I believe/hope that the DECLs themselves take up very little space,
they don't contain any RTL, they share their types and other major
fields.  So the DECL itself just acts a place holder, associating
the namespace/identifier, with its types, flags and attributes.


> If we have the same builtin declared twice with possibly two
> incompatible declarations, it occurs to me that we're calling for
> trouble.  Is there any case where that could be useful?

The DECL_BUILT_IN and similar attributes are only preserved if
the declarations are compatible.  If the type of the redeclaration
doesn't match the anticipated/pre-declared type, the old decl is
just completely overwritten.

Consider:

// Global namespace declaration matches anticipated type.
extern "C" size_t strlen(const char *);

// std namespace declaration doesn't match anticipated type.
namespace std {
double strlen;
}

We end up modifying or overwritting the anticipated decls for each
redeclaration, but clearly with very different information in each.
Its not that we use the same "built-in" function with different
types, but that we may or may not completely overwrite the decls
based upon different types, i.e. redeclare the DECL associated with
the identifier differently in different contexts.  The built-in only
gets used when the types match.

A less ambiguous/confusing example might be:

int strlen;
namespace std { double strlen; }

in which neither declaration matches the pre-declared built-in.


> The point is that I have been reworking some part of th name lookup
> machinery, and that particular behaviour crashes the compiler until I
> realized that declarations (of builtins) in the outer space is no good.
> If they  are supposed to be pre-declared at the global scope (as the
> comment indicates), then their DECL_CONTEXT should point to
> global_namespace.  I'll make that change, once I understand the other
> issue.

That sounds very reasonable.  Fortunately, fixing this should be
independent of the first issue.  You can be forgiven for being confused
by the current convoluted scheme.  I'd really like to see reuse of
old DECLs in C/C++'s duplicate_decls removed, but the entire area is
a minefield, and the current implementation has the one redeeming
feature that, for the time being, it works and works efficiently.

I hope this is clearer with a second explanation.

Roger
--