Sirraide wrote: One more thing: if we’re already introducing a set of flags that indicate the properties of each effect (e.g. must not throw etc.), is there anything else to effects than the union of those flags? In other words, can’t we just store the flags directly in the function type and call it a day?
As I see it, either all of an effect’s properties should be modelled as flags, or none should be (mixing the two sounds like the most complicated approach), and if we’re doing the former, then I don’t think there is a point in storing anything other than just the flags. For diagnostics, it is of course reasonable to be able to print e.g. ‘`throw X` is not allowed here because the function is declared Y’, but at least so long as you have a `TypeLoc` (and it’s worth noting that we might want to refactor `AttributedType`s to actually store the attribute rather than just the attribute kind, which I’ve been looking into a bit; if that would simplify the implementation of this system, then that would be another reason to seriously consider this refactor), you should be able to recover that information from the function type. In other words, I’m not sure we really need a sophisticated data for computing differences and set unions of effects considering that the actual `FunctionEffect` struct boils down to two enums, the first of which doesn’t seem to do that much. Also, I know that this is a lot of criticism on my part, but I just want to avoid adding overly complex machinery into an already fairly complex code base if we can avoid it. https://github.com/llvm/llvm-project/pull/84983 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
