================
@@ -53,10 +53,8 @@ class OptTable {
public:
/// Entry for a single option instance in the option data table.
struct Info {
- /// A null terminated array of prefix strings to apply to name while
- /// matching.
- ArrayRef<StringLiteral> Prefixes;
- StringLiteral PrefixedName;
+ unsigned PrefixesOffset;
----------------
chandlerc wrote:
Maybe? I'm not opposed to adding a string table abstraction similar to what
you're mentioning -- I would probably strucutre it a bit the other way around
but that's neither here nor there.
That said, could that be a follow-up rather than blocking? There are many uses
of raw string tables and `unsigned` indices for them from TableGen-ed code
already, and so I don't feel like this is a terribly problematic intermediate
state.
And it should be relatively trivial to switch this code to use the abstraction
once its using tables everywhere. The much more disruptive change I've found is
getting the existing code to use tables at all.
https://github.com/llvm/llvm-project/pull/119198
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
