[cfe-dev] Proposal: Add a tooling helper to simplify fully qualified names when possible

Kaelyn Uhrain rikka at google.com
Fri Nov 16 09:54:26 PST 2012


On Wed, Nov 14, 2012 at 8:39 AM, David Blaikie <dblaikie at gmail.com> wrote:

> On Wed, Nov 14, 2012 at 6:01 AM, Daniel Cheng <dcheng at google.com> wrote:
> > I recently wrote a small tool to do some automated refactoring. During
> > that work, I ended up writing some helper functions to "simplify"
> > fully qualified names, i.e. if you're already in namespace a::b, you
> > can refer to a::b::C as "C" rather than using the fully qualified
> > name. I'm wondering if there'd be interest in upstreaming this
> > functionality into Clang, as I believe this would be a generally
> > useful utility.
> >
> > Currently, I have the following signature:
> >
> > // Attempts to find the most concise way to refer to 'symbol' in the
> given
> > // context. 'symbol' should be a fully qualified name.
> > string SimplifySymbol(
> >     const clang::ASTContext& ast_context,
> >     const clang::DeclContext* context,
> >     const string& symbol);  // I think this should probably be a
> > NamedDecl* to prevent ambiguities
> >
> > Do other people feel this sort of thing would be helpful, and if so,
> > where would it belong? It seems like it ought to be a member of
> > NamedDecl or DeclContext, but I'm new to Clang development, so I'm
> > interested in feedback and comments. Thanks!
>
> I haven't looked closely but would this be applicable to Clang's typo
> correction logic & improve the quality of the typo correction by
> offering minimally qualified names?
>

The typo correction code already has logic to try to build a minimal nested
name specifier for a potential correction by taking the chain of
NamespaceDecls for the current context/symbol and for the potential
correction and eliminating common elements. (see
NamespaceSpecifierSet::AddNamespace in lib/Sema/SemaLookup.cpp). It could
probably use a bit more refinement--particularly in the presence of "using
namespace ..." directives--though I've not yet seen cases where it gives
extraneous specifiers for a potential correction (it also uses the number
of added specifiers as part of the overall edit distance for the correction
candidate).


> If that's the case that might be a good angle of attack to get this
> upstream with a solid use case.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121116/0d8ed415/attachment.html>


More information about the cfe-dev mailing list