erichkeane wrote: > > I feel like this issue is a little too niche to be adding such complexity, > > maybe just covering those specific uses cases before codegen might be the > > way to go? > > I think disabling the keywords entirely is a large ask (requires an RFC at a > minimum) and so we don't need to go down that route right now.
I would be against said RFC. If you asked me in 1996/whatever, I could be talked into it. But we're 30+ years of this behavior. > > I think `constexpr` exceptions are a red herring; if the user disabled C++ > exceptions, they should be disabled at compile time same as at runtime. Some > users disable exceptions because of overhead, but plenty of users also > disable exceptions because of difficulties with reasoning about flow control > (some style guides explicitly require exceptions to not be used, for example). I'm coming around on this one, I think I agree. -fno-exceptions means `no-exceptions`. IF we get a further feature request to allow them to work at const-eval time, perhaps we can consider that, but it seems reasonable to do the disallow at the 'fully instantiated' point as I suggested above. > > Since we currently validate that the exception constructs are semantically > valid, I think we may as well retain them in the AST for now. It's how we > currently behave: https://godbolt.org/z/xPbEPWTK8 so it would be consistent > to do so in discarded statements too. https://github.com/llvm/llvm-project/pull/139859 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
