[PATCH] D82579: [NFC] Extract unifyTargetFeatures

Yaxun Liu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jun 25 13:39:15 PDT 2020


yaxunl marked 3 inline comments as done.
yaxunl added inline comments.


================
Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:93
+    StringRef Name = Features[I];
+    assert(Name[0] == '-' || Name[0] == '+');
+    LastOpt[Name.drop_front(1)] = I;
----------------
tra wrote:
> yaxunl wrote:
> > tra wrote:
> > > I don't think assert should be used for something that may be specified to the user on command line.
> > > 
> > The entries in this array is not directly from command line.
> > 
> > It is either put in by clang code, or translated from -mxxx or -mno-xxx options whereas the translated entry should always have + or - prefix. So if things go wrong, it is due to developers.
> While clang may be the primary user of those options, features can be specified by the user, too.
> The general rule of thumb is that invalid external input should produce diagnostics, not compiler crashes.
> Asserts are for programming errors. Granted, when the inputs may be  generated by our code the boundary is blurred, but in this case I would err on the side of not crashing.
user may use -target-feature to directly specify features and they may forget +/- there but that is a -cc1 option, whereas this function is used in `tool` and will never be used in -cc1. The features in this vector can only come from clang driver, where the code is supposed to always add +/- to the entries. How could user inputs can cause +/- not added?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82579/new/

https://reviews.llvm.org/D82579





More information about the cfe-commits mailing list