vgvassilev wrote: > Wouldn't isExplicitSpecializationOrInstantiation be a stronger guarantee than > isExplicitSpecialization, such that it would exclude a superset of what is > excluded by isExplicitSpecialization? If I did not misunderstand their source > code.
I wanted to filter out instantiations. > I generally don't think we can depend on this kind of behavior, especially as > it is far too difficult to control for the kind of consistency we want. I think we could make the template specializations consistent so that you at least cure the symptom of your problem. > My assumption was that this might be an improvement for other use-cases too, > but I failed to see the "give me code that compiles" use case. Understood. That's a pretty strong requirement for this case and we cannot really make a compromise. The idea is to offer an API which gives the user how would they reach certain AST node from within the global scope if they had to type it. > The only thing that comes to mind would be to condition the behavior to be > there or not. Similar to how we have WighGlobalNsPrefix we might have another > boolean or similar, so that the default behavior remains the same but it can > be conditioned to avoid this case. I would avoid doing that. In fact, I still do not see why the proposed solution would not work. If it solves the minimal case that you provided in the description of this PR, I am afraid that there is some bit from the Qt setup that we do not understand. https://github.com/llvm/llvm-project/pull/67566 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits