<div>On Fri Jan 17 2014 at 4:41:22 PM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think we're OK here. 3.3.1/4 describes the rule as applying to a set<br>
of declarations "each of which specifies the same unqualified name" and<br>
we're guaranteed that using declarations will be qualified while the<br>
redeclarations will be unqualified (and the shadows are an<br>
implementation detail). So there's no conflict even in a pedantic reading..<br></blockquote><div><br></div><div>7.3.3/13, and its example, clarify that using-declarations are considered here. I've mailed the core reflector to get the wording in 3.3.1/4 clarified.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The "namespace surrounding the declaration" rule also doesn't appear to<br>
apply here given that one of the purposes of using declarations to work<br>
around strict lexical scope. Perhaps shades of PR17337 here but I'm<br>
tending to side with the mainstream again.<br>
<br>
Like you say the the standard is unclear but with this reading we get<br>
compatibility with g++ and MSVC and it does "feel right".<br></blockquote><div><br></div><div>EDG, g++, and MSVC all have different behavior here (different from each other and different from us).</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Awaiting that clarification you requested from the core reflector -- if<br>
anything it's an interesting discussion.<br></blockquote><div><br></div><div>Discussion on core so far suggests that an unqualified name *always* declares a name in the lexical context in which it appears, meaning our former behavior on this example was more appropriate than our new behavior.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alp.<br>
<br>
<br>
On 17/01/2014 20:59, Richard Smith wrote:<br>
> Hi Alp,<br>
><br>
> This change doesn't look correct.<br>
><br>
> On Fri Jan 17 2014 at 5:04:31 AM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a><br>
> <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
><br>
> Author: alp<br>
> Date: Fri Jan 17 06:57:21 2014<br>
> New Revision: 199490<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=199490&view=rev" target="_blank">http://llvm.org/viewvc/llvm-<u></u>project?rev=199490&view=rev</a><br>
> Log:<br>
> Permit redeclaration of tags introduced by using decls<br>
><br>
> This valid construct appears in MSVC headers where it's used to<br>
> provide a<br>
> definition for the '::type_info' compiler builtin type.<br>
><br>
> Modified:<br>
> cfe/trunk/lib/Sema/SemaDecl.<u></u>cpp<br>
> cfe/trunk/test/SemaCXX/using-<u></u>decl-1.cpp<br>
><br>
> Modified: cfe/trunk/lib/Sema/SemaDecl.<u></u>cpp<br>
> URL:<br>
> <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=199490&r1=199489&r2=199490&view=diff" target="_blank">http://llvm.org/viewvc/llvm-<u></u>project/cfe/trunk/lib/Sema/<u></u>SemaDecl.cpp?rev=199490&r1=<u></u>199489&r2=199490&view=diff</a><br>
> ==============================<u></u>==============================<u></u>==================<br>
> --- cfe/trunk/lib/Sema/SemaDecl.<u></u>cpp (original)<br>
> +++ cfe/trunk/lib/Sema/SemaDecl.<u></u>cpp Fri Jan 17 06:57:21 2014<br>
> @@ -10681,7 +10681,8 @@ Decl *Sema::ActOnTag(Scope *S, unsigned<br>
> }<br>
><br>
> if (!Previous.empty()) {<br>
> - NamedDecl *PrevDecl = (*Previous.begin())-><u></u>getUnderlyingDecl();<br>
> + NamedDecl *DirectPrevDecl = *Previous.begin();<br>
> + NamedDecl *PrevDecl = DirectPrevDecl-><u></u>getUnderlyingDecl();<br>
><br>
> // It's okay to have a tag decl in the same scope as a typedef<br>
> // which hides a tag decl in the same scope. Finding this<br>
> @@ -10713,7 +10714,7 @@ Decl *Sema::ActOnTag(Scope *S, unsigned<br>
> // in the same scope (so that the definition/declaration<br>
> completes or<br>
> // rementions the tag), reuse the decl.<br>
> if (TUK == TUK_Reference || TUK == TUK_Friend ||<br>
> - isDeclInScope(PrevDecl, SearchDC, S,<br>
> + isDeclInScope(DirectPrevDecl, SearchDC, S,<br>
> SS.isNotEmpty() ||<br>
> isExplicitSpecialization)) {<br>
> // Make sure that this wasn't declared as an enum and now<br>
> used as a<br>
> // struct or something similar.<br>
><br>
> Modified: cfe/trunk/test/SemaCXX/using-<u></u>decl-1.cpp<br>
> URL:<br>
> <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/using-decl-1.cpp?rev=199490&r1=199489&r2=199490&view=diff" target="_blank">http://llvm.org/viewvc/llvm-<u></u>project/cfe/trunk/test/<u></u>SemaCXX/using-decl-1.cpp?rev=<u></u>199490&r1=199489&r2=199490&<u></u>view=diff</a><br>
> ==============================<u></u>==============================<u></u>==================<br>
> --- cfe/trunk/test/SemaCXX/using-<u></u>decl-1.cpp (original)<br>
> +++ cfe/trunk/test/SemaCXX/using-<u></u>decl-1.cpp Fri Jan 17 06:57:21 2014<br>
> @@ -119,6 +119,27 @@ namespace foo<br>
> };<br>
> }<br>
><br>
> +namespace using_tag_redeclaration<br>
> +{<br>
> + struct S;<br>
> + namespace N {<br>
> + using ::using_tag_redeclaration::S;<br>
> + struct S {}; // expected-note {{previous definition is here}}<br>
><br>
><br>
> This is ill-formed, by 3.3.1/4. It appears that your change makes the<br>
> second declaration into a redeclaration of<br>
> ::using_tag_redeclaration::S; that's incorrect. (Our previous handling<br>
> of this case was also incorrect, albeit in a different way, since we<br>
> didn't enforce the 3.3.1/4 rule here.)<br>
><br>
> If we need to handle something of this form for MSVC compatibility,<br>
> we'll need to put it behind MSVCCompat.<br>
><br>
> + }<br>
> + void f() {<br>
> + N::S s1;<br>
><br>
> + S s2;<br>
> + }<br>
> + void g() {<br>
> + struct S; // expected-note {{forward declaration of 'S'}}<br>
> + S s3; // expected-error {{variable has incomplete type 'S'}}<br>
> + }<br>
> + void h() {<br>
> + using ::using_tag_redeclaration::S;<br>
> + struct S {}; // expected-error {{redefinition of 'S'}}<br>
><br>
> + }<br>
> +}<br>
> +<br>
> // Don't suggest non-typenames for positions requiring typenames.<br>
> namespace using_suggestion_tyname_val {<br>
> namespace N { void FFF() {} }<br>
><br>
><br>
> ______________________________<u></u>_________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a> <mailto:<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.<u></u>edu</a>><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-commits</a><br>
><br>
<br>
--<br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</blockquote>