jdoerfert added a comment. In D95764#2532927 <https://reviews.llvm.org/D95764#2532927>, @JonChesterfield wrote:
> I would have expected a nested match statement to hit on a subset of those > that matched in the parent. > > If (match x64) > If (match Intel) > > - expect x64 and intel to be true here > > I think that's how the normal openmp variant match works. It is. > Why do we want to diverge from that for (all?) extensions? For the same reason we have `match_any` and other things that modify the standard behavior, it is useful or even necessary to solve certain problems. > It would make for a semantic break if one of the extensions was standardised. Yes and no. Like a breaking change in the standard, that could happen on a conceptual level. However, if the standard would adopt part of the `match_any` semantics, it would not assume it to be in the `extension` trait set. Doing so would introduce problems for downstream extensions which are basically breaking changes. That said, you have to remember that the semantic of `match_any` (and `match_none`) was made up for LLVM and is already changing the behavior of the variant selector compared to the default described in the standard. The argument of this patch is that this made up semantics should be tweaked. FWIW, when I added the extension I haven't had implemented the selector inheritance yet, so at that point there was no practical difference. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95764/new/ https://reviews.llvm.org/D95764 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
