erichkeane wrote: > > The secret I think would be to still do the Profile, but instead of > > 'filling in' the attribute when you complete it, you replace it. Not > > uniquing it is a solution, but I would like to avoid doing something > > particularly 'special' here? > > @erichkeane By "instead of 'filling in' the attribute when you complete it, > you replace it" — do you mean creating a fresh CountAttributedType and > replacing the incomplete one? My concern with that is that every enclosing > type node would then need to be rebuilt. That's why replacing the placeholder > needed a TreeTransform, whereas filling in the expression wouldn't: the > enclosing nodes keep pointing at the same node and don't change at all. > > On 'special' — I think there's precedent for types that skip Profile, > particularly ones holding expressions, since expressions aren't uniqued > themselves. getVariableArrayType says so directly: "Since we don't unique > expressions, it isn't possible to unique VLA's that have an expression > provided for their size." A few other types skip it too. > > Thanks for staying with this, and for the suggestions — I think we're > converging on something good and I'll experiment with it.
Ah, right, I forgot it is type modifying. I think skipping profile/uniquing is acceptable/necessary. https://github.com/llvm/llvm-project/pull/212906 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
