aaron.ballman added a comment. In https://reviews.llvm.org/D45835#1073883, @efriedma wrote:
> > If any of those options we care about wind up being changed, there's a good > > chance we may need to change something on our end anyway, so breaking us is > > actually useful. > > I'm not sure I follow. The language options have specific consequences you > could check some other way, so they're "stable" in the sense that the same > flags will produce the same result (e.g. LangOpts.FastMath represents whether > __FAST_MATH__ is defined). So it should be possible to provide the data > somehow; I'm more concerned about taking names and enum values from > LangOptions.def itself. When a name or enum value from LangOptions.def changes, that generally signals some behavior may have changed (we don't often rename things just for the sake of renaming them, but that seems a less likely scenario) and we might want to react to that in our product. That's why the list of names from LangOptions.def directly is somewhat of a benefit (but it is not a design requirement). How do you envision surfacing a list of language options that isn't tied to values from LangOptions.def itself? Would it still be tied in to the syntax in LangOptions.def (and others) so that there's not a substantial increase in maintenance burden when modifying options? https://reviews.llvm.org/D45835 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
