This is an archive of the discontinued LLVM Phabricator instance.

fix determination of whether declarations are visible during ObjC lookups
Needs ReviewPublic

Authored by rsmith on Jun 21 2017, 7:11 PM.

Details

Reviewers
bruno
Summary

Determining whether a declaration is visible or not requires knowledge of the context in which the question is asked: for instance, during template instantiation, additional modules might be visible, and with local submodule visibility, the set of visible declarations can shrink as well as grow throughout the compilation.

This patch explicitly passes an "is hidden" callback to all ObjC lookup functions on Decl rather than relying on the increasingly-inaccurate Hidden bit to provide useful information. (Ideally, these lookup functions would be moved to Sema instead; that change can follow if it makes sense.)

Please pay particular attention to the places where AllDeclsVisible is passed: in those places, we do not have any local visibility context. Possibly some of them should be doing something more subtle than ignoring module visibility rules.

The test from PR33552 does /not/ pass with this change, I'm still digging into what else might be wrong here.

Diff Detail

Repository
rL LLVM

Event Timeline

rsmith created this revision.Jun 21 2017, 7:11 PM
rsmith updated this revision to Diff 103678.Jun 22 2017, 6:16 PM

The remaining missing pieces were ObjCInterfaceDecl::visible_categories and ObjCInterfaceDecl::visible_extensions. The new revision of the patch gets a bit further down the road of passing through real visibility information into those, but that approach seems to snowball out of control. For example, ASTContext::mergeTypes now needs visibility information in order to determine whether two ObjC object types are compatible (because this depends on whether the types have compatible sets of protocols, which in turn can vary depending on which categories are visible for those two types). I have not completed this patch: there are still a lot of places that an IsHiddenFunction would need to be plumbed through to make this work.

The fact that type compatibility can vary depending on the context in which you ask seems like a significant design issue with ObjC categories; perhaps a modest and reasonable change to the language (and particularly the interaction between modules and categories) could avoid at least some of this implementation complexity, but I'm not the right person to design or champion such a change.