igorkudrin wrote: > > > I would _really_ like to get rid of the operations over stack allocated > > > AST nodes. > > > > This deserves its own atomic patch, separate from other changes, no? > > This PR is intended to simplify resolveAllocationOverload(), it is a > restructuring, and removing the stack allocated nodes is part of that > simplification -- if we want to simplify this code, we need to simplify it.
This PR restructures the existing code, yes, in a way that it is now easy to implement CWG2282, or fix deficiencies in the current implementation of the type-aware allocation function resolution, or fix emitting diagnostics in the msvc-specific fallback. The optimizations around AST nodes are just orthogonal to these goals and can be done independently of this change, pursuing their own goals. As far as I understand the idea, it is more about efficiency rather than simplicity. It can be implemented at any time, before or after other changes, with the same result. > The complexity of this code is a consequence of _structural_ deficiencies, > the current PR does not address those structural issues, it's trying to > "simplify" the code around those deficiencies. The result is that I do not > believe that it is meaningfully changing the complexity of the code, it is > essentially shuffling the complexity around. This PR targets very specific deficiencies of the existing code, i.e., mutating the argument lists and allocation parameters in nested/recursive calls. I'd also prefer the idea of checking all the variants in a cycle, creating argument lists on the fly. But when the cycle ends without a result, we need to emit the diagnostic, listing all considered candidates with their corresponding argument lists. This means that after the cycle, the argument lists need to be reconstructed again, and the candidates need to be filtered again, taking into account that some candidate argument lists should be ignored for diagnostic purposes. Trying to cram the msvc-specific fallback in this scheme makes it even more convoluted. As I could not find an elegant solution for these issues, I preferred a simple, linear, straightforward scheme with a do-while loop for early exit. Am I missing anything? https://github.com/llvm/llvm-project/pull/203824 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
