| Message ID | f726a433-0bb9-33d4-9929-7c018913d0ca@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | avoid -Wredundant-tags on a first declaration in use (PR 93824) | expand |
On 2/24/20 6:58 PM, Martin Sebor wrote: > -Wredundant-tags doesn't consider type declarations that are also > the first uses of the type, such as in 'void f (struct S);' and > issues false positives for those. According to the reported that's > making it harder to use the warning to clean up LibreOffice. > > The attached patch extends -Wredundant-tags to avoid these false > positives by relying on the same class_decl_loc_t::class2loc mapping > as -Wmismatched-tags. The patch also somewhat improves the detection > of both issues in template declarations (though more work is still > needed there). > + a new entry for it and return unless it's a declaration > + involving a template that may need to be diagnosed by > + -Wredundant-tags. */ > *rdl = class_decl_loc_t (class_key, false, def_p); > - return; > + if (TREE_CODE (decl) != TEMPLATE_DECL) > + return; How can the first appearance of a class template be redundant? Jason
On 2/28/20 9:58 AM, Jason Merrill wrote: > On 2/24/20 6:58 PM, Martin Sebor wrote: >> -Wredundant-tags doesn't consider type declarations that are also >> the first uses of the type, such as in 'void f (struct S);' and >> issues false positives for those. According to the reported that's >> making it harder to use the warning to clean up LibreOffice. >> >> The attached patch extends -Wredundant-tags to avoid these false >> positives by relying on the same class_decl_loc_t::class2loc mapping >> as -Wmismatched-tags. The patch also somewhat improves the detection >> of both issues in template declarations (though more work is still >> needed there). > >> + a new entry for it and return unless it's a declaration >> + involving a template that may need to be diagnosed by >> + -Wredundant-tags. */ >> *rdl = class_decl_loc_t (class_key, false, def_p); >> - return; >> + if (TREE_CODE (decl) != TEMPLATE_DECL) >> + return; > > How can the first appearance of a class template be redundant? I'm not sure I correctly understand the question. The comment says "involving a template" (i.e., not one of the first declaration of a template). The test case that corresponds to this test is: template <class> struct S7 { }; struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } where DECL is the TEPLATE_DECL of S7<void>. As I mentioned, more work is still needed to handle templates right because some redundant tags are still not diagnosed. For example: template <class> struct S7 { }; template <class T> using U = struct S7<T>; // missing warning Martin
On 2/28/20 12:45 PM, Martin Sebor wrote: > On 2/28/20 9:58 AM, Jason Merrill wrote: >> On 2/24/20 6:58 PM, Martin Sebor wrote: >>> -Wredundant-tags doesn't consider type declarations that are also >>> the first uses of the type, such as in 'void f (struct S);' and >>> issues false positives for those. According to the reported that's >>> making it harder to use the warning to clean up LibreOffice. >>> >>> The attached patch extends -Wredundant-tags to avoid these false >>> positives by relying on the same class_decl_loc_t::class2loc mapping >>> as -Wmismatched-tags. The patch also somewhat improves the detection >>> of both issues in template declarations (though more work is still >>> needed there). >> >>> + a new entry for it and return unless it's a declaration >>> + involving a template that may need to be diagnosed by >>> + -Wredundant-tags. */ >>> *rdl = class_decl_loc_t (class_key, false, def_p); >>> - return; >>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>> + return; >> >> How can the first appearance of a class template be redundant? > > I'm not sure I correctly understand the question. The comment says > "involving a template" (i.e., not one of the first declaration of > a template). The test case that corresponds to this test is: > > template <class> struct S7 { }; > struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } > > where DECL is the TEPLATE_DECL of S7<void>. > > As I mentioned, more work is still needed to handle templates right > because some redundant tags are still not diagnosed. For example: > > template <class> struct S7 { }; > template <class T> > using U = struct S7<T>; // missing warning When we get here for an instance of a template, it doesn't make sense to treat it as a new type. If decl is a template and type_decl is an instance of that template, do we want to (before the lookup) change type_decl to the template or the corresponding generic TYPE_DECL, which should already be in the table? Jason
On 2/28/20 1:24 PM, Jason Merrill wrote: > On 2/28/20 12:45 PM, Martin Sebor wrote: >> On 2/28/20 9:58 AM, Jason Merrill wrote: >>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>> -Wredundant-tags doesn't consider type declarations that are also >>>> the first uses of the type, such as in 'void f (struct S);' and >>>> issues false positives for those. According to the reported that's >>>> making it harder to use the warning to clean up LibreOffice. >>>> >>>> The attached patch extends -Wredundant-tags to avoid these false >>>> positives by relying on the same class_decl_loc_t::class2loc mapping >>>> as -Wmismatched-tags. The patch also somewhat improves the detection >>>> of both issues in template declarations (though more work is still >>>> needed there). >>> >>>> + a new entry for it and return unless it's a declaration >>>> + involving a template that may need to be diagnosed by >>>> + -Wredundant-tags. */ >>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>> - return; >>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>> + return; >>> >>> How can the first appearance of a class template be redundant? >> >> I'm not sure I correctly understand the question. The comment says >> "involving a template" (i.e., not one of the first declaration of >> a template). The test case that corresponds to this test is: >> >> template <class> struct S7 { }; >> struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } >> >> where DECL is the TEPLATE_DECL of S7<void>. >> >> As I mentioned, more work is still needed to handle templates right >> because some redundant tags are still not diagnosed. For example: >> >> template <class> struct S7 { }; >> template <class T> >> using U = struct S7<T>; // missing warning > > When we get here for an instance of a template, it doesn't make sense to > treat it as a new type. > > If decl is a template and type_decl is an instance of that template, do > we want to (before the lookup) change type_decl to the template or the > corresponding generic TYPE_DECL, which should already be in the table? I'm struggling with how to do this. Given type (a RECORD_TYPE) and type_decl (a TEMPLATE_DECL) representing the use of a template, how do I get the corresponding template (or its explicit or partial specialization) in the three cases below? 1) Instance of the primary: template <class> class A; struct A<int> a; 2) Instance of an explicit specialization: template <class> class B; template <> struct B<int>; class B<int> b; 3) Instance of a partial specialization: template <class> class C; template <class T> struct C<T*>; class C<int*> c; By trial and (lots of) error I figured out that in both (1) and (2), but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns the template's type_decl. Is there some function to call to get it in (3), or even better, in all three cases? Martin
On 3/9/20 12:31 PM, Martin Sebor wrote: > On 2/28/20 1:24 PM, Jason Merrill wrote: >> On 2/28/20 12:45 PM, Martin Sebor wrote: >>> On 2/28/20 9:58 AM, Jason Merrill wrote: >>>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>>> -Wredundant-tags doesn't consider type declarations that are also >>>>> the first uses of the type, such as in 'void f (struct S);' and >>>>> issues false positives for those. According to the reported that's >>>>> making it harder to use the warning to clean up LibreOffice. >>>>> >>>>> The attached patch extends -Wredundant-tags to avoid these false >>>>> positives by relying on the same class_decl_loc_t::class2loc mapping >>>>> as -Wmismatched-tags. The patch also somewhat improves the detection >>>>> of both issues in template declarations (though more work is still >>>>> needed there). >>>> >>>>> + a new entry for it and return unless it's a declaration >>>>> + involving a template that may need to be diagnosed by >>>>> + -Wredundant-tags. */ >>>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>>> - return; >>>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>>> + return; >>>> >>>> How can the first appearance of a class template be redundant? >>> >>> I'm not sure I correctly understand the question. The comment says >>> "involving a template" (i.e., not one of the first declaration of >>> a template). The test case that corresponds to this test is: >>> >>> template <class> struct S7 { }; >>> struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } >>> >>> where DECL is the TEPLATE_DECL of S7<void>. >>> >>> As I mentioned, more work is still needed to handle templates right >>> because some redundant tags are still not diagnosed. For example: >>> >>> template <class> struct S7 { }; >>> template <class T> >>> using U = struct S7<T>; // missing warning >> >> When we get here for an instance of a template, it doesn't make sense >> to treat it as a new type. >> >> If decl is a template and type_decl is an instance of that template, >> do we want to (before the lookup) change type_decl to the template or >> the corresponding generic TYPE_DECL, which should already be in the >> table? > > I'm struggling with how to do this. Given type (a RECORD_TYPE) and > type_decl (a TEMPLATE_DECL) representing the use of a template, how > do I get the corresponding template (or its explicit or partial > specialization) in the three cases below? > > 1) Instance of the primary: > template <class> class A; > struct A<int> a; > > 2) Instance of an explicit specialization: > template <class> class B; > template <> struct B<int>; > class B<int> b; > > 3) Instance of a partial specialization: > template <class> class C; > template <class T> struct C<T*>; > class C<int*> c; > > By trial and (lots of) error I figured out that in both (1) and (2), > but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns > the template's type_decl. > > Is there some function to call to get it in (3), or even better, > in all three cases? I think you're looking for most_general_template. Jason
On 3/9/20 1:40 PM, Jason Merrill wrote: > On 3/9/20 12:31 PM, Martin Sebor wrote: >> On 2/28/20 1:24 PM, Jason Merrill wrote: >>> On 2/28/20 12:45 PM, Martin Sebor wrote: >>>> On 2/28/20 9:58 AM, Jason Merrill wrote: >>>>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>>>> -Wredundant-tags doesn't consider type declarations that are also >>>>>> the first uses of the type, such as in 'void f (struct S);' and >>>>>> issues false positives for those. According to the reported that's >>>>>> making it harder to use the warning to clean up LibreOffice. >>>>>> >>>>>> The attached patch extends -Wredundant-tags to avoid these false >>>>>> positives by relying on the same class_decl_loc_t::class2loc mapping >>>>>> as -Wmismatched-tags. The patch also somewhat improves the detection >>>>>> of both issues in template declarations (though more work is still >>>>>> needed there). >>>>> >>>>>> + a new entry for it and return unless it's a declaration >>>>>> + involving a template that may need to be diagnosed by >>>>>> + -Wredundant-tags. */ >>>>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>>>> - return; >>>>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>>>> + return; >>>>> >>>>> How can the first appearance of a class template be redundant? >>>> >>>> I'm not sure I correctly understand the question. The comment says >>>> "involving a template" (i.e., not one of the first declaration of >>>> a template). The test case that corresponds to this test is: >>>> >>>> template <class> struct S7 { }; >>>> struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } >>>> >>>> where DECL is the TEPLATE_DECL of S7<void>. >>>> >>>> As I mentioned, more work is still needed to handle templates right >>>> because some redundant tags are still not diagnosed. For example: >>>> >>>> template <class> struct S7 { }; >>>> template <class T> >>>> using U = struct S7<T>; // missing warning >>> >>> When we get here for an instance of a template, it doesn't make sense >>> to treat it as a new type. >>> >>> If decl is a template and type_decl is an instance of that template, >>> do we want to (before the lookup) change type_decl to the template or >>> the corresponding generic TYPE_DECL, which should already be in the >>> table? >> >> I'm struggling with how to do this. Given type (a RECORD_TYPE) and >> type_decl (a TEMPLATE_DECL) representing the use of a template, how >> do I get the corresponding template (or its explicit or partial >> specialization) in the three cases below? >> >> 1) Instance of the primary: >> template <class> class A; >> struct A<int> a; >> >> 2) Instance of an explicit specialization: >> template <class> class B; >> template <> struct B<int>; >> class B<int> b; >> >> 3) Instance of a partial specialization: >> template <class> class C; >> template <class T> struct C<T*>; >> class C<int*> c; >> >> By trial and (lots of) error I figured out that in both (1) and (2), >> but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns >> the template's type_decl. >> >> Is there some function to call to get it in (3), or even better, >> in all three cases? > > I think you're looking for most_general_template. I don't think that's quite what I'm looking for. At least it doesn't return the template or its specialization in all three cases above. In (2) and (3) it won't distinguish between specializations of B or C on different types. In (2), the function returns the same result for both: template <> struct B<int>; template <> struct B<char>; In (3), it similarly returns the same result for both of template <class T> struct C<T*>; template <class T> struct C<const T>; even though they are declarations of distinct types. What I missing? Martin
On 3/9/20 5:39 PM, Martin Sebor wrote: > On 3/9/20 1:40 PM, Jason Merrill wrote: >> On 3/9/20 12:31 PM, Martin Sebor wrote: >>> On 2/28/20 1:24 PM, Jason Merrill wrote: >>>> On 2/28/20 12:45 PM, Martin Sebor wrote: >>>>> On 2/28/20 9:58 AM, Jason Merrill wrote: >>>>>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>>>>> -Wredundant-tags doesn't consider type declarations that are also >>>>>>> the first uses of the type, such as in 'void f (struct S);' and >>>>>>> issues false positives for those. According to the reported that's >>>>>>> making it harder to use the warning to clean up LibreOffice. >>>>>>> >>>>>>> The attached patch extends -Wredundant-tags to avoid these false >>>>>>> positives by relying on the same class_decl_loc_t::class2loc mapping >>>>>>> as -Wmismatched-tags. The patch also somewhat improves the >>>>>>> detection >>>>>>> of both issues in template declarations (though more work is still >>>>>>> needed there). >>>>>> >>>>>>> + a new entry for it and return unless it's a declaration >>>>>>> + involving a template that may need to be diagnosed by >>>>>>> + -Wredundant-tags. */ >>>>>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>>>>> - return; >>>>>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>>>>> + return; >>>>>> >>>>>> How can the first appearance of a class template be redundant? >>>>> >>>>> I'm not sure I correctly understand the question. The comment says >>>>> "involving a template" (i.e., not one of the first declaration of >>>>> a template). The test case that corresponds to this test is: >>>>> >>>>> template <class> struct S7 { }; >>>>> struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } >>>>> >>>>> where DECL is the TEPLATE_DECL of S7<void>. >>>>> >>>>> As I mentioned, more work is still needed to handle templates right >>>>> because some redundant tags are still not diagnosed. For example: >>>>> >>>>> template <class> struct S7 { }; >>>>> template <class T> >>>>> using U = struct S7<T>; // missing warning >>>> >>>> When we get here for an instance of a template, it doesn't make >>>> sense to treat it as a new type. >>>> >>>> If decl is a template and type_decl is an instance of that template, >>>> do we want to (before the lookup) change type_decl to the template >>>> or the corresponding generic TYPE_DECL, which should already be in >>>> the table? >>> >>> I'm struggling with how to do this. Given type (a RECORD_TYPE) and >>> type_decl (a TEMPLATE_DECL) representing the use of a template, how >>> do I get the corresponding template (or its explicit or partial >>> specialization) in the three cases below? >>> >>> 1) Instance of the primary: >>> template <class> class A; >>> struct A<int> a; >>> >>> 2) Instance of an explicit specialization: >>> template <class> class B; >>> template <> struct B<int>; >>> class B<int> b; >>> >>> 3) Instance of a partial specialization: >>> template <class> class C; >>> template <class T> struct C<T*>; >>> class C<int*> c; >>> >>> By trial and (lots of) error I figured out that in both (1) and (2), >>> but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns >>> the template's type_decl. >>> >>> Is there some function to call to get it in (3), or even better, >>> in all three cases? >> >> I think you're looking for most_general_template. > > I don't think that's quite what I'm looking for. At least it doesn't > return the template or its specialization in all three cases above. Ah, true, that function stops at specializations. Oddly, I don't think there's currently a similar function that looks through them. You could create one that does a simple loop through DECL_TI_TEMPLATE like is_specialization_of. > In (2) and (3) it won't distinguish between specializations of B or > C on different types. In (2), the function returns the same result > for both: > > template <> struct B<int>; > template <> struct B<char>; > > In (3), it similarly returns the same result for both of > > template <class T> struct C<T*>; > template <class T> struct C<const T>; > > even though they are declarations of distinct types. Jason
On 3/9/20 6:08 PM, Jason Merrill wrote: > On 3/9/20 5:39 PM, Martin Sebor wrote: >> On 3/9/20 1:40 PM, Jason Merrill wrote: >>> On 3/9/20 12:31 PM, Martin Sebor wrote: >>>> On 2/28/20 1:24 PM, Jason Merrill wrote: >>>>> On 2/28/20 12:45 PM, Martin Sebor wrote: >>>>>> On 2/28/20 9:58 AM, Jason Merrill wrote: >>>>>>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>>>>>> -Wredundant-tags doesn't consider type declarations that are also >>>>>>>> the first uses of the type, such as in 'void f (struct S);' and >>>>>>>> issues false positives for those. According to the reported that's >>>>>>>> making it harder to use the warning to clean up LibreOffice. >>>>>>>> >>>>>>>> The attached patch extends -Wredundant-tags to avoid these false >>>>>>>> positives by relying on the same class_decl_loc_t::class2loc >>>>>>>> mapping >>>>>>>> as -Wmismatched-tags. The patch also somewhat improves the >>>>>>>> detection >>>>>>>> of both issues in template declarations (though more work is still >>>>>>>> needed there). >>>>>>> >>>>>>>> + a new entry for it and return unless it's a declaration >>>>>>>> + involving a template that may need to be diagnosed by >>>>>>>> + -Wredundant-tags. */ >>>>>>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>>>>>> - return; >>>>>>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>>>>>> + return; >>>>>>> >>>>>>> How can the first appearance of a class template be redundant? >>>>>> >>>>>> I'm not sure I correctly understand the question. The comment says >>>>>> "involving a template" (i.e., not one of the first declaration of >>>>>> a template). The test case that corresponds to this test is: >>>>>> >>>>>> template <class> struct S7 { }; >>>>>> struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } >>>>>> >>>>>> where DECL is the TEPLATE_DECL of S7<void>. >>>>>> >>>>>> As I mentioned, more work is still needed to handle templates right >>>>>> because some redundant tags are still not diagnosed. For example: >>>>>> >>>>>> template <class> struct S7 { }; >>>>>> template <class T> >>>>>> using U = struct S7<T>; // missing warning >>>>> >>>>> When we get here for an instance of a template, it doesn't make >>>>> sense to treat it as a new type. >>>>> >>>>> If decl is a template and type_decl is an instance of that >>>>> template, do we want to (before the lookup) change type_decl to the >>>>> template or the corresponding generic TYPE_DECL, which should >>>>> already be in the table? >>>> >>>> I'm struggling with how to do this. Given type (a RECORD_TYPE) and >>>> type_decl (a TEMPLATE_DECL) representing the use of a template, how >>>> do I get the corresponding template (or its explicit or partial >>>> specialization) in the three cases below? >>>> >>>> 1) Instance of the primary: >>>> template <class> class A; >>>> struct A<int> a; >>>> >>>> 2) Instance of an explicit specialization: >>>> template <class> class B; >>>> template <> struct B<int>; >>>> class B<int> b; >>>> >>>> 3) Instance of a partial specialization: >>>> template <class> class C; >>>> template <class T> struct C<T*>; >>>> class C<int*> c; >>>> >>>> By trial and (lots of) error I figured out that in both (1) and (2), >>>> but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns >>>> the template's type_decl. >>>> >>>> Is there some function to call to get it in (3), or even better, >>>> in all three cases? >>> >>> I think you're looking for most_general_template. >> >> I don't think that's quite what I'm looking for. At least it doesn't >> return the template or its specialization in all three cases above. > > Ah, true, that function stops at specializations. Oddly, I don't think > there's currently a similar function that looks through them. You could > create one that does a simple loop through DECL_TI_TEMPLATE like > is_specialization_of. Thanks for the tip. Even with that I'm having trouble with partial specializations. For example in: template <class> struct S; template <class T> class S<const T>; extern class S<const int> s1; extern struct S<const int> s2; // expect -Wmismatched-tags how do I find the declaration of the partial specialization when given the type in the extern declaration? A loop in my find_template_for() function (similar to is_specialization_of) only visits the implicit specialization S<const int> (i.e., its own type) and the primary. Martin > >> In (2) and (3) it won't distinguish between specializations of B or >> C on different types. In (2), the function returns the same result >> for both: >> >> template <> struct B<int>; >> template <> struct B<char>; >> >> In (3), it similarly returns the same result for both of >> >> template <class T> struct C<T*>; >> template <class T> struct C<const T>; >> >> even though they are declarations of distinct types. > > > Jason >
On 3/11/20 12:57 PM, Martin Sebor wrote: > On 3/9/20 6:08 PM, Jason Merrill wrote: >> On 3/9/20 5:39 PM, Martin Sebor wrote: >>> On 3/9/20 1:40 PM, Jason Merrill wrote: >>>> On 3/9/20 12:31 PM, Martin Sebor wrote: >>>>> On 2/28/20 1:24 PM, Jason Merrill wrote: >>>>>> On 2/28/20 12:45 PM, Martin Sebor wrote: >>>>>>> On 2/28/20 9:58 AM, Jason Merrill wrote: >>>>>>>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>>>>>>> -Wredundant-tags doesn't consider type declarations that are also >>>>>>>>> the first uses of the type, such as in 'void f (struct S);' and >>>>>>>>> issues false positives for those. According to the reported >>>>>>>>> that's >>>>>>>>> making it harder to use the warning to clean up LibreOffice. >>>>>>>>> >>>>>>>>> The attached patch extends -Wredundant-tags to avoid these false >>>>>>>>> positives by relying on the same class_decl_loc_t::class2loc >>>>>>>>> mapping >>>>>>>>> as -Wmismatched-tags. The patch also somewhat improves the >>>>>>>>> detection >>>>>>>>> of both issues in template declarations (though more work is still >>>>>>>>> needed there). >>>>>>>> >>>>>>>>> + a new entry for it and return unless it's a declaration >>>>>>>>> + involving a template that may need to be diagnosed by >>>>>>>>> + -Wredundant-tags. */ >>>>>>>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>>>>>>> - return; >>>>>>>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>>>>>>> + return; >>>>>>>> >>>>>>>> How can the first appearance of a class template be redundant? >>>>>>> >>>>>>> I'm not sure I correctly understand the question. The comment says >>>>>>> "involving a template" (i.e., not one of the first declaration of >>>>>>> a template). The test case that corresponds to this test is: >>>>>>> >>>>>>> template <class> struct S7 { }; >>>>>>> struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } >>>>>>> >>>>>>> where DECL is the TEPLATE_DECL of S7<void>. >>>>>>> >>>>>>> As I mentioned, more work is still needed to handle templates right >>>>>>> because some redundant tags are still not diagnosed. For example: >>>>>>> >>>>>>> template <class> struct S7 { }; >>>>>>> template <class T> >>>>>>> using U = struct S7<T>; // missing warning >>>>>> >>>>>> When we get here for an instance of a template, it doesn't make >>>>>> sense to treat it as a new type. >>>>>> >>>>>> If decl is a template and type_decl is an instance of that >>>>>> template, do we want to (before the lookup) change type_decl to >>>>>> the template or the corresponding generic TYPE_DECL, which should >>>>>> already be in the table? >>>>> >>>>> I'm struggling with how to do this. Given type (a RECORD_TYPE) and >>>>> type_decl (a TEMPLATE_DECL) representing the use of a template, how >>>>> do I get the corresponding template (or its explicit or partial >>>>> specialization) in the three cases below? >>>>> >>>>> 1) Instance of the primary: >>>>> template <class> class A; >>>>> struct A<int> a; >>>>> >>>>> 2) Instance of an explicit specialization: >>>>> template <class> class B; >>>>> template <> struct B<int>; >>>>> class B<int> b; >>>>> >>>>> 3) Instance of a partial specialization: >>>>> template <class> class C; >>>>> template <class T> struct C<T*>; >>>>> class C<int*> c; >>>>> >>>>> By trial and (lots of) error I figured out that in both (1) and (2), >>>>> but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns >>>>> the template's type_decl. >>>>> >>>>> Is there some function to call to get it in (3), or even better, >>>>> in all three cases? >>>> >>>> I think you're looking for most_general_template. >>> >>> I don't think that's quite what I'm looking for. At least it doesn't >>> return the template or its specialization in all three cases above. >> >> Ah, true, that function stops at specializations. Oddly, I don't >> think there's currently a similar function that looks through them. >> You could create one that does a simple loop through DECL_TI_TEMPLATE >> like is_specialization_of. > > Thanks for the tip. Even with that I'm having trouble with partial > specializations. For example in: > > template <class> struct S; > template <class T> class S<const T>; > extern class S<const int> s1; > extern struct S<const int> s2; // expect -Wmismatched-tags > > how do I find the declaration of the partial specialization when given > the type in the extern declaration? A loop in my find_template_for() > function (similar to is_specialization_of) only visits the implicit > specialization S<const int> (i.e., its own type) and the primary. Is that a problem? The name is from the primary template, so does it matter for this warning whether there's an explicit specialization involved? > Martin > >> >>> In (2) and (3) it won't distinguish between specializations of B or >>> C on different types. In (2), the function returns the same result >>> for both: >>> >>> template <> struct B<int>; >>> template <> struct B<char>; >>> >>> In (3), it similarly returns the same result for both of >>> >>> template <class T> struct C<T*>; >>> template <class T> struct C<const T>; >>> >>> even though they are declarations of distinct types. >> >> >> Jason >> >
On 3/11/20 2:10 PM, Jason Merrill wrote: > On 3/11/20 12:57 PM, Martin Sebor wrote: >> On 3/9/20 6:08 PM, Jason Merrill wrote: >>> On 3/9/20 5:39 PM, Martin Sebor wrote: >>>> On 3/9/20 1:40 PM, Jason Merrill wrote: >>>>> On 3/9/20 12:31 PM, Martin Sebor wrote: >>>>>> On 2/28/20 1:24 PM, Jason Merrill wrote: >>>>>>> On 2/28/20 12:45 PM, Martin Sebor wrote: >>>>>>>> On 2/28/20 9:58 AM, Jason Merrill wrote: >>>>>>>>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>>>>>>>> -Wredundant-tags doesn't consider type declarations that are also >>>>>>>>>> the first uses of the type, such as in 'void f (struct S);' and >>>>>>>>>> issues false positives for those. According to the reported >>>>>>>>>> that's >>>>>>>>>> making it harder to use the warning to clean up LibreOffice. >>>>>>>>>> >>>>>>>>>> The attached patch extends -Wredundant-tags to avoid these false >>>>>>>>>> positives by relying on the same class_decl_loc_t::class2loc >>>>>>>>>> mapping >>>>>>>>>> as -Wmismatched-tags. The patch also somewhat improves the >>>>>>>>>> detection >>>>>>>>>> of both issues in template declarations (though more work is >>>>>>>>>> still >>>>>>>>>> needed there). >>>>>>>>> >>>>>>>>>> + a new entry for it and return unless it's a declaration >>>>>>>>>> + involving a template that may need to be diagnosed by >>>>>>>>>> + -Wredundant-tags. */ >>>>>>>>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>>>>>>>> - return; >>>>>>>>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>>>>>>>> + return; >>>>>>>>> >>>>>>>>> How can the first appearance of a class template be redundant? >>>>>>>> >>>>>>>> I'm not sure I correctly understand the question. The comment says >>>>>>>> "involving a template" (i.e., not one of the first declaration of >>>>>>>> a template). The test case that corresponds to this test is: >>>>>>>> >>>>>>>> template <class> struct S7 { }; >>>>>>>> struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } >>>>>>>> >>>>>>>> where DECL is the TEPLATE_DECL of S7<void>. >>>>>>>> >>>>>>>> As I mentioned, more work is still needed to handle templates right >>>>>>>> because some redundant tags are still not diagnosed. For example: >>>>>>>> >>>>>>>> template <class> struct S7 { }; >>>>>>>> template <class T> >>>>>>>> using U = struct S7<T>; // missing warning >>>>>>> >>>>>>> When we get here for an instance of a template, it doesn't make >>>>>>> sense to treat it as a new type. >>>>>>> >>>>>>> If decl is a template and type_decl is an instance of that >>>>>>> template, do we want to (before the lookup) change type_decl to >>>>>>> the template or the corresponding generic TYPE_DECL, which should >>>>>>> already be in the table? >>>>>> >>>>>> I'm struggling with how to do this. Given type (a RECORD_TYPE) and >>>>>> type_decl (a TEMPLATE_DECL) representing the use of a template, how >>>>>> do I get the corresponding template (or its explicit or partial >>>>>> specialization) in the three cases below? >>>>>> >>>>>> 1) Instance of the primary: >>>>>> template <class> class A; >>>>>> struct A<int> a; >>>>>> >>>>>> 2) Instance of an explicit specialization: >>>>>> template <class> class B; >>>>>> template <> struct B<int>; >>>>>> class B<int> b; >>>>>> >>>>>> 3) Instance of a partial specialization: >>>>>> template <class> class C; >>>>>> template <class T> struct C<T*>; >>>>>> class C<int*> c; >>>>>> >>>>>> By trial and (lots of) error I figured out that in both (1) and (2), >>>>>> but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns >>>>>> the template's type_decl. >>>>>> >>>>>> Is there some function to call to get it in (3), or even better, >>>>>> in all three cases? >>>>> >>>>> I think you're looking for most_general_template. >>>> >>>> I don't think that's quite what I'm looking for. At least it doesn't >>>> return the template or its specialization in all three cases above. >>> >>> Ah, true, that function stops at specializations. Oddly, I don't >>> think there's currently a similar function that looks through them. >>> You could create one that does a simple loop through DECL_TI_TEMPLATE >>> like is_specialization_of. >> >> Thanks for the tip. Even with that I'm having trouble with partial >> specializations. For example in: >> >> template <class> struct S; >> template <class T> class S<const T>; >> extern class S<const int> s1; >> extern struct S<const int> s2; // expect -Wmismatched-tags >> >> how do I find the declaration of the partial specialization when given >> the type in the extern declaration? A loop in my find_template_for() >> function (similar to is_specialization_of) only visits the implicit >> specialization S<const int> (i.e., its own type) and the primary. > > Is that a problem? The name is from the primary template, so does it > matter for this warning whether there's an explicit specialization > involved? I don't understand the question. S<const int> is an instance of the partial specialization. To diagnose the right mismatch the warning needs to know how to find the template (i.e., either the primary, or the explicit or partial specialization) the instance corresponds to and the class-key it was declared with. As it is, while GCC does diagnose the right declaration (that of s2), it does that thanks to a bug: because it finds and uses the type and class-key used to declare s1. If we get rid of s1 it doesn't diagnose anything. I tried using DECL_TEMPLATE_SPECIALIZATIONS() to get the list of the partial specializations but it doesn't like any of the arguments I've given it (it ICEs). Martin PS As an aside, both Clang and VC++ have trouble with templates as well, just slightly different kinds of trouble. Clang diagnoses the declaration of the partial specialization while VC++ diagnoses s1. In other similar cases like the one below VC++ does the right thing and Clang is silent. template <class> struct S { }; template <class T> class S<const T> { }; template <class T> void f (class S<T>); // VC++ warns template <class T> void g (struct S<const T>); // GCC & VC++ warn > >> Martin >> >>> >>>> In (2) and (3) it won't distinguish between specializations of B or >>>> C on different types. In (2), the function returns the same result >>>> for both: >>>> >>>> template <> struct B<int>; >>>> template <> struct B<char>; >>>> >>>> In (3), it similarly returns the same result for both of >>>> >>>> template <class T> struct C<T*>; >>>> template <class T> struct C<const T>; >>>> >>>> even though they are declarations of distinct types. >>> >>> >>> Jason >>> >> >
On 3/11/20 3:30 PM, Martin Sebor wrote: > On 3/11/20 2:10 PM, Jason Merrill wrote: >> On 3/11/20 12:57 PM, Martin Sebor wrote: >>> On 3/9/20 6:08 PM, Jason Merrill wrote: >>>> On 3/9/20 5:39 PM, Martin Sebor wrote: >>>>> On 3/9/20 1:40 PM, Jason Merrill wrote: >>>>>> On 3/9/20 12:31 PM, Martin Sebor wrote: >>>>>>> On 2/28/20 1:24 PM, Jason Merrill wrote: >>>>>>>> On 2/28/20 12:45 PM, Martin Sebor wrote: >>>>>>>>> On 2/28/20 9:58 AM, Jason Merrill wrote: >>>>>>>>>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>>>>>>>>> -Wredundant-tags doesn't consider type declarations that are >>>>>>>>>>> also >>>>>>>>>>> the first uses of the type, such as in 'void f (struct S);' and >>>>>>>>>>> issues false positives for those. According to the reported >>>>>>>>>>> that's >>>>>>>>>>> making it harder to use the warning to clean up LibreOffice. >>>>>>>>>>> >>>>>>>>>>> The attached patch extends -Wredundant-tags to avoid these false >>>>>>>>>>> positives by relying on the same class_decl_loc_t::class2loc >>>>>>>>>>> mapping >>>>>>>>>>> as -Wmismatched-tags. The patch also somewhat improves the >>>>>>>>>>> detection >>>>>>>>>>> of both issues in template declarations (though more work is >>>>>>>>>>> still >>>>>>>>>>> needed there). >>>>>>>>>> >>>>>>>>>>> + a new entry for it and return unless it's a >>>>>>>>>>> declaration >>>>>>>>>>> + involving a template that may need to be diagnosed by >>>>>>>>>>> + -Wredundant-tags. */ >>>>>>>>>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>>>>>>>>> - return; >>>>>>>>>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>>>>>>>>> + return; >>>>>>>>>> >>>>>>>>>> How can the first appearance of a class template be redundant? >>>>>>>>> >>>>>>>>> I'm not sure I correctly understand the question. The comment >>>>>>>>> says >>>>>>>>> "involving a template" (i.e., not one of the first declaration of >>>>>>>>> a template). The test case that corresponds to this test is: >>>>>>>>> >>>>>>>>> template <class> struct S7 { }; >>>>>>>>> struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } >>>>>>>>> >>>>>>>>> where DECL is the TEPLATE_DECL of S7<void>. >>>>>>>>> >>>>>>>>> As I mentioned, more work is still needed to handle templates >>>>>>>>> right >>>>>>>>> because some redundant tags are still not diagnosed. For example: >>>>>>>>> >>>>>>>>> template <class> struct S7 { }; >>>>>>>>> template <class T> >>>>>>>>> using U = struct S7<T>; // missing warning >>>>>>>> >>>>>>>> When we get here for an instance of a template, it doesn't make >>>>>>>> sense to treat it as a new type. >>>>>>>> >>>>>>>> If decl is a template and type_decl is an instance of that >>>>>>>> template, do we want to (before the lookup) change type_decl to >>>>>>>> the template or the corresponding generic TYPE_DECL, which >>>>>>>> should already be in the table? >>>>>>> >>>>>>> I'm struggling with how to do this. Given type (a RECORD_TYPE) and >>>>>>> type_decl (a TEMPLATE_DECL) representing the use of a template, how >>>>>>> do I get the corresponding template (or its explicit or partial >>>>>>> specialization) in the three cases below? >>>>>>> >>>>>>> 1) Instance of the primary: >>>>>>> template <class> class A; >>>>>>> struct A<int> a; >>>>>>> >>>>>>> 2) Instance of an explicit specialization: >>>>>>> template <class> class B; >>>>>>> template <> struct B<int>; >>>>>>> class B<int> b; >>>>>>> >>>>>>> 3) Instance of a partial specialization: >>>>>>> template <class> class C; >>>>>>> template <class T> struct C<T*>; >>>>>>> class C<int*> c; >>>>>>> >>>>>>> By trial and (lots of) error I figured out that in both (1) and (2), >>>>>>> but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns >>>>>>> the template's type_decl. >>>>>>> >>>>>>> Is there some function to call to get it in (3), or even better, >>>>>>> in all three cases? >>>>>> >>>>>> I think you're looking for most_general_template. >>>>> >>>>> I don't think that's quite what I'm looking for. At least it doesn't >>>>> return the template or its specialization in all three cases above. >>>> >>>> Ah, true, that function stops at specializations. Oddly, I don't >>>> think there's currently a similar function that looks through them. >>>> You could create one that does a simple loop through >>>> DECL_TI_TEMPLATE like is_specialization_of. >>> >>> Thanks for the tip. Even with that I'm having trouble with partial >>> specializations. For example in: >>> >>> template <class> struct S; >>> template <class T> class S<const T>; >>> extern class S<const int> s1; >>> extern struct S<const int> s2; // expect -Wmismatched-tags >>> >>> how do I find the declaration of the partial specialization when given >>> the type in the extern declaration? A loop in my find_template_for() >>> function (similar to is_specialization_of) only visits the implicit >>> specialization S<const int> (i.e., its own type) and the primary. >> >> Is that a problem? The name is from the primary template, so does it >> matter for this warning whether there's an explicit specialization >> involved? > > I don't understand the question. S<const int> is an instance of > the partial specialization. To diagnose the right mismatch the warning > needs to know how to find the template (i.e., either the primary, or > the explicit or partial specialization) the instance corresponds to and > the class-key it was declared with. As it is, while GCC does diagnose > the right declaration (that of s2), it does that thanks to a bug: > because it finds and uses the type and class-key used to declare s1. > If we get rid of s1 it doesn't diagnose anything. > > I tried using DECL_TEMPLATE_SPECIALIZATIONS() to get the list of > the partial specializations but it doesn't like any of the arguments > I've given it (it ICEs). With this fixed, here's the algorithm I tried: 1) for a type T of a template instantiation (s1 above), get the primary P that T was instantiated from using P = TYPE_MAIN_DECL (CLASSTYPE_PRIMARY_TEMPLATE_TYPE (T)), 2) from P, get the chain of its specializations using SC = DECL_TEMPLATE_SPECIALIZATIONS (P) 3) for each (partial) specialization S on the SC chain get the chain of its instantiations IC using DECL_TEMPLATE_INSTANTIATIONS, if is_specialization_of (T, TREE_VALUE (IC)) is non-zero take TREE_VALUE (SC) as the declaration of the partial specialization that the template instanstantiaton T was generated from. Unfortunately, in the example above, DECL_TEMPLATE_INSTANTIATIONS for the partial specialization 'class S<const T>' is null (even after all the declarations have been parsed) so I'm at a dead end. The other recurring problem I'm running into is that many of the C++ FE macros (and APIs) don't always return the expected/documented result. I think this is at least in part because until a declaration has been fully parsed not all the bits are in place to make it possible to tell if it's an implicit or explicit specialization, for example (so CLASSTYPE_USE_TEMPLATE (T) is 1 for the first-time declaration of an explicit specialization, for example). But in view of the problem above I'm not sure that's the only reason. > > Martin > > PS As an aside, both Clang and VC++ have trouble with templates as > well, just slightly different kinds of trouble. Clang diagnoses > the declaration of the partial specialization while VC++ diagnoses > s1. In other similar cases like the one below VC++ does the right > thing and Clang is silent. > > template <class> struct S { }; > template <class T> class S<const T> { }; > > template <class T> void f (class S<T>); // VC++ warns > template <class T> void g (struct S<const T>); // GCC & VC++ warn > >> >>> Martin >>> >>>> >>>>> In (2) and (3) it won't distinguish between specializations of B or >>>>> C on different types. In (2), the function returns the same result >>>>> for both: >>>>> >>>>> template <> struct B<int>; >>>>> template <> struct B<char>; >>>>> >>>>> In (3), it similarly returns the same result for both of >>>>> >>>>> template <class T> struct C<T*>; >>>>> template <class T> struct C<const T>; >>>>> >>>>> even though they are declarations of distinct types. >>>> >>>> >>>> Jason >>>> >>> >> >
On 3/12/20 11:03 AM, Martin Sebor wrote: > On 3/11/20 3:30 PM, Martin Sebor wrote: >> On 3/11/20 2:10 PM, Jason Merrill wrote: >>> On 3/11/20 12:57 PM, Martin Sebor wrote: >>>> On 3/9/20 6:08 PM, Jason Merrill wrote: >>>>> On 3/9/20 5:39 PM, Martin Sebor wrote: >>>>>> On 3/9/20 1:40 PM, Jason Merrill wrote: >>>>>>> On 3/9/20 12:31 PM, Martin Sebor wrote: >>>>>>>> On 2/28/20 1:24 PM, Jason Merrill wrote: >>>>>>>>> On 2/28/20 12:45 PM, Martin Sebor wrote: >>>>>>>>>> On 2/28/20 9:58 AM, Jason Merrill wrote: >>>>>>>>>>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>>>>>>>>>> -Wredundant-tags doesn't consider type declarations that are >>>>>>>>>>>> also >>>>>>>>>>>> the first uses of the type, such as in 'void f (struct S);' and >>>>>>>>>>>> issues false positives for those. According to the reported >>>>>>>>>>>> that's >>>>>>>>>>>> making it harder to use the warning to clean up LibreOffice. >>>>>>>>>>>> >>>>>>>>>>>> The attached patch extends -Wredundant-tags to avoid these >>>>>>>>>>>> false >>>>>>>>>>>> positives by relying on the same class_decl_loc_t::class2loc >>>>>>>>>>>> mapping >>>>>>>>>>>> as -Wmismatched-tags. The patch also somewhat improves the >>>>>>>>>>>> detection >>>>>>>>>>>> of both issues in template declarations (though more work is >>>>>>>>>>>> still >>>>>>>>>>>> needed there). >>>>>>>>>>> >>>>>>>>>>>> + a new entry for it and return unless it's a >>>>>>>>>>>> declaration >>>>>>>>>>>> + involving a template that may need to be diagnosed by >>>>>>>>>>>> + -Wredundant-tags. */ >>>>>>>>>>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>>>>>>>>>> - return; >>>>>>>>>>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>>>>>>>>>> + return; >>>>>>>>>>> >>>>>>>>>>> How can the first appearance of a class template be redundant? >>>>>>>>>> >>>>>>>>>> I'm not sure I correctly understand the question. The comment >>>>>>>>>> says >>>>>>>>>> "involving a template" (i.e., not one of the first declaration of >>>>>>>>>> a template). The test case that corresponds to this test is: >>>>>>>>>> >>>>>>>>>> template <class> struct S7 { }; >>>>>>>>>> struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" } >>>>>>>>>> >>>>>>>>>> where DECL is the TEPLATE_DECL of S7<void>. >>>>>>>>>> >>>>>>>>>> As I mentioned, more work is still needed to handle templates >>>>>>>>>> right >>>>>>>>>> because some redundant tags are still not diagnosed. For >>>>>>>>>> example: >>>>>>>>>> >>>>>>>>>> template <class> struct S7 { }; >>>>>>>>>> template <class T> >>>>>>>>>> using U = struct S7<T>; // missing warning >>>>>>>>> >>>>>>>>> When we get here for an instance of a template, it doesn't make >>>>>>>>> sense to treat it as a new type. >>>>>>>>> >>>>>>>>> If decl is a template and type_decl is an instance of that >>>>>>>>> template, do we want to (before the lookup) change type_decl to >>>>>>>>> the template or the corresponding generic TYPE_DECL, which >>>>>>>>> should already be in the table? >>>>>>>> >>>>>>>> I'm struggling with how to do this. Given type (a RECORD_TYPE) and >>>>>>>> type_decl (a TEMPLATE_DECL) representing the use of a template, how >>>>>>>> do I get the corresponding template (or its explicit or partial >>>>>>>> specialization) in the three cases below? >>>>>>>> >>>>>>>> 1) Instance of the primary: >>>>>>>> template <class> class A; >>>>>>>> struct A<int> a; >>>>>>>> >>>>>>>> 2) Instance of an explicit specialization: >>>>>>>> template <class> class B; >>>>>>>> template <> struct B<int>; >>>>>>>> class B<int> b; >>>>>>>> >>>>>>>> 3) Instance of a partial specialization: >>>>>>>> template <class> class C; >>>>>>>> template <class T> struct C<T*>; >>>>>>>> class C<int*> c; >>>>>>>> >>>>>>>> By trial and (lots of) error I figured out that in both (1) and >>>>>>>> (2), >>>>>>>> but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns >>>>>>>> the template's type_decl. >>>>>>>> >>>>>>>> Is there some function to call to get it in (3), or even better, >>>>>>>> in all three cases? >>>>>>> >>>>>>> I think you're looking for most_general_template. >>>>>> >>>>>> I don't think that's quite what I'm looking for. At least it doesn't >>>>>> return the template or its specialization in all three cases above. >>>>> >>>>> Ah, true, that function stops at specializations. Oddly, I don't >>>>> think there's currently a similar function that looks through them. >>>>> You could create one that does a simple loop through >>>>> DECL_TI_TEMPLATE like is_specialization_of. >>>> >>>> Thanks for the tip. Even with that I'm having trouble with partial >>>> specializations. For example in: >>>> >>>> template <class> struct S; >>>> template <class T> class S<const T>; >>>> extern class S<const int> s1; >>>> extern struct S<const int> s2; // expect -Wmismatched-tags >>>> >>>> how do I find the declaration of the partial specialization when given >>>> the type in the extern declaration? A loop in my find_template_for() >>>> function (similar to is_specialization_of) only visits the implicit >>>> specialization S<const int> (i.e., its own type) and the primary. >>> >>> Is that a problem? The name is from the primary template, so does it >>> matter for this warning whether there's an explicit specialization >>> involved? >> >> I don't understand the question. S<const int> is an instance of >> the partial specialization. To diagnose the right mismatch the warning >> needs to know how to find the template (i.e., either the primary, or >> the explicit or partial specialization) the instance corresponds to and >> the class-key it was declared with. As it is, while GCC does diagnose >> the right declaration (that of s2), it does that thanks to a bug: >> because it finds and uses the type and class-key used to declare s1. >> If we get rid of s1 it doesn't diagnose anything. >> >> I tried using DECL_TEMPLATE_SPECIALIZATIONS() to get the list of >> the partial specializations but it doesn't like any of the arguments >> I've given it (it ICEs). > > With this fixed, here's the algorithm I tried: > > 1) for a type T of a template instantiation (s1 above), get the primary > P that T was instantiated from using > P = TYPE_MAIN_DECL (CLASSTYPE_PRIMARY_TEMPLATE_TYPE (T)), > 2) from P, get the chain of its specializations using > SC = DECL_TEMPLATE_SPECIALIZATIONS (P) > 3) for each (partial) specialization S on the SC chain get the chain > of its instantiations IC using DECL_TEMPLATE_INSTANTIATIONS, if > is_specialization_of (T, TREE_VALUE (IC)) is non-zero take > TREE_VALUE (SC) as the declaration of the partial specialization > that the template instanstantiaton T was generated from. > > Unfortunately, in the example above, DECL_TEMPLATE_INSTANTIATIONS for > the partial specialization 'class S<const T>' is null (even after all > the declarations have been parsed) so I'm at a dead end. After a lot more trial and error I discovered most_specialized_partial_spec in pt.c with whose help I have been able to get templates to work the way I think they should (at least the cases I've tested do). Besides fixing the original problem that motivated it, the attached patch also corrects how template specializations are handled: the first declaration of either a primary template or its specialization (either explicit or partial) determines the class-key in subsequent uses of the type or its instantiations. To do this for uses of first-time template instantiations such as in the declaration of s1 in the test case above, class_decl_loc_t::diag_mismatched_tags looks up the template (either the primary or the partial specialization) in the CLASS2LOC map and uses it and its class-key as the guide when issuing diagnostics. This also means that the first instance of every template needs to have a record in the CLASS2LOC map (it also needs it to compare its class-key to subsequent redeclarations of the template). This has been unexpectedly difficult. A big part of it is that I've never before worked with templates in the front-end so I had to learn how they're organized (I'm far from having mastered it). What's made the learning curve especially steep, besides the sparse documentation, is the problems hinted at in the paragraph below below. This whole area could really stand to be documented in some sort of a writeup: a high-level overview of how templates are put together (i.e., what hangs off what in the tree representation) and what APIs to use to work with them. The revised patch has been tested on x86_64-linux. Martin > The other recurring problem I'm running into is that many of the C++ > FE macros (and APIs) don't always return the expected/documented result. > I think this is at least in part because until a declaration has been > fully parsed not all the bits are in place to make it possible to tell > if it's an implicit or explicit specialization, for example (so > CLASSTYPE_USE_TEMPLATE (T) is 1 for the first-time declaration of > an explicit specialization, for example). But in view of the problem > above I'm not sure that's the only reason. > >> >> Martin >> >> PS As an aside, both Clang and VC++ have trouble with templates as >> well, just slightly different kinds of trouble. Clang diagnoses >> the declaration of the partial specialization while VC++ diagnoses >> s1. In other similar cases like the one below VC++ does the right >> thing and Clang is silent. >> >> template <class> struct S { }; >> template <class T> class S<const T> { }; >> >> template <class T> void f (class S<T>); // VC++ warns >> template <class T> void g (struct S<const T>); // GCC & VC++ warn >> >>> >>>> Martin >>>> >>>>> >>>>>> In (2) and (3) it won't distinguish between specializations of B or >>>>>> C on different types. In (2), the function returns the same result >>>>>> for both: >>>>>> >>>>>> template <> struct B<int>; >>>>>> template <> struct B<char>; >>>>>> >>>>>> In (3), it similarly returns the same result for both of >>>>>> >>>>>> template <class T> struct C<T*>; >>>>>> template <class T> struct C<const T>; >>>>>> >>>>>> even though they are declarations of distinct types. >>>>> >>>>> >>>>> Jason >>>>> >>>> >>> >> >
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541962.html On 3/12/20 4:38 PM, Martin Sebor wrote: > On 3/12/20 11:03 AM, Martin Sebor wrote: >> On 3/11/20 3:30 PM, Martin Sebor wrote: >>> On 3/11/20 2:10 PM, Jason Merrill wrote: >>>> On 3/11/20 12:57 PM, Martin Sebor wrote: >>>>> On 3/9/20 6:08 PM, Jason Merrill wrote: >>>>>> On 3/9/20 5:39 PM, Martin Sebor wrote: >>>>>>> On 3/9/20 1:40 PM, Jason Merrill wrote: >>>>>>>> On 3/9/20 12:31 PM, Martin Sebor wrote: >>>>>>>>> On 2/28/20 1:24 PM, Jason Merrill wrote: >>>>>>>>>> On 2/28/20 12:45 PM, Martin Sebor wrote: >>>>>>>>>>> On 2/28/20 9:58 AM, Jason Merrill wrote: >>>>>>>>>>>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>>>>>>>>>>> -Wredundant-tags doesn't consider type declarations that >>>>>>>>>>>>> are also >>>>>>>>>>>>> the first uses of the type, such as in 'void f (struct S);' >>>>>>>>>>>>> and >>>>>>>>>>>>> issues false positives for those. According to the >>>>>>>>>>>>> reported that's >>>>>>>>>>>>> making it harder to use the warning to clean up LibreOffice. >>>>>>>>>>>>> >>>>>>>>>>>>> The attached patch extends -Wredundant-tags to avoid these >>>>>>>>>>>>> false >>>>>>>>>>>>> positives by relying on the same >>>>>>>>>>>>> class_decl_loc_t::class2loc mapping >>>>>>>>>>>>> as -Wmismatched-tags. The patch also somewhat improves the >>>>>>>>>>>>> detection >>>>>>>>>>>>> of both issues in template declarations (though more work >>>>>>>>>>>>> is still >>>>>>>>>>>>> needed there). >>>>>>>>>>>> >>>>>>>>>>>>> + a new entry for it and return unless it's a >>>>>>>>>>>>> declaration >>>>>>>>>>>>> + involving a template that may need to be >>>>>>>>>>>>> diagnosed by >>>>>>>>>>>>> + -Wredundant-tags. */ >>>>>>>>>>>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>>>>>>>>>>> - return; >>>>>>>>>>>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>>>>>>>>>>> + return; >>>>>>>>>>>> >>>>>>>>>>>> How can the first appearance of a class template be redundant? >>>>>>>>>>> >>>>>>>>>>> I'm not sure I correctly understand the question. The >>>>>>>>>>> comment says >>>>>>>>>>> "involving a template" (i.e., not one of the first >>>>>>>>>>> declaration of >>>>>>>>>>> a template). The test case that corresponds to this test is: >>>>>>>>>>> >>>>>>>>>>> template <class> struct S7 { }; >>>>>>>>>>> struct S7<void> s7v; // { dg-warning >>>>>>>>>>> "\\\[-Wredundant-tags" } >>>>>>>>>>> >>>>>>>>>>> where DECL is the TEPLATE_DECL of S7<void>. >>>>>>>>>>> >>>>>>>>>>> As I mentioned, more work is still needed to handle templates >>>>>>>>>>> right >>>>>>>>>>> because some redundant tags are still not diagnosed. For >>>>>>>>>>> example: >>>>>>>>>>> >>>>>>>>>>> template <class> struct S7 { }; >>>>>>>>>>> template <class T> >>>>>>>>>>> using U = struct S7<T>; // missing warning >>>>>>>>>> >>>>>>>>>> When we get here for an instance of a template, it doesn't >>>>>>>>>> make sense to treat it as a new type. >>>>>>>>>> >>>>>>>>>> If decl is a template and type_decl is an instance of that >>>>>>>>>> template, do we want to (before the lookup) change type_decl >>>>>>>>>> to the template or the corresponding generic TYPE_DECL, which >>>>>>>>>> should already be in the table? >>>>>>>>> >>>>>>>>> I'm struggling with how to do this. Given type (a RECORD_TYPE) >>>>>>>>> and >>>>>>>>> type_decl (a TEMPLATE_DECL) representing the use of a template, >>>>>>>>> how >>>>>>>>> do I get the corresponding template (or its explicit or partial >>>>>>>>> specialization) in the three cases below? >>>>>>>>> >>>>>>>>> 1) Instance of the primary: >>>>>>>>> template <class> class A; >>>>>>>>> struct A<int> a; >>>>>>>>> >>>>>>>>> 2) Instance of an explicit specialization: >>>>>>>>> template <class> class B; >>>>>>>>> template <> struct B<int>; >>>>>>>>> class B<int> b; >>>>>>>>> >>>>>>>>> 3) Instance of a partial specialization: >>>>>>>>> template <class> class C; >>>>>>>>> template <class T> struct C<T*>; >>>>>>>>> class C<int*> c; >>>>>>>>> >>>>>>>>> By trial and (lots of) error I figured out that in both (1) and >>>>>>>>> (2), >>>>>>>>> but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns >>>>>>>>> the template's type_decl. >>>>>>>>> >>>>>>>>> Is there some function to call to get it in (3), or even better, >>>>>>>>> in all three cases? >>>>>>>> >>>>>>>> I think you're looking for most_general_template. >>>>>>> >>>>>>> I don't think that's quite what I'm looking for. At least it >>>>>>> doesn't >>>>>>> return the template or its specialization in all three cases above. >>>>>> >>>>>> Ah, true, that function stops at specializations. Oddly, I don't >>>>>> think there's currently a similar function that looks through >>>>>> them. You could create one that does a simple loop through >>>>>> DECL_TI_TEMPLATE like is_specialization_of. >>>>> >>>>> Thanks for the tip. Even with that I'm having trouble with partial >>>>> specializations. For example in: >>>>> >>>>> template <class> struct S; >>>>> template <class T> class S<const T>; >>>>> extern class S<const int> s1; >>>>> extern struct S<const int> s2; // expect -Wmismatched-tags >>>>> >>>>> how do I find the declaration of the partial specialization when given >>>>> the type in the extern declaration? A loop in my find_template_for() >>>>> function (similar to is_specialization_of) only visits the implicit >>>>> specialization S<const int> (i.e., its own type) and the primary. >>>> >>>> Is that a problem? The name is from the primary template, so does >>>> it matter for this warning whether there's an explicit >>>> specialization involved? >>> >>> I don't understand the question. S<const int> is an instance of >>> the partial specialization. To diagnose the right mismatch the warning >>> needs to know how to find the template (i.e., either the primary, or >>> the explicit or partial specialization) the instance corresponds to and >>> the class-key it was declared with. As it is, while GCC does diagnose >>> the right declaration (that of s2), it does that thanks to a bug: >>> because it finds and uses the type and class-key used to declare s1. >>> If we get rid of s1 it doesn't diagnose anything. >>> >>> I tried using DECL_TEMPLATE_SPECIALIZATIONS() to get the list of >>> the partial specializations but it doesn't like any of the arguments >>> I've given it (it ICEs). >> >> With this fixed, here's the algorithm I tried: >> >> 1) for a type T of a template instantiation (s1 above), get the primary >> P that T was instantiated from using >> P = TYPE_MAIN_DECL (CLASSTYPE_PRIMARY_TEMPLATE_TYPE (T)), >> 2) from P, get the chain of its specializations using >> SC = DECL_TEMPLATE_SPECIALIZATIONS (P) >> 3) for each (partial) specialization S on the SC chain get the chain >> of its instantiations IC using DECL_TEMPLATE_INSTANTIATIONS, if >> is_specialization_of (T, TREE_VALUE (IC)) is non-zero take >> TREE_VALUE (SC) as the declaration of the partial specialization >> that the template instanstantiaton T was generated from. >> >> Unfortunately, in the example above, DECL_TEMPLATE_INSTANTIATIONS for >> the partial specialization 'class S<const T>' is null (even after all >> the declarations have been parsed) so I'm at a dead end. > > After a lot more trial and error I discovered > most_specialized_partial_spec in pt.c with whose help I have been able > to get templates to work the way I think they should (at least the cases > I've tested do). > > Besides fixing the original problem that motivated it, the attached > patch also corrects how template specializations are handled: the first > declaration of either a primary template or its specialization (either > explicit or partial) determines the class-key in subsequent uses of > the type or its instantiations. To do this for uses of first-time > template instantiations such as in the declaration of s1 in the test > case above, class_decl_loc_t::diag_mismatched_tags looks up the template > (either the primary or the partial specialization) in the CLASS2LOC map > and uses it and its class-key as the guide when issuing diagnostics. > This also means that the first instance of every template needs to > have a record in the CLASS2LOC map (it also needs it to compare its > class-key to subsequent redeclarations of the template). > > This has been unexpectedly difficult. A big part of it is that I've > never before worked with templates in the front-end so I had to learn > how they're organized (I'm far from having mastered it). What's made > the learning curve especially steep, besides the sparse documentation, > is the problems hinted at in the paragraph below below. This whole > area could really stand to be documented in some sort of a writeup: > a high-level overview of how templates are put together (i.e., what > hangs off what in the tree representation) and what APIs to use to > work with them. > > The revised patch has been tested on x86_64-linux. > > Martin > > >> The other recurring problem I'm running into is that many of the C++ >> FE macros (and APIs) don't always return the expected/documented result. >> I think this is at least in part because until a declaration has been >> fully parsed not all the bits are in place to make it possible to tell >> if it's an implicit or explicit specialization, for example (so >> CLASSTYPE_USE_TEMPLATE (T) is 1 for the first-time declaration of >> an explicit specialization, for example). But in view of the problem >> above I'm not sure that's the only reason. >> >>> >>> Martin >>> >>> PS As an aside, both Clang and VC++ have trouble with templates as >>> well, just slightly different kinds of trouble. Clang diagnoses >>> the declaration of the partial specialization while VC++ diagnoses >>> s1. In other similar cases like the one below VC++ does the right >>> thing and Clang is silent. >>> >>> template <class> struct S { }; >>> template <class T> class S<const T> { }; >>> >>> template <class T> void f (class S<T>); // VC++ warns >>> template <class T> void g (struct S<const T>); // GCC & VC++ warn >>> >>>> >>>>> Martin >>>>> >>>>>> >>>>>>> In (2) and (3) it won't distinguish between specializations of B or >>>>>>> C on different types. In (2), the function returns the same result >>>>>>> for both: >>>>>>> >>>>>>> template <> struct B<int>; >>>>>>> template <> struct B<char>; >>>>>>> >>>>>>> In (3), it similarly returns the same result for both of >>>>>>> >>>>>>> template <class T> struct C<T*>; >>>>>>> template <class T> struct C<const T>; >>>>>>> >>>>>>> even though they are declarations of distinct types. >>>>>> >>>>>> >>>>>> Jason >>>>>> >>>>> >>>> >>> >> >
On 3/12/20 6:38 PM, Martin Sebor wrote: > On 3/12/20 11:03 AM, Martin Sebor wrote: >> On 3/11/20 3:30 PM, Martin Sebor wrote: >>> On 3/11/20 2:10 PM, Jason Merrill wrote: >>>> On 3/11/20 12:57 PM, Martin Sebor wrote: >>>>> On 3/9/20 6:08 PM, Jason Merrill wrote: >>>>>> On 3/9/20 5:39 PM, Martin Sebor wrote: >>>>>>> On 3/9/20 1:40 PM, Jason Merrill wrote: >>>>>>>> On 3/9/20 12:31 PM, Martin Sebor wrote: >>>>>>>>> On 2/28/20 1:24 PM, Jason Merrill wrote: >>>>>>>>>> On 2/28/20 12:45 PM, Martin Sebor wrote: >>>>>>>>>>> On 2/28/20 9:58 AM, Jason Merrill wrote: >>>>>>>>>>>> On 2/24/20 6:58 PM, Martin Sebor wrote: >>>>>>>>>>>>> -Wredundant-tags doesn't consider type declarations that >>>>>>>>>>>>> are also >>>>>>>>>>>>> the first uses of the type, such as in 'void f (struct S);' >>>>>>>>>>>>> and >>>>>>>>>>>>> issues false positives for those. According to the >>>>>>>>>>>>> reported that's >>>>>>>>>>>>> making it harder to use the warning to clean up LibreOffice. >>>>>>>>>>>>> >>>>>>>>>>>>> The attached patch extends -Wredundant-tags to avoid these >>>>>>>>>>>>> false >>>>>>>>>>>>> positives by relying on the same >>>>>>>>>>>>> class_decl_loc_t::class2loc mapping >>>>>>>>>>>>> as -Wmismatched-tags. The patch also somewhat improves the >>>>>>>>>>>>> detection >>>>>>>>>>>>> of both issues in template declarations (though more work >>>>>>>>>>>>> is still >>>>>>>>>>>>> needed there). >>>>>>>>>>>> >>>>>>>>>>>>> + a new entry for it and return unless it's a >>>>>>>>>>>>> declaration >>>>>>>>>>>>> + involving a template that may need to be >>>>>>>>>>>>> diagnosed by >>>>>>>>>>>>> + -Wredundant-tags. */ >>>>>>>>>>>>> *rdl = class_decl_loc_t (class_key, false, def_p); >>>>>>>>>>>>> - return; >>>>>>>>>>>>> + if (TREE_CODE (decl) != TEMPLATE_DECL) >>>>>>>>>>>>> + return; >>>>>>>>>>>> >>>>>>>>>>>> How can the first appearance of a class template be redundant? >>>>>>>>>>> >>>>>>>>>>> I'm not sure I correctly understand the question. The >>>>>>>>>>> comment says >>>>>>>>>>> "involving a template" (i.e., not one of the first >>>>>>>>>>> declaration of >>>>>>>>>>> a template). The test case that corresponds to this test is: >>>>>>>>>>> >>>>>>>>>>> template <class> struct S7 { }; >>>>>>>>>>> struct S7<void> s7v; // { dg-warning >>>>>>>>>>> "\\\[-Wredundant-tags" } >>>>>>>>>>> >>>>>>>>>>> where DECL is the TEPLATE_DECL of S7<void>. >>>>>>>>>>> >>>>>>>>>>> As I mentioned, more work is still needed to handle templates >>>>>>>>>>> right >>>>>>>>>>> because some redundant tags are still not diagnosed. For >>>>>>>>>>> example: >>>>>>>>>>> >>>>>>>>>>> template <class> struct S7 { }; >>>>>>>>>>> template <class T> >>>>>>>>>>> using U = struct S7<T>; // missing warning >>>>>>>>>> >>>>>>>>>> When we get here for an instance of a template, it doesn't >>>>>>>>>> make sense to treat it as a new type. >>>>>>>>>> >>>>>>>>>> If decl is a template and type_decl is an instance of that >>>>>>>>>> template, do we want to (before the lookup) change type_decl >>>>>>>>>> to the template or the corresponding generic TYPE_DECL, which >>>>>>>>>> should already be in the table? >>>>>>>>> >>>>>>>>> I'm struggling with how to do this. Given type (a RECORD_TYPE) >>>>>>>>> and >>>>>>>>> type_decl (a TEMPLATE_DECL) representing the use of a template, >>>>>>>>> how >>>>>>>>> do I get the corresponding template (or its explicit or partial >>>>>>>>> specialization) in the three cases below? >>>>>>>>> >>>>>>>>> 1) Instance of the primary: >>>>>>>>> template <class> class A; >>>>>>>>> struct A<int> a; >>>>>>>>> >>>>>>>>> 2) Instance of an explicit specialization: >>>>>>>>> template <class> class B; >>>>>>>>> template <> struct B<int>; >>>>>>>>> class B<int> b; >>>>>>>>> >>>>>>>>> 3) Instance of a partial specialization: >>>>>>>>> template <class> class C; >>>>>>>>> template <class T> struct C<T*>; >>>>>>>>> class C<int*> c; >>>>>>>>> >>>>>>>>> By trial and (lots of) error I figured out that in both (1) and >>>>>>>>> (2), >>>>>>>>> but not in (3), TYPE_MAIN_DECL (TYPE_TI_TEMPLATE (type)) returns >>>>>>>>> the template's type_decl. >>>>>>>>> >>>>>>>>> Is there some function to call to get it in (3), or even better, >>>>>>>>> in all three cases? >>>>>>>> >>>>>>>> I think you're looking for most_general_template. >>>>>>> >>>>>>> I don't think that's quite what I'm looking for. At least it >>>>>>> doesn't >>>>>>> return the template or its specialization in all three cases above. >>>>>> >>>>>> Ah, true, that function stops at specializations. Oddly, I don't >>>>>> think there's currently a similar function that looks through >>>>>> them. You could create one that does a simple loop through >>>>>> DECL_TI_TEMPLATE like is_specialization_of. >>>>> >>>>> Thanks for the tip. Even with that I'm having trouble with partial >>>>> specializations. For example in: >>>>> >>>>> template <class> struct S; >>>>> template <class T> class S<const T>; >>>>> extern class S<const int> s1; >>>>> extern struct S<const int> s2; // expect -Wmismatched-tags >>>>> >>>>> how do I find the declaration of the partial specialization when given >>>>> the type in the extern declaration? A loop in my find_template_for() >>>>> function (similar to is_specialization_of) only visits the implicit >>>>> specialization S<const int> (i.e., its own type) and the primary. >>>> >>>> Is that a problem? The name is from the primary template, so does >>>> it matter for this warning whether there's an explicit >>>> specialization involved? >>> >>> I don't understand the question. S<const int> is an instance of >>> the partial specialization. To diagnose the right mismatch the warning >>> needs to know how to find the template (i.e., either the primary, or >>> the explicit or partial specialization) the instance corresponds to and >>> the class-key it was declared with. As it is, while GCC does diagnose >>> the right declaration (that of s2), it does that thanks to a bug: >>> because it finds and uses the type and class-key used to declare s1. >>> If we get rid of s1 it doesn't diagnose anything. >>> >>> I tried using DECL_TEMPLATE_SPECIALIZATIONS() to get the list of >>> the partial specializations but it doesn't like any of the arguments >>> I've given it (it ICEs). >> >> With this fixed, here's the algorithm I tried: >> >> 1) for a type T of a template instantiation (s1 above), get the primary >> P that T was instantiated from using >> P = TYPE_MAIN_DECL (CLASSTYPE_PRIMARY_TEMPLATE_TYPE (T)), >> 2) from P, get the chain of its specializations using >> SC = DECL_TEMPLATE_SPECIALIZATIONS (P) >> 3) for each (partial) specialization S on the SC chain get the chain >> of its instantiations IC using DECL_TEMPLATE_INSTANTIATIONS, if >> is_specialization_of (T, TREE_VALUE (IC)) is non-zero take >> TREE_VALUE (SC) as the declaration of the partial specialization >> that the template instanstantiaton T was generated from. >> >> Unfortunately, in the example above, DECL_TEMPLATE_INSTANTIATIONS for >> the partial specialization 'class S<const T>' is null (even after all >> the declarations have been parsed) so I'm at a dead end. > > After a lot more trial and error I discovered > most_specialized_partial_spec in pt.c with whose help I have been able > to get templates to work the way I think they should (at least the cases > I've tested do). > > Besides fixing the original problem that motivated it, the attached > patch also corrects how template specializations are handled: the first > declaration of either a primary template or its specialization (either > explicit or partial) determines the class-key in subsequent uses of > the type or its instantiations. To do this for uses of first-time > template instantiations such as in the declaration of s1 in the test > case above, class_decl_loc_t::diag_mismatched_tags looks up the template > (either the primary or the partial specialization) in the CLASS2LOC map > and uses it and its class-key as the guide when issuing diagnostics. > This also means that the first instance of every template needs to > have a record in the CLASS2LOC map (it also needs it to compare its > class-key to subsequent redeclarations of the template). > > This has been unexpectedly difficult. A big part of it is that I've > never before worked with templates in the front-end so I had to learn > how they're organized (I'm far from having mastered it). What's made > the learning curve especially steep, besides the sparse documentation, > is the problems hinted at in the paragraph below below. This whole > area could really stand to be documented in some sort of a writeup: > a high-level overview of how templates are put together (i.e., what > hangs off what in the tree representation) and what APIs to use to > work with them. > > The revised patch has been tested on x86_64-linux. > > Martin > > >> The other recurring problem I'm running into is that many of the C++ >> FE macros (and APIs) don't always return the expected/documented result. >> I think this is at least in part because until a declaration has been >> fully parsed not all the bits are in place to make it possible to tell >> if it's an implicit or explicit specialization, for example (so >> CLASSTYPE_USE_TEMPLATE (T) is 1 for the first-time declaration of >> an explicit specialization, for example). But in view of the problem >> above I'm not sure that's the only reason. >> >>> >>> Martin >>> >>> PS As an aside, both Clang and VC++ have trouble with templates as >>> well, just slightly different kinds of trouble. Clang diagnoses >>> the declaration of the partial specialization while VC++ diagnoses >>> s1. In other similar cases like the one below VC++ does the right >>> thing and Clang is silent. >>> >>> template <class> struct S { }; >>> template <class T> class S<const T> { }; >>> >>> template <class T> void f (class S<T>); // VC++ warns >>> template <class T> void g (struct S<const T>); // GCC & VC++ warn >>> >>>> >>>>> Martin >>>>> >>>>>> >>>>>>> In (2) and (3) it won't distinguish between specializations of B or >>>>>>> C on different types. In (2), the function returns the same result >>>>>>> for both: >>>>>>> >>>>>>> template <> struct B<int>; >>>>>>> template <> struct B<char>; >>>>>>> >>>>>>> In (3), it similarly returns the same result for both of >>>>>>> >>>>>>> template <class T> struct C<T*>; >>>>>>> template <class T> struct C<const T>; >>>>>>> >>>>>>> even though they are declarations of distinct types. >>>>>> >>>>>> >>>>>> Jason >>>>>> >>>>> >>>> >>> >> > > + FIXME: Relying on cp_parser_declares_only_class_p to diffeerentiate "differentiate" > + declarations of a class from its uses doesn't work for type aliases > + (as in using T = class C;). */ Good point. Perhaps we could pass flags to cp_parser_declares_only_class_p and have it return false if CP_PARSER_FLAGS_TYPENAME_OPTIONAL, since that is set for an alias but not for a normal type-specifier. > + DECL corresponsds. IS_USE should be set when DECL refers to a class "corresponds" > + for (tree t = decl_type; > + t != NULL_TREE; > + t = CLASSTYPE_USE_TEMPLATE (t) > + ? TREE_TYPE (CLASSTYPE_TI_TEMPLATE (t)) : NULL_TREE > + ) > + { > + if (same_type_ignoring_top_level_qualifiers_p (t, decl_type)) Looks like on the first iteration, t == decl_type, so this will always be true, and this loop has no effect, right? > + if (tree spec = most_specialized_partial_spec (ret, tsubst_flags_t ())) tf_none instead of tsubst_flags_t (). > + if (!decl_p && !def_p && TREE_CODE (decl) == TEMPLATE_DECL) > { > + /* When TYPE is the use of an implicit specialization of a previously > + declared template set TYPE_DECL to the type of the primary template > + for the specialization and look it up in CLASS2LOC below. For uses > + of explicit or partial specializations TYPE_DECL already points to > + the declaration of the specialization. */ > + type_decl = specialization_of (type_decl); Here shouldn't is_use be true? > + /* Save the current function before changing it below. */ > + tree save_func = current_function_decl; Let's change this (and the restoration at the bottom of the function) to a temp_override sentinel. Jason
On 3/18/20 9:07 PM, Jason Merrill wrote: > On 3/12/20 6:38 PM, Martin Sebor wrote: ... >> After a lot more trial and error I discovered >> most_specialized_partial_spec in pt.c with whose help I have been able >> to get templates to work the way I think they should (at least the cases >> I've tested do). >> >> Besides fixing the original problem that motivated it, the attached >> patch also corrects how template specializations are handled: the first >> declaration of either a primary template or its specialization (either >> explicit or partial) determines the class-key in subsequent uses of >> the type or its instantiations. To do this for uses of first-time >> template instantiations such as in the declaration of s1 in the test >> case above, class_decl_loc_t::diag_mismatched_tags looks up the template >> (either the primary or the partial specialization) in the CLASS2LOC map >> and uses it and its class-key as the guide when issuing diagnostics. >> This also means that the first instance of every template needs to >> have a record in the CLASS2LOC map (it also needs it to compare its >> class-key to subsequent redeclarations of the template). >> >> This has been unexpectedly difficult. A big part of it is that I've >> never before worked with templates in the front-end so I had to learn >> how they're organized (I'm far from having mastered it). What's made >> the learning curve especially steep, besides the sparse documentation, >> is the problems hinted at in the paragraph below below. This whole >> area could really stand to be documented in some sort of a writeup: >> a high-level overview of how templates are put together (i.e., what >> hangs off what in the tree representation) and what APIs to use to >> work with them. >> >> The revised patch has been tested on x86_64-linux. >> ... > >> + FIXME: Relying on cp_parser_declares_only_class_p to diffeerentiate > > "differentiate" > >> + declarations of a class from its uses doesn't work for type aliases >> + (as in using T = class C;). */ > > Good point. Perhaps we could pass flags to > cp_parser_declares_only_class_p and have it return false if > CP_PARSER_FLAGS_TYPENAME_OPTIONAL, since that is set for an alias but > not for a normal type-specifier. I wondered if there was a way to identify that we're dealing with an alias. CP_PARSER_FLAGS_TYPENAME_OPTIONAL is set not just for those but also for template declarations (in cp_parser_single_declaration) but I was able to make it work by tweaking cp_parser_type_specifier. It doesn't feel very clean (it seems like either the bit or all of cp_parser_flags could be a member of the parser class or some subobject of it) but it does the job. Thanks for pointing me in the right direction! > >> + DECL corresponsds. IS_USE should be set when DECL refers to a class > > "corresponds" > >> + for (tree t = decl_type; >> + t != NULL_TREE; >> + t = CLASSTYPE_USE_TEMPLATE (t) >> + ? TREE_TYPE (CLASSTYPE_TI_TEMPLATE (t)) : NULL_TREE >> + ) >> + { >> + if (same_type_ignoring_top_level_qualifiers_p (t, decl_type)) > > Looks like on the first iteration, t == decl_type, so this will always > be true, and this loop has no effect, right? Right. > >> + if (tree spec = most_specialized_partial_spec (ret, >> tsubst_flags_t ())) > > tf_none instead of tsubst_flags_t (). > >> + if (!decl_p && !def_p && TREE_CODE (decl) == TEMPLATE_DECL) >> { >> + /* When TYPE is the use of an implicit specialization of a >> previously >> + declared template set TYPE_DECL to the type of the primary template >> + for the specialization and look it up in CLASS2LOC below. For uses >> + of explicit or partial specializations TYPE_DECL already points to >> + the declaration of the specialization. */ >> + type_decl = specialization_of (type_decl); > > Here shouldn't is_use be true? If it were set to true here we would find the partial specialization corresponding to its specialization in the use when what we want is the latter. As a result, for the following: template <class> struct S; template <class T> struct S<T*>; extern class S<int*> s1; // expect -Wmismatched-tags extern struct S<int*> s2; we'd end up with a warning for s2 pointing to the instantiation of s1 as the "guiding declaration:" z.C:5:15: warning: ‘template<class T> struct S<T*>’ declared with a mismatched class-key ‘struct’ [-Wmismatched-tags] 5 | extern struct S<int*> s2; | ^~~~~~~ z.C:5:15: note: remove the class-key or replace it with ‘class’ z.C:4:15: note: ‘template<class T> struct S<T*>’ first declared as ‘class’ here 4 | extern class S<int*> s1; // expect -Wmismatched-tags | ^~~~~~~ By setting it to false here we record the type of the instantiation instead along with the class-key so that we can diagnose the mismatch between the partial and its use. > >> + /* Save the current function before changing it below. */ >> + tree save_func = current_function_decl; > > Let's change this (and the restoration at the bottom of the function) to > a temp_override sentinel. Attached is a revision with the updates above, rested on x86_64. To check the code doesn't ICE on non-trivial use cases I also built stage 1 with both warnings enabled. It found no ICEs but it sure got a good workout. Here's a breakdown of the two warnings (total count, unique instances, and files they appear in): -Wredundant-tags 727969 21130 839 -Wmismatched-tags 2089 536 73 I thought I cleaned up most of the -Wmismatched-tags warnings back in July so it looks like a lot of them must have crept back in (I don't think the warning got that much better at finding them in non-template code). Martin
On 3/19/20 7:55 PM, Martin Sebor wrote: > On 3/18/20 9:07 PM, Jason Merrill wrote: >> On 3/12/20 6:38 PM, Martin Sebor wrote: > ... >>> + declarations of a class from its uses doesn't work for type >>> aliases >>> + (as in using T = class C;). */ >> >> Good point. Perhaps we could pass flags to >> cp_parser_declares_only_class_p and have it return false if >> CP_PARSER_FLAGS_TYPENAME_OPTIONAL, since that is set for an alias but >> not for a normal type-specifier. > > I wondered if there was a way to identify that we're dealing with > an alias. CP_PARSER_FLAGS_TYPENAME_OPTIONAL is set not just for > those but also for template declarations (in > cp_parser_single_declaration) but I was able to make it work by > tweaking cp_parser_type_specifier. It doesn't feel very clean > (it seems like either the bit or all of cp_parser_flags could be > a member of the parser class or some subobject of it) but it does > the job. Thanks for pointing me in the right direction! Hmm, true, relying on that flag is probably too fragile. And now that I look closer, I see that we already have is_declaration in cp_parser_elaborated_type_specifier, we just need to check that before cp_parser_declares_only_class_p like we do earlier in the function. >>> + if (!decl_p && !def_p && TREE_CODE (decl) == TEMPLATE_DECL) >>> { >>> + /* When TYPE is the use of an implicit specialization of a >>> previously >>> + declared template set TYPE_DECL to the type of the primary >>> template >>> + for the specialization and look it up in CLASS2LOC below. For >>> uses >>> + of explicit or partial specializations TYPE_DECL already points to >>> + the declaration of the specialization. */ >>> + type_decl = specialization_of (type_decl); >> >> Here shouldn't is_use be true? > > If it were set to true here we would find the partial specialization > corresponding to its specialization in the use when what we want is > the latter. As a result, for the following: > > template <class> struct S; > template <class T> struct S<T*>; > > extern class S<int*> s1; // expect -Wmismatched-tags > extern struct S<int*> s2; > > we'd end up with a warning for s2 pointing to the instantiation of > s1 as the "guiding declaration:" > > z.C:5:15: warning: ‘template<class T> struct S<T*>’ declared with a > mismatched class-key ‘struct’ [-Wmismatched-tags] > 5 | extern struct S<int*> s2; > | ^~~~~~~ > z.C:5:15: note: remove the class-key or replace it with ‘class’ > z.C:4:15: note: ‘template<class T> struct S<T*>’ first declared as > ‘class’ here > 4 | extern class S<int*> s1; // expect -Wmismatched-tags > | ^~~~~~~ I found this puzzling and wanted to see why that would be, but I can't reproduce it; compiling with -Wmismatched-tags produces only wa2.C:4:17: warning: ‘S<T*>’ declared with a mismatched class-key ‘class’ [-Wmismatched-tags] 4 | extern class S<int*> s1; // expect -Wmismatched-tags | ^~~~~~~ wa2.C:4:17: note: remove the class-key or replace it with ‘struct’ wa2.C:2:29: note: ‘S<T*>’ first declared as ‘struct’ here 2 | template <class T> struct S<T*>; So the only difference is whether we talk about S<T*> or S<int*>. I agree that the latter is probably better, which is what you get without my suggested change. But since specialization_of does nothing if is_use is false, how about removing the call here and removing the is_use parameter? > + if (tree spec = most_specialized_partial_spec (ret, tf_none)) > + if (spec != error_mark_node) > + ret = TREE_VALUE (spec); I think you want to take the TREE_TYPE of the template here, so you don't need to do it here: > + tree pt = specialization_of (TYPE_MAIN_DECL (type), true); > + if (TREE_CODE (pt) == TEMPLATE_DECL) > + pt = TREE_TYPE (pt); > + pt = TYPE_MAIN_DECL (pt); And also, since it takes a TYPE_DECL, it would be better to return another TYPE_DECL rather than a _TYPE, especially since the only caller immediately extracts a TYPE_DECL. Jason
On 3/20/20 3:53 PM, Jason Merrill wrote: > On 3/19/20 7:55 PM, Martin Sebor wrote: >> On 3/18/20 9:07 PM, Jason Merrill wrote: >>> On 3/12/20 6:38 PM, Martin Sebor wrote: >> ... >>>> + declarations of a class from its uses doesn't work for type >>>> aliases >>>> + (as in using T = class C;). */ >>> >>> Good point. Perhaps we could pass flags to >>> cp_parser_declares_only_class_p and have it return false if >>> CP_PARSER_FLAGS_TYPENAME_OPTIONAL, since that is set for an alias but >>> not for a normal type-specifier. >> >> I wondered if there was a way to identify that we're dealing with >> an alias. CP_PARSER_FLAGS_TYPENAME_OPTIONAL is set not just for >> those but also for template declarations (in >> cp_parser_single_declaration) but I was able to make it work by >> tweaking cp_parser_type_specifier. It doesn't feel very clean >> (it seems like either the bit or all of cp_parser_flags could be >> a member of the parser class or some subobject of it) but it does >> the job. Thanks for pointing me in the right direction! > > Hmm, true, relying on that flag is probably too fragile. And now that I > look closer, I see that we already have is_declaration in > cp_parser_elaborated_type_specifier, we just need to check that before > cp_parser_declares_only_class_p like we do earlier in the function. I changed it to use is_declaration instead. >>>> + if (!decl_p && !def_p && TREE_CODE (decl) == TEMPLATE_DECL) >>>> { >>>> + /* When TYPE is the use of an implicit specialization of a >>>> previously >>>> + declared template set TYPE_DECL to the type of the primary >>>> template >>>> + for the specialization and look it up in CLASS2LOC below. For >>>> uses >>>> + of explicit or partial specializations TYPE_DECL already >>>> points to >>>> + the declaration of the specialization. */ >>>> + type_decl = specialization_of (type_decl); >>> >>> Here shouldn't is_use be true? >> >> If it were set to true here we would find the partial specialization >> corresponding to its specialization in the use when what we want is >> the latter. As a result, for the following: >> >> template <class> struct S; >> template <class T> struct S<T*>; >> >> extern class S<int*> s1; // expect -Wmismatched-tags >> extern struct S<int*> s2; >> >> we'd end up with a warning for s2 pointing to the instantiation of >> s1 as the "guiding declaration:" >> >> z.C:5:15: warning: ‘template<class T> struct S<T*>’ declared with a >> mismatched class-key ‘struct’ [-Wmismatched-tags] >> 5 | extern struct S<int*> s2; >> | ^~~~~~~ >> z.C:5:15: note: remove the class-key or replace it with ‘class’ >> z.C:4:15: note: ‘template<class T> struct S<T*>’ first declared as >> ‘class’ here >> 4 | extern class S<int*> s1; // expect -Wmismatched-tags >> | ^~~~~~~ > > I found this puzzling and wanted to see why that would be, but I can't > reproduce it; compiling with -Wmismatched-tags produces only I'm not sure what you did differently. With the patch (the last one or the one in the attachment) we get the expected warning below. > > wa2.C:4:17: warning: ‘S<T*>’ declared with a mismatched class-key > ‘class’ [-Wmismatched-tags] > 4 | extern class S<int*> s1; // expect -Wmismatched-tags > | ^~~~~~~ > wa2.C:4:17: note: remove the class-key or replace it with ‘struct’ > wa2.C:2:29: note: ‘S<T*>’ first declared as ‘struct’ here > 2 | template <class T> struct S<T*>; > > So the only difference is whether we talk about S<T*> or S<int*>. I > agree that the latter is probably better, which is what you get without > my suggested change. But since specialization_of does nothing if is_use > is false, how about removing the call here and removing the is_use > parameter? Sure. > >> + if (tree spec = most_specialized_partial_spec (ret, tf_none)) >> + if (spec != error_mark_node) >> + ret = TREE_VALUE (spec); > > I think you want to take the TREE_TYPE of the template here, so you > don't need to do it here: > >> + tree pt = specialization_of (TYPE_MAIN_DECL (type), true); >> + if (TREE_CODE (pt) == TEMPLATE_DECL) >> + pt = TREE_TYPE (pt); >> + pt = TYPE_MAIN_DECL (pt); > > And also, since it takes a TYPE_DECL, it would be better to return > another TYPE_DECL rather than a _TYPE, especially since the only caller > immediately extracts a TYPE_DECL. Okay. Attached is an revised patch with these changes. Martin
On 3/21/20 5:59 PM, Martin Sebor wrote: > + /* Diagnose class/struct/union mismatches. IS_DECLARATION is false > + for alias definition. */ > + bool decl_class = (is_declaration > + && cp_parser_declares_only_class_p (parser)); > cp_parser_check_class_key (parser, key_loc, tag_type, type, false, > cp_parser_declares_only_class_p (parser)); Don't you need to use the new variable? Don't your testcases exercise this? > + /* When TYPE is the use of an implicit specialization of a previously > + declared template set TYPE_DECL to the type of the primary template > + for the specialization and look it up in CLASS2LOC below. For uses > + of explicit or partial specializations TYPE_DECL already points to > + the declaration of the specialization. > + IS_USE is clear so that the type of an implicit instantiation rather > + than that of a partial specialization is determined. */ > + type_decl = TREE_TYPE (type_decl); > + if (TREE_CODE (type_decl) != TEMPLATE_DECL) > + type_decl = TYPE_MAIN_DECL (type_decl); The comment is no longer relevant to the code. The remaining code also seems like it would have no effect; we already know type_decl is TYPE_MAIN_DECL (type). Jason
On 3/23/20 8:49 AM, Jason Merrill wrote: > On 3/21/20 5:59 PM, Martin Sebor wrote: >> + /* Diagnose class/struct/union mismatches. IS_DECLARATION is >> false >> + for alias definition. */ >> + bool decl_class = (is_declaration >> + && cp_parser_declares_only_class_p (parser)); >> cp_parser_check_class_key (parser, key_loc, tag_type, type, >> false, >> cp_parser_declares_only_class_p (parser)); > > Don't you need to use the new variable? > > Don't your testcases exercise this? Of course they do. This was a leftover from an experiment after I put the initial updated patch together. On final review I decided to adjust some comments and forgot to restore the original use of the variable. >> + /* When TYPE is the use of an implicit specialization of a >> previously >> + declared template set TYPE_DECL to the type of the primary template >> + for the specialization and look it up in CLASS2LOC below. For uses >> + of explicit or partial specializations TYPE_DECL already points to >> + the declaration of the specialization. >> + IS_USE is clear so that the type of an implicit instantiation >> rather >> + than that of a partial specialization is determined. */ >> + type_decl = TREE_TYPE (type_decl); >> + if (TREE_CODE (type_decl) != TEMPLATE_DECL) >> + type_decl = TYPE_MAIN_DECL (type_decl); > > The comment is no longer relevant to the code. The remaining code also > seems like it would have no effect; we already know type_decl is > TYPE_MAIN_DECL (type). I removed the block of code. Martin PS I would have preferred to resolve just the reported problem in this patch and deal with the template specializations more fully (and with aliases) in a followup. As it is, it has grown bigger and more complex than I'm comfortable with, especially with the template specializations, harder for me to follow, and obviously a lot more time-consuming not just to put together but also to review. Although this revision handles many more template specialization cases correctly, there still are other (arguably corner) cases that it doesn't. I suspect getting those right might even require a design change, which I see as out of scope at this time (not to mention my ability).
Ping: Jason, is the latest patch acceptable or are there any other changes you want me to make? https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542538.html On 3/21/20 3:59 PM, Martin Sebor wrote: > On 3/20/20 3:53 PM, Jason Merrill wrote: >> On 3/19/20 7:55 PM, Martin Sebor wrote: >>> On 3/18/20 9:07 PM, Jason Merrill wrote: >>>> On 3/12/20 6:38 PM, Martin Sebor wrote: >>> ... >>>>> + declarations of a class from its uses doesn't work for type >>>>> aliases >>>>> + (as in using T = class C;). */ >>>> >>>> Good point. Perhaps we could pass flags to >>>> cp_parser_declares_only_class_p and have it return false if >>>> CP_PARSER_FLAGS_TYPENAME_OPTIONAL, since that is set for an alias >>>> but not for a normal type-specifier. >>> >>> I wondered if there was a way to identify that we're dealing with >>> an alias. CP_PARSER_FLAGS_TYPENAME_OPTIONAL is set not just for >>> those but also for template declarations (in >>> cp_parser_single_declaration) but I was able to make it work by >>> tweaking cp_parser_type_specifier. It doesn't feel very clean >>> (it seems like either the bit or all of cp_parser_flags could be >>> a member of the parser class or some subobject of it) but it does >>> the job. Thanks for pointing me in the right direction! >> >> Hmm, true, relying on that flag is probably too fragile. And now that >> I look closer, I see that we already have is_declaration in >> cp_parser_elaborated_type_specifier, we just need to check that before >> cp_parser_declares_only_class_p like we do earlier in the function. > > I changed it to use is_declaration instead. > >>>>> + if (!decl_p && !def_p && TREE_CODE (decl) == TEMPLATE_DECL) >>>>> { >>>>> + /* When TYPE is the use of an implicit specialization of a >>>>> previously >>>>> + declared template set TYPE_DECL to the type of the primary >>>>> template >>>>> + for the specialization and look it up in CLASS2LOC below. >>>>> For uses >>>>> + of explicit or partial specializations TYPE_DECL already >>>>> points to >>>>> + the declaration of the specialization. */ >>>>> + type_decl = specialization_of (type_decl); >>>> >>>> Here shouldn't is_use be true? >>> >>> If it were set to true here we would find the partial specialization >>> corresponding to its specialization in the use when what we want is >>> the latter. As a result, for the following: >>> >>> template <class> struct S; >>> template <class T> struct S<T*>; >>> >>> extern class S<int*> s1; // expect -Wmismatched-tags >>> extern struct S<int*> s2; >>> >>> we'd end up with a warning for s2 pointing to the instantiation of >>> s1 as the "guiding declaration:" >>> >>> z.C:5:15: warning: ‘template<class T> struct S<T*>’ declared with a >>> mismatched class-key ‘struct’ [-Wmismatched-tags] >>> 5 | extern struct S<int*> s2; >>> | ^~~~~~~ >>> z.C:5:15: note: remove the class-key or replace it with ‘class’ >>> z.C:4:15: note: ‘template<class T> struct S<T*>’ first declared as >>> ‘class’ here >>> 4 | extern class S<int*> s1; // expect -Wmismatched-tags >>> | ^~~~~~~ >> >> I found this puzzling and wanted to see why that would be, but I can't >> reproduce it; compiling with -Wmismatched-tags produces only > > I'm not sure what you did differently. With the patch (the last one > or the one in the attachment) we get the expected warning below. > >> >> wa2.C:4:17: warning: ‘S<T*>’ declared with a mismatched class-key >> ‘class’ [-Wmismatched-tags] >> 4 | extern class S<int*> s1; // expect -Wmismatched-tags >> | ^~~~~~~ >> wa2.C:4:17: note: remove the class-key or replace it with ‘struct’ >> wa2.C:2:29: note: ‘S<T*>’ first declared as ‘struct’ here >> 2 | template <class T> struct S<T*>; >> >> So the only difference is whether we talk about S<T*> or S<int*>. I >> agree that the latter is probably better, which is what you get >> without my suggested change. But since specialization_of does nothing >> if is_use is false, how about removing the call here and removing the >> is_use parameter? > > Sure. > >> >>> + if (tree spec = most_specialized_partial_spec (ret, tf_none)) >>> + if (spec != error_mark_node) >>> + ret = TREE_VALUE (spec); >> >> I think you want to take the TREE_TYPE of the template here, so you >> don't need to do it here: >> >>> + tree pt = specialization_of (TYPE_MAIN_DECL (type), true); >>> + if (TREE_CODE (pt) == TEMPLATE_DECL) >>> + pt = TREE_TYPE (pt); >>> + pt = TYPE_MAIN_DECL (pt); >> >> And also, since it takes a TYPE_DECL, it would be better to return >> another TYPE_DECL rather than a _TYPE, especially since the only >> caller immediately extracts a TYPE_DECL. > > Okay. Attached is an revised patch with these changes. > > Martin
On 3/23/20 12:50 PM, Martin Sebor wrote: > On 3/23/20 8:49 AM, Jason Merrill wrote: >> On 3/21/20 5:59 PM, Martin Sebor wrote: >>> + /* Diagnose class/struct/union mismatches. IS_DECLARATION is >>> false >>> + for alias definition. */ >>> + bool decl_class = (is_declaration >>> + && cp_parser_declares_only_class_p (parser)); >>> cp_parser_check_class_key (parser, key_loc, tag_type, type, >>> false, >>> cp_parser_declares_only_class_p (parser)); >> >> Don't you need to use the new variable? >> >> Don't your testcases exercise this? > > Of course they do. This was a leftover from an experiment after I put > the initial updated patch together. On final review I decided to adjust > some comments and forgot to restore the original use of the variable. > >>> + /* When TYPE is the use of an implicit specialization of a >>> previously >>> + declared template set TYPE_DECL to the type of the primary >>> template >>> + for the specialization and look it up in CLASS2LOC below. For >>> uses >>> + of explicit or partial specializations TYPE_DECL already points to >>> + the declaration of the specialization. >>> + IS_USE is clear so that the type of an implicit instantiation >>> rather >>> + than that of a partial specialization is determined. */ >>> + type_decl = TREE_TYPE (type_decl); >>> + if (TREE_CODE (type_decl) != TEMPLATE_DECL) >>> + type_decl = TYPE_MAIN_DECL (type_decl); >> >> The comment is no longer relevant to the code. The remaining code >> also seems like it would have no effect; we already know type_decl is >> TYPE_MAIN_DECL (type). > > I removed the block of code. > > Martin > > PS I would have preferred to resolve just the reported problem in this > patch and deal with the template specializations more fully (and with > aliases) in a followup. As it is, it has grown bigger and more complex > than I'm comfortable with, especially with the template specializations, > harder for me to follow, and obviously a lot more time-consuming not > just to put together but also to review. Although this revision handles > many more template specialization cases correctly, there still are other > (arguably corner) cases that it doesn't. I suspect getting those right > might even require a design change, which I see as out of scope at this > time (not to mention my ability). Sure, at this point in the cycle there's always a tradeoff between better functionality and risk from ballooning changes. It looks like the improved template handling could still be split out into a separate patch, if you'd prefer. > + /* Number of usesn of the class. */ Typo. > + definintion if one exists or the first declaration otherwise. */ typo. > + if (CLASSTYPE_USE_TEMPLATE (type) == 1 && !is_decl (0)) ... > + the first reference to the instantiation. The primary must > + be (and inevitably is) at index zero. */ I think CLASSTYPE_IMPLICIT_INSTANTIATION is more readable than testing the value 1. What is the !is_decl (0) intended to do? Changing it to an assert inside the 'if' doesn't seem to affect any of the testcases. > + For implicit instantiations of a primary template it's > + the class-key used to declare the primary with. The primary > + must be at index zero. */ > + const tag_types xpect_key > + = cdlguide->class_key (cdlguide == this ? idxguide : 0); A template can also be declared before it's defined; I think you want to move the def_p/idxdef/idxguide logic into another member function that you invoke on cdlguide to perhaps get the class_key_loc_t that you want to use as the pattern. Jason
On 3/25/20 11:36 PM, Jason Merrill wrote: > On 3/23/20 12:50 PM, Martin Sebor wrote: >> On 3/23/20 8:49 AM, Jason Merrill wrote: >>> On 3/21/20 5:59 PM, Martin Sebor wrote: >>>> + /* Diagnose class/struct/union mismatches. IS_DECLARATION is >>>> false >>>> + for alias definition. */ >>>> + bool decl_class = (is_declaration >>>> + && cp_parser_declares_only_class_p (parser)); >>>> cp_parser_check_class_key (parser, key_loc, tag_type, type, >>>> false, >>>> cp_parser_declares_only_class_p (parser)); >>> >>> Don't you need to use the new variable? >>> >>> Don't your testcases exercise this? >> >> Of course they do. This was a leftover from an experiment after I put >> the initial updated patch together. On final review I decided to adjust >> some comments and forgot to restore the original use of the variable. >> >>>> + /* When TYPE is the use of an implicit specialization of a >>>> previously >>>> + declared template set TYPE_DECL to the type of the primary >>>> template >>>> + for the specialization and look it up in CLASS2LOC below. For >>>> uses >>>> + of explicit or partial specializations TYPE_DECL already >>>> points to >>>> + the declaration of the specialization. >>>> + IS_USE is clear so that the type of an implicit instantiation >>>> rather >>>> + than that of a partial specialization is determined. */ >>>> + type_decl = TREE_TYPE (type_decl); >>>> + if (TREE_CODE (type_decl) != TEMPLATE_DECL) >>>> + type_decl = TYPE_MAIN_DECL (type_decl); >>> >>> The comment is no longer relevant to the code. The remaining code >>> also seems like it would have no effect; we already know type_decl is >>> TYPE_MAIN_DECL (type). >> >> I removed the block of code. >> >> Martin >> >> PS I would have preferred to resolve just the reported problem in this >> patch and deal with the template specializations more fully (and with >> aliases) in a followup. As it is, it has grown bigger and more complex >> than I'm comfortable with, especially with the template specializations, >> harder for me to follow, and obviously a lot more time-consuming not >> just to put together but also to review. Although this revision handles >> many more template specialization cases correctly, there still are other >> (arguably corner) cases that it doesn't. I suspect getting those right >> might even require a design change, which I see as out of scope at this >> time (not to mention my ability). > > Sure, at this point in the cycle there's always a tradeoff between > better functionality and risk from ballooning changes. It looks like > the improved template handling could still be split out into a separate > patch, if you'd prefer. I would prefer to get this patch committed as is now. I appreciate there are improvements that can be made to the code (there always are) but, unlike the bugs it fixes, they are invisible to users and so don't seem essential at this point. >> + /* Number of usesn of the class. */ > Typo. > >> + definintion if one exists or the first declaration otherwise. */ > typo. > >> + if (CLASSTYPE_USE_TEMPLATE (type) == 1 && !is_decl (0)) > ... >> + the first reference to the instantiation. The primary must >> + be (and inevitably is) at index zero. */ > > I think CLASSTYPE_IMPLICIT_INSTANTIATION is more readable than testing > the value 1. Okay. > > What is the !is_decl (0) intended to do? Changing it to an assert > inside the 'if' doesn't seem to affect any of the testcases. Looks like the test is an unnecessary remnant and can be removed. In fact, both is_decl() and decl_p member don't appear necessary anymore so I've removed them too. >> + For implicit instantiations of a primary template it's >> + the class-key used to declare the primary with. The primary >> + must be at index zero. */ >> + const tag_types xpect_key >> + = cdlguide->class_key (cdlguide == this ? idxguide : 0); > > A template can also be declared before it's defined; Obviously, just like a class. Is there something you expect me to change in response to this point? > I think you want to > move the def_p/idxdef/idxguide logic into another member function that > you invoke on cdlguide to perhaps get the class_key_loc_t that you want > to use as the pattern. I'm not quite sure what you have in mind here. I agree the cdlcode code looks a little cumbersome and perhaps could be restructured but it's not obvious to me how. Nothing I tried looked like a clear win so unless you consider changing how this is done a prerequisite for accepting the whole patch I'd rather not spend any more time at this stage iterating over refinements of it. Please let me know soon. Attached is a revised patch with the other changes above. Martin
On 3/26/20 2:58 PM, Martin Sebor wrote: > On 3/25/20 11:36 PM, Jason Merrill wrote: >> On 3/23/20 12:50 PM, Martin Sebor wrote: >>> On 3/23/20 8:49 AM, Jason Merrill wrote: >>>> On 3/21/20 5:59 PM, Martin Sebor wrote: >>>>> + /* Diagnose class/struct/union mismatches. IS_DECLARATION >>>>> is false >>>>> + for alias definition. */ >>>>> + bool decl_class = (is_declaration >>>>> + && cp_parser_declares_only_class_p (parser)); >>>>> cp_parser_check_class_key (parser, key_loc, tag_type, type, >>>>> false, >>>>> cp_parser_declares_only_class_p (parser)); >>>> >>>> Don't you need to use the new variable? >>>> >>>> Don't your testcases exercise this? >>> >>> Of course they do. This was a leftover from an experiment after I put >>> the initial updated patch together. On final review I decided to adjust >>> some comments and forgot to restore the original use of the variable. >>> >>>>> + /* When TYPE is the use of an implicit specialization of a >>>>> previously >>>>> + declared template set TYPE_DECL to the type of the primary >>>>> template >>>>> + for the specialization and look it up in CLASS2LOC below. >>>>> For uses >>>>> + of explicit or partial specializations TYPE_DECL already >>>>> points to >>>>> + the declaration of the specialization. >>>>> + IS_USE is clear so that the type of an implicit instantiation >>>>> rather >>>>> + than that of a partial specialization is determined. */ >>>>> + type_decl = TREE_TYPE (type_decl); >>>>> + if (TREE_CODE (type_decl) != TEMPLATE_DECL) >>>>> + type_decl = TYPE_MAIN_DECL (type_decl); >>>> >>>> The comment is no longer relevant to the code. The remaining code >>>> also seems like it would have no effect; we already know type_decl >>>> is TYPE_MAIN_DECL (type). >>> >>> I removed the block of code. >>> >>> Martin >>> >>> PS I would have preferred to resolve just the reported problem in this >>> patch and deal with the template specializations more fully (and with >>> aliases) in a followup. As it is, it has grown bigger and more complex >>> than I'm comfortable with, especially with the template specializations, >>> harder for me to follow, and obviously a lot more time-consuming not >>> just to put together but also to review. Although this revision handles >>> many more template specialization cases correctly, there still are other >>> (arguably corner) cases that it doesn't. I suspect getting those right >>> might even require a design change, which I see as out of scope at this >>> time (not to mention my ability). >> >> Sure, at this point in the cycle there's always a tradeoff between >> better functionality and risk from ballooning changes. It looks like >> the improved template handling could still be split out into a >> separate patch, if you'd prefer. > > I would prefer to get this patch committed as is now. I appreciate > there are improvements that can be made to the code (there always > are) but, unlike the bugs it fixes, they are invisible to users and > so don't seem essential at this point. > >>> + /* Number of usesn of the class. */ >> Typo. >> >>> + definintion if one exists or the first declaration otherwise. */ >> typo. >> >>> + if (CLASSTYPE_USE_TEMPLATE (type) == 1 && !is_decl (0)) >> ... >>> + the first reference to the instantiation. The primary must >>> + be (and inevitably is) at index zero. */ >> >> I think CLASSTYPE_IMPLICIT_INSTANTIATION is more readable than testing >> the value 1. > > Okay. > >> >> What is the !is_decl (0) intended to do? Changing it to an assert >> inside the 'if' doesn't seem to affect any of the testcases. > > Looks like the test is an unnecessary remnant and can be removed. > In fact, both is_decl() and decl_p member don't appear necessary > anymore so I've removed them too. > >>> + For implicit instantiations of a primary template it's >>> + the class-key used to declare the primary with. The primary >>> + must be at index zero. */ >>> + const tag_types xpect_key >>> + = cdlguide->class_key (cdlguide == this ? idxguide : 0); >> >> A template can also be declared before it's defined; > > Obviously, just like a class. Is there something you expect me to > change in response to this point? You're hardcoding index zero for the template case, which seems to assume that the definition of a template is always at index zero. >> I think you want to move the def_p/idxdef/idxguide logic into another >> member function that you invoke on cdlguide to perhaps get the >> class_key_loc_t that you want to use as the pattern. > > I'm not quite sure what you have in mind here. I agree the cdlcode > code looks a little cumbersome and perhaps could be restructured but > it's not obvious to me how. Nothing I tried looked like a clear win > so unless you consider changing how this is done a prerequisite for > accepting the whole patch I'd rather not spend any more time at this > stage iterating over refinements of it. Please let me know soon. I mean that > + const unsigned ndecls = locvec.length (); > + const bool def_p = idxdef < ndecls; > + const unsigned idxguide = def_p ? idxdef : 0; are based on whether the instantiation, rather than the template, is defined. I's probably enough to update ndecls to cdlguide->locvec.length() and change the uses of idxdef to cdlguide->idxdef. And then idxguide will be set properly for cdlguide, so the code farther above can become > + const tag_types xpect_key > + = cdlguide->class_key (idxguide); If you'd prefer, I can make these changes and commit the patch myself. Jason
On 3/26/20 4:16 PM, Jason Merrill wrote: > On 3/26/20 2:58 PM, Martin Sebor wrote: >> On 3/25/20 11:36 PM, Jason Merrill wrote: >>> On 3/23/20 12:50 PM, Martin Sebor wrote: >>>> On 3/23/20 8:49 AM, Jason Merrill wrote: >>>>> On 3/21/20 5:59 PM, Martin Sebor wrote: >>>>>> + /* Diagnose class/struct/union mismatches. IS_DECLARATION >>>>>> is false >>>>>> + for alias definition. */ >>>>>> + bool decl_class = (is_declaration >>>>>> + && cp_parser_declares_only_class_p (parser)); >>>>>> cp_parser_check_class_key (parser, key_loc, tag_type, >>>>>> type, false, >>>>>> cp_parser_declares_only_class_p (parser)); >>>>> >>>>> Don't you need to use the new variable? >>>>> >>>>> Don't your testcases exercise this? >>>> >>>> Of course they do. This was a leftover from an experiment after I put >>>> the initial updated patch together. On final review I decided to >>>> adjust >>>> some comments and forgot to restore the original use of the variable. >>>> >>>>>> + /* When TYPE is the use of an implicit specialization of a >>>>>> previously >>>>>> + declared template set TYPE_DECL to the type of the primary >>>>>> template >>>>>> + for the specialization and look it up in CLASS2LOC below. >>>>>> For uses >>>>>> + of explicit or partial specializations TYPE_DECL already >>>>>> points to >>>>>> + the declaration of the specialization. >>>>>> + IS_USE is clear so that the type of an implicit >>>>>> instantiation rather >>>>>> + than that of a partial specialization is determined. */ >>>>>> + type_decl = TREE_TYPE (type_decl); >>>>>> + if (TREE_CODE (type_decl) != TEMPLATE_DECL) >>>>>> + type_decl = TYPE_MAIN_DECL (type_decl); >>>>> >>>>> The comment is no longer relevant to the code. The remaining code >>>>> also seems like it would have no effect; we already know type_decl >>>>> is TYPE_MAIN_DECL (type). >>>> >>>> I removed the block of code. >>>> >>>> Martin >>>> >>>> PS I would have preferred to resolve just the reported problem in this >>>> patch and deal with the template specializations more fully (and with >>>> aliases) in a followup. As it is, it has grown bigger and more complex >>>> than I'm comfortable with, especially with the template >>>> specializations, >>>> harder for me to follow, and obviously a lot more time-consuming not >>>> just to put together but also to review. Although this revision >>>> handles >>>> many more template specialization cases correctly, there still are >>>> other >>>> (arguably corner) cases that it doesn't. I suspect getting those right >>>> might even require a design change, which I see as out of scope at this >>>> time (not to mention my ability). >>> >>> Sure, at this point in the cycle there's always a tradeoff between >>> better functionality and risk from ballooning changes. It looks like >>> the improved template handling could still be split out into a >>> separate patch, if you'd prefer. >> >> I would prefer to get this patch committed as is now. I appreciate >> there are improvements that can be made to the code (there always >> are) but, unlike the bugs it fixes, they are invisible to users and >> so don't seem essential at this point. >> >>>> + /* Number of usesn of the class. */ >>> Typo. >>> >>>> + definintion if one exists or the first declaration otherwise. */ >>> typo. >>> >>>> + if (CLASSTYPE_USE_TEMPLATE (type) == 1 && !is_decl (0)) >>> ... >>>> + the first reference to the instantiation. The primary must >>>> + be (and inevitably is) at index zero. */ >>> >>> I think CLASSTYPE_IMPLICIT_INSTANTIATION is more readable than >>> testing the value 1. >> >> Okay. >> >>> >>> What is the !is_decl (0) intended to do? Changing it to an assert >>> inside the 'if' doesn't seem to affect any of the testcases. >> >> Looks like the test is an unnecessary remnant and can be removed. >> In fact, both is_decl() and decl_p member don't appear necessary >> anymore so I've removed them too. >> >>>> + For implicit instantiations of a primary template it's >>>> + the class-key used to declare the primary with. The primary >>>> + must be at index zero. */ >>>> + const tag_types xpect_key >>>> + = cdlguide->class_key (cdlguide == this ? idxguide : 0); >>> >>> A template can also be declared before it's defined; >> >> Obviously, just like a class. Is there something you expect me to >> change in response to this point? > > You're hardcoding index zero for the template case, which seems to > assume that the definition of a template is always at index zero. Sounds like you're concerned about something like: template <class> class A; template <class T> class A<T*>; // expect -Wmismatched-tags template <class T> struct A<T*> { }; // ...because of this class A<int*> a; // expect -Wmismatched-tags The definition should be at index zero because once it's seen, entries for prior declarations are purged (after diagnosing mismatches). But I'm sure the tests for these things could stand to beefed up so there could easily be cases that aren't handled correctly. > >>> I think you want to move the def_p/idxdef/idxguide logic into another >>> member function that you invoke on cdlguide to perhaps get the >>> class_key_loc_t that you want to use as the pattern. >> >> I'm not quite sure what you have in mind here. I agree the cdlcode >> code looks a little cumbersome and perhaps could be restructured but >> it's not obvious to me how. Nothing I tried looked like a clear win >> so unless you consider changing how this is done a prerequisite for >> accepting the whole patch I'd rather not spend any more time at this >> stage iterating over refinements of it. Please let me know soon. > > I mean that > >> + const unsigned ndecls = locvec.length (); > + const bool def_p = >> idxdef < ndecls; >> + const unsigned idxguide = def_p ? idxdef : 0; > > are based on whether the instantiation, rather than the template, is > defined. > > I's probably enough to update ndecls to cdlguide->locvec.length() and > change the uses of idxdef to cdlguide->idxdef. And then idxguide will > be set properly for cdlguide, so the code farther above can become > >> + const tag_types xpect_key >> + = cdlguide->class_key (idxguide); > > If you'd prefer, I can make these changes and commit the patch myself. Please go ahead. That will make it a lot quicker. Martin
On 3/26/20 6:51 PM, Martin Sebor wrote: > On 3/26/20 4:16 PM, Jason Merrill wrote: >> On 3/26/20 2:58 PM, Martin Sebor wrote: >>> On 3/25/20 11:36 PM, Jason Merrill wrote: >>>> On 3/23/20 12:50 PM, Martin Sebor wrote: >>>>> On 3/23/20 8:49 AM, Jason Merrill wrote: >>>>>> On 3/21/20 5:59 PM, Martin Sebor wrote: >>>>>>> + /* Diagnose class/struct/union mismatches. IS_DECLARATION >>>>>>> is false >>>>>>> + for alias definition. */ >>>>>>> + bool decl_class = (is_declaration >>>>>>> + && cp_parser_declares_only_class_p (parser)); >>>>>>> cp_parser_check_class_key (parser, key_loc, tag_type, >>>>>>> type, false, >>>>>>> cp_parser_declares_only_class_p (parser)); >>>>>> >>>>>> Don't you need to use the new variable? >>>>>> >>>>>> Don't your testcases exercise this? >>>>> >>>>> Of course they do. This was a leftover from an experiment after I put >>>>> the initial updated patch together. On final review I decided to >>>>> adjust >>>>> some comments and forgot to restore the original use of the variable. >>>>> >>>>>>> + /* When TYPE is the use of an implicit specialization of a >>>>>>> previously >>>>>>> + declared template set TYPE_DECL to the type of the primary >>>>>>> template >>>>>>> + for the specialization and look it up in CLASS2LOC below. >>>>>>> For uses >>>>>>> + of explicit or partial specializations TYPE_DECL already >>>>>>> points to >>>>>>> + the declaration of the specialization. >>>>>>> + IS_USE is clear so that the type of an implicit >>>>>>> instantiation rather >>>>>>> + than that of a partial specialization is determined. */ >>>>>>> + type_decl = TREE_TYPE (type_decl); >>>>>>> + if (TREE_CODE (type_decl) != TEMPLATE_DECL) >>>>>>> + type_decl = TYPE_MAIN_DECL (type_decl); >>>>>> >>>>>> The comment is no longer relevant to the code. The remaining code >>>>>> also seems like it would have no effect; we already know type_decl >>>>>> is TYPE_MAIN_DECL (type). >>>>> >>>>> I removed the block of code. >>>>> >>>>> Martin >>>>> >>>>> PS I would have preferred to resolve just the reported problem in this >>>>> patch and deal with the template specializations more fully (and with >>>>> aliases) in a followup. As it is, it has grown bigger and more >>>>> complex >>>>> than I'm comfortable with, especially with the template >>>>> specializations, >>>>> harder for me to follow, and obviously a lot more time-consuming not >>>>> just to put together but also to review. Although this revision >>>>> handles >>>>> many more template specialization cases correctly, there still are >>>>> other >>>>> (arguably corner) cases that it doesn't. I suspect getting those >>>>> right >>>>> might even require a design change, which I see as out of scope at >>>>> this >>>>> time (not to mention my ability). >>>> >>>> Sure, at this point in the cycle there's always a tradeoff between >>>> better functionality and risk from ballooning changes. It looks >>>> like the improved template handling could still be split out into a >>>> separate patch, if you'd prefer. >>> >>> I would prefer to get this patch committed as is now. I appreciate >>> there are improvements that can be made to the code (there always >>> are) but, unlike the bugs it fixes, they are invisible to users and >>> so don't seem essential at this point. >>> >>>>> + /* Number of usesn of the class. */ >>>> Typo. >>>> >>>>> + definintion if one exists or the first declaration >>>>> otherwise. */ >>>> typo. >>>> >>>>> + if (CLASSTYPE_USE_TEMPLATE (type) == 1 && !is_decl (0)) >>>> ... >>>>> + the first reference to the instantiation. The primary must >>>>> + be (and inevitably is) at index zero. */ >>>> >>>> I think CLASSTYPE_IMPLICIT_INSTANTIATION is more readable than >>>> testing the value 1. >>> >>> Okay. >>> >>>> >>>> What is the !is_decl (0) intended to do? Changing it to an assert >>>> inside the 'if' doesn't seem to affect any of the testcases. >>> >>> Looks like the test is an unnecessary remnant and can be removed. >>> In fact, both is_decl() and decl_p member don't appear necessary >>> anymore so I've removed them too. >>> >>>>> + For implicit instantiations of a primary template it's >>>>> + the class-key used to declare the primary with. The primary >>>>> + must be at index zero. */ >>>>> + const tag_types xpect_key >>>>> + = cdlguide->class_key (cdlguide == this ? idxguide : 0); >>>> >>>> A template can also be declared before it's defined; >>> >>> Obviously, just like a class. Is there something you expect me to >>> change in response to this point? >> >> You're hardcoding index zero for the template case, which seems to >> assume that the definition of a template is always at index zero. > > Sounds like you're concerned about something like: > > template <class> class A; > template <class T> class A<T*>; // expect -Wmismatched-tags > template <class T> struct A<T*> { }; // ...because of this > class A<int*> a; // expect -Wmismatched-tags > > The definition should be at index zero because once it's seen, entries > for prior declarations are purged (after diagnosing mismatches). But > I'm sure the tests for these things could stand to beefed up so there > could easily be cases that aren't handled correctly. > >> >>>> I think you want to move the def_p/idxdef/idxguide logic into >>>> another member function that you invoke on cdlguide to perhaps get >>>> the class_key_loc_t that you want to use as the pattern. >>> >>> I'm not quite sure what you have in mind here. I agree the cdlcode >>> code looks a little cumbersome and perhaps could be restructured but >>> it's not obvious to me how. Nothing I tried looked like a clear win >>> so unless you consider changing how this is done a prerequisite for >>> accepting the whole patch I'd rather not spend any more time at this >>> stage iterating over refinements of it. Please let me know soon. >> >> I mean that >> >>> + const unsigned ndecls = locvec.length (); > + const bool def_p = >>> idxdef < ndecls; >>> + const unsigned idxguide = def_p ? idxdef : 0; >> >> are based on whether the instantiation, rather than the template, is >> defined. >> >> I's probably enough to update ndecls to cdlguide->locvec.length() and >> change the uses of idxdef to cdlguide->idxdef. And then idxguide will >> be set properly for cdlguide, so the code farther above can become >> >>> + const tag_types xpect_key >>> + = cdlguide->class_key (idxguide); >> >> If you'd prefer, I can make these changes and commit the patch myself. > > Please go ahead. That will make it a lot quicker. Done. Here are the changes I made. Jason
PR c++/93824 - bogus -Wredundant-tags on a first declaration in use PR c++/93810 - missing -Wmismatched-tags and -Wredundant-tags on a typedef of an implicit class template specialization gcc/cp/ChangeLog: PR c++/93824 PR c++/93810 * parser.c (cp_parser_check_class_key): Move code... (class_decl_loc_t::add): ...to here. Add parameters. Avoid issuing -Wredundant-tags on first-time declarations in other declarators. (class_decl_loc_t::diag_mismatched_tags): Also expect to be called when -Wredundant-tags is enabled. gcc/testsuite/ChangeLog: PR c++/93824 PR c++/93810 * g++.dg/warn/Wmismatched-tags-3.C: New test. * g++.dg/warn/Wredundant-tags-3.C: Remove xfails. * g++.dg/warn/Wredundant-tags-6.C: New test. diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index ca85d899427..3cf2f2d8b34 100644 --- a/gcc/cp/parser.c +++ b/gcc/cp/parser.c @@ -30924,8 +30924,9 @@ class class_decl_loc_t /* Issues -Wmismatched-tags for all classes. */ static void diag_mismatched_tags (); - /* Adds TYPE_DECL to the collection of class decls. */ - static void add (tree, tag_types, bool, bool); + /* Adds TYPE_DECL to the collection of class decls and diagnoses + redundant tags (if -Wredundant-tags is enabled). */ + static void add (cp_parser *, location_t, tag_types, tree, bool, bool); /* Either adds this decl to the collection of class decls or diagnoses it, whichever is appropriate. */ @@ -31021,6 +31022,19 @@ cp_parser_check_class_key (cp_parser *parser, location_t key_loc, && class_key != union_type) return; + class_decl_loc_t::add (parser, key_loc, class_key, type, def_p, decl_p); +} + +/* Adds TYPE to the collection of class decls and diagnoses redundant + tags (if -Wredundant-tags is enabled). + DEF_P is expected to be set for a definition of class TYPE. DECL_P + is set for a declaration of class TYPE and clear for a reference to + it that is not a declaration of it. */ + +void +class_decl_loc_t::add (cp_parser *parser, location_t key_loc, + tag_types class_key, tree type, bool def_p, bool decl_p) +{ tree type_decl = TYPE_MAIN_DECL (type); tree name = DECL_NAME (type_decl); /* Look up the NAME to see if it unambiguously refers to the TYPE @@ -31032,7 +31046,10 @@ cp_parser_check_class_key (cp_parser *parser, location_t key_loc, /* The class-key is redundant for uses of the CLASS_TYPE that are neither definitions of it nor declarations, and for which name lookup returns just the type itself. */ - bool key_redundant = !def_p && !decl_p && decl == type_decl; + bool key_redundant = (!def_p && !decl_p + && (decl == type_decl + || TREE_CODE (decl) == TEMPLATE_DECL + || TYPE_BEING_DEFINED (type))); if (key_redundant && class_key != class_type @@ -31050,29 +31067,8 @@ cp_parser_check_class_key (cp_parser *parser, location_t key_loc, key_redundant = false; } - if (key_redundant) - { - gcc_rich_location richloc (key_loc); - richloc.add_fixit_remove (key_loc); - warning_at (&richloc, OPT_Wredundant_tags, - "redundant class-key %qs in reference to %q#T", - class_key == union_type ? "union" - : class_key == record_type ? "struct" : "class", - type); - } - - if (seen_as_union || !warn_mismatched_tags) - return; - - class_decl_loc_t::add (type_decl, class_key, key_redundant, def_p); -} - -/* Adds TYPE_DECL to the collection of class decls. */ - -void -class_decl_loc_t::add (tree type_decl, tag_types class_key, bool redundant, - bool def_p) -{ + /* Set if a declaration of TYPE has previously been seen or if it + must exist in a precompiled header. */ bool exist; class_decl_loc_t *rdl = &class2loc.get_or_insert (type_decl, &exist); if (!exist) @@ -31082,30 +31078,51 @@ class_decl_loc_t::add (tree type_decl, tag_types class_key, bool redundant, { /* TYPE_DECL is the first declaration or definition of the type (outside precompiled headers -- see below). Just create - a new entry for it. */ + a new entry for it and return unless it's a declaration + involving a template that may need to be diagnosed by + -Wredundant-tags. */ *rdl = class_decl_loc_t (class_key, false, def_p); - return; + if (TREE_CODE (decl) != TEMPLATE_DECL) + return; + } + else + { + /* TYPE was previously defined in some unknown precompiled hdeader. + Simply add a record of its definition at an unknown location and + proceed below to add a reference to it at the current location. + (Declarations in precompiled headers that are not definitions + are ignored.) */ + tag_types def_key + = CLASSTYPE_DECLARED_CLASS (type) ? class_type : record_type; + location_t def_loc = DECL_SOURCE_LOCATION (type_decl); + *rdl = class_decl_loc_t (def_key, false, true, def_loc); + exist = true; } - - /* TYPE was previously defined in some unknown precompiled hdeader. - Simply add a record of its definition at an unknown location and - proceed below to add a reference to it at the current location. - (Declarations in precompiled headers that are not definitions - are ignored.) */ - tag_types def_key - = CLASSTYPE_DECLARED_CLASS (type) ? class_type : record_type; - location_t def_loc = DECL_SOURCE_LOCATION (type_decl); - *rdl = class_decl_loc_t (def_key, false, true, def_loc); } /* A prior declaration of TYPE_DECL has been seen. */ + if (key_redundant) + { + gcc_rich_location richloc (key_loc); + richloc.add_fixit_remove (key_loc); + warning_at (&richloc, OPT_Wredundant_tags, + "redundant class-key %qs in reference to %q#T", + class_key == union_type ? "union" + : class_key == record_type ? "struct" : "class", + type); + } + + if (!exist) + /* Do nothing if this is the first declaration of the type. */ + return; + if (rdl->idxdef != UINT_MAX && rdl->def_class_key == class_key) /* Do nothing if the class-key in this declaration matches the definition. */ return; - rdl->add_or_diag_mismatched_tag (type_decl, class_key, redundant, def_p); + rdl->add_or_diag_mismatched_tag (type_decl, class_key, key_redundant, def_p); } /* Either adds this DECL corresponding to the TYPE_DECL to the collection @@ -31158,6 +31175,9 @@ class_decl_loc_t::add_or_diag_mismatched_tag (tree type_decl, void class_decl_loc_t::diag_mismatched_tags (tree type_decl) { + if (!warn_mismatched_tags) + return; + unsigned ndecls = locvec.length (); /* Skip a declaration that consistently uses the same class-key @@ -31249,20 +31269,26 @@ class_decl_loc_t::diag_mismatched_tags (tree type_decl) void class_decl_loc_t::diag_mismatched_tags () { - /* CLASS2LOC should be empty if -Wmismatched-tags is disabled. */ - gcc_assert (warn_mismatched_tags || class2loc.is_empty ()); + /* CLASS2LOC should be empty if both -Wmismatched-tags and + -Wredundant-tags are disabled. */ + gcc_assert (warn_mismatched_tags + || warn_redundant_tags + || class2loc.is_empty ()); /* Save the current function before changing it below. It should be null at this point. */ tree save_func = current_function_decl; - /* Iterate over the collected class/struct declarations. */ - typedef class_to_loc_map_t::iterator iter_t; - for (iter_t it = class2loc.begin (); it != class2loc.end (); ++it) + if (warn_mismatched_tags) { - tree type_decl = (*it).first; - class_decl_loc_t &recloc = (*it).second; - recloc.diag_mismatched_tags (type_decl); + /* Iterate over the collected class/struct declarations. */ + typedef class_to_loc_map_t::iterator iter_t; + for (iter_t it = class2loc.begin (); it != class2loc.end (); ++it) + { + tree type_decl = (*it).first; + class_decl_loc_t &recloc = (*it).second; + recloc.diag_mismatched_tags (type_decl); + } } class2loc.empty (); diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-tags-3.C b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-3.C new file mode 100644 index 00000000000..ecbe66d037e --- /dev/null +++ b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-3.C @@ -0,0 +1,14 @@ +/* { dg-do compile } + { dg-options "-Wall -Wmismatched-tags" } */ + +extern class C1 c1; // { dg-message "declared as 'class'" } +extern struct C1 c1; // { dg-warning "\\\[-Wmismatched-tags" } + +void fs1 (struct S1); // { dg-message "declared as 'struct'" } +void fs1 (class S1); // { dg-warning "\\\[-Wmismatched-tags" } + +enum +{ + ec2 = sizeof (struct C2*), // { dg-message "declared as 'struct'" } + fc2 = sizeof (class C2*) // { dg-warning "\\\[-Wmismatched-tags" } +}; diff --git a/gcc/testsuite/g++.dg/warn/Wredundant-tags-3.C b/gcc/testsuite/g++.dg/warn/Wredundant-tags-3.C index 7b30e949d0c..0eeee34dae7 100644 --- a/gcc/testsuite/g++.dg/warn/Wredundant-tags-3.C +++ b/gcc/testsuite/g++.dg/warn/Wredundant-tags-3.C @@ -34,12 +34,12 @@ union N::U u3; // { dg-warning "-Wredundant-tags" } typedef N::TC<0> TC0; typedef typename N::TC<0> TC0; -typedef class N::TC<0> TC0; // { dg-warning "-Wredundant-tags" "pr93809" { xfail *-*-*} .-1 } +typedef class N::TC<0> TC0; // { dg-warning "-Wredundant-tags" } typedef N::TS<0> TS0; typedef typename N::TS<0> TS0; -typedef struct N::TS<0> TS0; // { dg-warning "-Wredundant-tags" "pr93809" { xfail *-*-*} .-1 } +typedef struct N::TS<0> TS0; // { dg-warning "-Wredundant-tags" } typedef N::TS<0> TS0; typedef typename N::TS<0> TS0; -typedef struct N::TS<0> TS0; // { dg-warning "-Wredundant-tags" "pr93809" { xfail *-*-*} .-1 } +typedef struct N::TS<0> TS0; // { dg-warning "-Wredundant-tags" } diff --git a/gcc/testsuite/g++.dg/warn/Wredundant-tags-6.C b/gcc/testsuite/g++.dg/warn/Wredundant-tags-6.C new file mode 100644 index 00000000000..a21cc14b2d8 --- /dev/null +++ b/gcc/testsuite/g++.dg/warn/Wredundant-tags-6.C @@ -0,0 +1,51 @@ +/* PR c++/93824 - bogus -Wredundant-tags on a first declaration in use + { dg-do compile } + { dg-options "-Wredundant-tags" } */ + +extern class C1 &c1; // { dg-bogus "\\\[-Wredundant-tags" } +extern class C1 &c1; // { dg-warning "\\\[-Wredundant-tags" } + +void fc2 (class C2); // { dg-bogus "\\\[-Wredundant-tags" } +void fc2 (class C2); // { dg-warning "\\\[-Wredundant-tags" } + +const int +npc3 = sizeof (class C3*); // { dg-bogus "\\\[-Wredundant-tags" } +const int +nppc3 = sizeof (class C3**); // { dg-warning "\\\[-Wredundant-tags" } + +extern struct S1 *s1p; // { dg-bogus "\\\[-Wredundant-tags" } +extern struct S1 s1a[]; // { dg-warning "\\\[-Wredundant-tags" } + +struct S3 +{ + struct S3 *p1s3; // { dg-warning "\\\[-Wredundant-tags" } + S3 *p2s3; + + union U1 *p1u1; // { dg-bogus "\\\[-Wredundant-tags" } + union U1 *p2u1; // { dg-warning "\\\[-Wredundant-tags" } +} s3; + +typedef struct S3 TS3; // { dg-warning "\\\[-Wredundant-tags" } + +typedef struct S4 TS4; + +struct S5 +{ + struct S6 + { + private: + // 'struct' is redundant in a declaration of a pointer to ::S5; + struct S5 *ps5; // { dg-warning "\\\[-Wredundant-tags" } + // 'struct' is required in a definition of a new type. + struct S5 { } *ps5_2; + struct S5 *p2s5_2; // { dg-warning "\\\[-Wredundant-tags" } + }; +}; + + +template <class> struct S7; +template <class> struct S7 { }; + +template <> struct S7<int>; +template <> struct S7<int> { }; +struct S7<void> s7v; // { dg-warning "\\\[-Wredundant-tags" }