Sirraide wrote: > I don’t think there is a point in storing anything other than just the flags
In other words, the design approach I’m proposing is that instead of having two effects, `nolock` and `noallock`, we’d instead just have two *attributes* that each add a ‘set’ of effects, but those ‘sets’ would just be a set of flags. That is, instead of having a `nolock` attribute that adds a ‘`nolock` effect’, it could just add the flags that make up the ‘`nolock` effect’. As a consequence, `nolock` would then not really exist as a concept internally in the compiler, but rather, it’d just be a user-facing name for a set of flags; things like one effect subsuming another should then just work automatically as a result. Of course, that’s assuming that everything can just be modelled as flags, but at least I’m thinking most if not all of it could be. Basically, what I’m saying is *if* we’re introducing a bunch of flags for this (e.g. ‘should not throw’), then I’m not sure we need pick a specific set of flags and call it e.g. `noalloc`. If we want the named-effect-based approach or whatever you want to call it (as in, there is a specific `noalloc` effect that is subject to specific rules), then I’m not sure we need the flags in turn. More than anything, the part that I’m finding problematic is that this pr is currently making use of two seemigly orthogonal approaches to accomplishing the same thing, and I’m not convinced we need both. 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
