It turns out that I'm only looking for conflicts in the unqualified name, since I will never introduce a qualified variable in the Init portion of a for loop.<div><br></div><div>My current strategy is to grab the DeclContext from the loop's index or iterator variable and use that as a starting point to check for naming conflicts with existing variables. The difficult part is identifying when my own changes would conflict with themselves, which I accomplish by building up a reversed AST tree containing only Stmt nodes, so that I can ask for the parent of any Stmt. Ideally, this would be done by the AST or some other utility, though the data structure is only computed once per run of the migration tool.</div>
<div><br></div><div>-Sam</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 16, 2012 at 1:48 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Sat, Jul 14, 2012 at 3:13 AM, Sam Panzer <<a href="mailto:panzer@google.com">panzer@google.com</a>> wrote:<br>
> Hi everyone,<br>
><br>
> When a tool introduces a new declaration or renames an old one, it will need<br>
> to make sure that the existing semantics are preserved. In particular, it is<br>
> possible for the new declaration to conflict with or shadow an existing one,<br>
> which means the tool needs to be particularly careful.<br>
><br>
> My first guess would be to check all enclosing and enclosed DeclContexts for<br>
> declarations with the same identifier. Is this a reasonable strategy, and if<br>
> so, would matchers be able to track the DeclContexts of their results? It<br>
> gets even more interesting when the refactoring tool wants to introduce two<br>
> separate declarations that might conflict with each other.<br>
<br>
</div></div>If you have a declaration, you can traverse the decl-contexts from the<br>
ast context. We have some snippets of code that we haven't upstreamed<br>
yet, which do traversal of the decl-contexts, and are probably not<br>
perfect yet. See below.<br>
<br>
I'd rather not have the matcher layer try to implement pulling<br>
together additional information. I'd rather try to either get Sema<br>
involved (like you suggested earlier) or add stuff somewhere into the<br>
AST so we can retrieve it later; perhaps make that optional.<br>
<br>
Thoughts?<br>
/Manuel<br>
<br>
inline bool HasSymbol(<br>
    const clang::ASTContext& ast_context,<br>
    const clang::DeclContext* context,<br>
    const llvm::SmallVectorImpl<llvm::StringRef>& components,<br>
    int component) {<br>
  if (context == NULL) {<br>
    return false;<br>
  }<br>
  if (component == components.size()) {<br>
    // Found the symbol.<br>
    return true;<br>
  }<br>
  clang::IdentifierInfo& identifier =<br>
      ast_context.Idents.get(components[component]);<br>
  clang::DeclContext::lookup_const_result result = context->lookup(&identifier);<br>
  for (clang::NamedDecl* const * it = result.first; it != result.second; ++it) {<br>
    if (HasSymbol(ast_context, clang::NamedDecl::castToDeclContext(*it),<br>
                  components, component+1)) {<br>
      return true;<br>
    }<br>
  }<br>
  return false;<br>
}<br>
inline bool HasGlobalSymbol(<br>
    const clang::ASTContext& ast_context, const string& symbol) {<br>
  llvm::StringRef symbol_ref(symbol.c_str(), symbol.size());<br>
  llvm::SmallVector<llvm::StringRef, 4> components;<br>
  symbol_ref.split(components, "::");<br>
  clang::DeclContext* decl = ast_context.getTranslationUnitDecl();<br>
  return HasSymbol(ast_context, decl, components, 0);<br>
}<br>
<br>
><br>
> Thanks!<br>
><br>
> -Sam<br>
</blockquote></div><br></div>