Are attributes allowed in explicit template instantiations?

[Matthew Woehlke]

Let's say I have a templates:

template <typename T> T foo(T) { ... }

Now let's say that I want to a) explicitly instantiate it, and b) set
its ELF symbol visibility when doing so.

template [[gnu::visibility("default")]] int foo<int>(int);

This works fine on GCC, but Clang rejects it with "error: an attribute
list cannot appear here". Which is correct?

Based on my reading of N4606, [A.6] and [A.12], it seems to me that the
correct parse of this grammar would be:

<explicit-instantiation> -->
[extern] template <declaration> -->
[extern] template <nodeclspec-function-declaration> -->
[extern] template [<attribute-specifier-seq>] <declarator> ;

...which would suggest that clang is wrong, but I'd appreciate a second
opinion.

--
Matthew

[Richard Smith]

[dcl.attr.grammar]/5: "No attribute-specifier-seq shall appertain to an explicit instantiation (14.7.2)."

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.

[Matthew Woehlke]

On 2016-08-22 15:49, Richard Smith wrote:

Ugh, please don't top post.

> On Mon, Aug 22, 2016 at 10:32 AM, Matthew Woehlke wrote:
>> Let's say I have a templates:
>>
>> template <typename T> T foo(T) { ... }
>>
>> Now let's say that I want to a) explicitly instantiate it, and b) set
>> its ELF symbol visibility when doing so.
>>
>> template [[gnu::visibility("default")]] int foo<int>(int);
>>
>> This works fine on GCC, but Clang rejects it with "error: an attribute
>> list cannot appear here". Which is correct?
>

> [dcl.attr.grammar]/5: "No *attribute-specifier-seq* shall appertain to an
> explicit instantiation (14.7.2)."

Um... okay, *why is that*? Considering that instantiations may need to
be exported decorated, this seems like a... misguided restriction, as it
forbids the use of attributes to export an instantiation, forcing
instead the old and ugly __declspec/__attribute__ to be used.

...or am I missing something?

--
Matthew

[Richard Smith]

One view of explicit instantiations is that they're not really declarations of the specialization at all -- they're just commands to the compiler that control which points of instantiation you get for a specialization (explicit instantiation definitions add a specific point of instantiation, and explicit instantiation declarations remove points of instantiation from the same translation unit), and points of instantiation only control the behavior of name lookup within the template. For a compiler that instantiates templates separately from normal compilation (such as EDG's frontend in some modes), they may merely specify how to filter the name lookup results based on the chosen point of instantiation, but otherwise the specialization is instantiated in the normal way. From that point of view, attributes on explicit instantiations don't make much sense, just like you can't add attributes to an implicitly-instantiated specialization of a class template.

[Matthew Woehlke]

On 2016-08-23 15:07, Richard Smith wrote:

Okay, I think I follow that. Essentially, what you are saying is that in
the "ivory tower" world of the standard by itself (wherein, IIRC,
concepts like "linking" and "translation units" don't exist), there is
no reason why an explicit instantiation would ever have attributes?

That makes sense, but unfortunately doesn't line up very well with real
world practice.

Practically speaking, an explicit instantiation provides a definition
that can be used to satisfy the linker when another TU needs the
template but does not have a definition available to instantiate (or has
been instructed to suppress instantiation). In that world, at least ELF
visibility attributes are... well, somewhat important :-). And
therefore, the blanket prohibition on attributes is... unfortunate.

(By the same token, it's also unfortunate that the obvious use case for
attributes on explicit instantiations "doesn't exist" in the limited
world view of the standard :-). Alas, I think this is one place where
the real world should probably be allowed to intrude.)

I'd like to propose to remove this restriction (see thread on
std-proposals). At least, I am assuming this is a change for which a DR
would not be appropriate?

(I note for the record that, based on your comment in
https://llvm.org/bugs/show_bug.cgi?id=29094, I suspect we agree, but are
repeating this conversation for the sake of the std-discussion audience.
Also, thanks for the discussion!)

--
Matthew