On Wed, 2022-06-15 at 09:33 -0400, Andrew MacLeod wrote: > On 6/13/22 21:24, David Malcolm wrote: > > On Mon, 2022-06-13 at 20:45 -0400, Aldy Hernandez wrote: > > > Final implies we can't further derive from the derived class, > > > right? > > "final" on a vfunc implies that nothing overrides that vfunc, but you > > could still have further derived classes. > > > > You can think of it as "nothing further overrides this vfunc", as > > both > > a hint to the human reader, and an optimization hint to the compiler. > > > > You can always just remove the "final" if you want to override it in > > the future (unless the override is happening in a plugin, I suppose). > > > > > If so > > > we may want just override. > > "override" is indeed probably more useful, in that it documents to > > compilers and human readers that you intend this to override a vfunc. > > > > FWIW I wrote the patch by using both "final" and "override", and then > > dropping the "final" everywhere I needed to to get it to compile. > > > > Dave > > > > > > > Andrew, what are your thoughts? > > > > > > Thanks for doing this. > > OK by me.
Thanks; I've pushed this to trunk as r13-1118-gb06b84dbca5a11, after retesting (bootstrapped & regrtested again on x86_64-pc-linux-gnu). FWIW, as noted in https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595437.html I tried hacking in -Werror=suggest-override to the Makefile, and there were a bunch of places that it suggested could use "override" in gcc/range.op.cc, but I decided not to touch that, because it seems to be under heavy development by you (and also, frankly, out of laziness on my part). So maybe you might want to look at adding those at some point, to avoid snafus where you meant to override something, but got the signature slightly wrong, etc. Dave
