On 7/9/24 9:55 AM, Nathaniel Shead wrote:
On Mon, Jul 08, 2024 at 02:24:14PM -0400, Jason Merrill wrote:
On 7/6/24 10:13 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
I have also been working on a patch that uses the locations of
using-decls in 'diagnose_name_conflict' and 'duplicate_decls' calls, but
that will need a fair bit more work that I'll probaby put off for the
meantime. Otherwise, as far as I can tell there's no circumstance when
modules-imported namespace-scope USING_DECLs have their locations
printed (hence the lack of tests), so I'm happy to defer this patch
until I've made something I can actually test.
An alternative approach here (rather than giving locations to OVERLOADs)
would be to rewrite the modules handling to not using OVERLOADs
internally for non-function usings, that way we can attach the location
to those USING_DECLs. I went this way because I felt having locations
in OVL_USING_P overloads would be useful anyway, but happy to try that
route instead if you're uncomfortable increasing the size of most
OVERLOADs for something largely unused.
That sounds better to me.
OK. Just for some additional context, the diagnostics I was thinking of
were in regards to PR c++/106851; currently the 'conflicts with' for
such declarations just point to an apparently unrelated declaration in a
different namespace, and provides no indication of the using-declaration
that brought it into scope. Ideally I'd like to add another "note: brought
into scope here" message for all such conflicts with using-decls, but
that means that we need to actually track this for function using-decls
too.
That said, I imagine we could do this by instead of having a flag on the
OVERLOAD, instead have the OVERLOAD wrap a USING_DECL that has this
location on it. Which may be slightly less confusing, and should also
optimise for the (I expect?) common case of overloads not being usings.
Sure, perhaps instead of individually adding the used decls to the list
in the current scope, add a USING_DECL that refers to all of them, and
extend ovl_iterator to handle that case.
Jason
