2012-12-05 01:29:32 +01:00
|
|
|
include "llvm/Option/OptParser.td"
|
|
|
|
|
|
2013-07-19 20:05:13 +02:00
|
|
|
def OptFlag1 : OptionFlag;
|
|
|
|
|
def OptFlag2 : OptionFlag;
|
|
|
|
|
def OptFlag3 : OptionFlag;
|
|
|
|
|
|
|
|
|
|
def A : Flag<["-"], "A">, HelpText<"The A option">, Flags<[OptFlag1]>;
|
2020-07-17 18:18:24 +02:00
|
|
|
def AB : Flag<["-"], "AB">;
|
2013-07-19 20:05:13 +02:00
|
|
|
def B : Joined<["-"], "B">, HelpText<"The B option">, MetaVarName<"B">, Flags<[OptFlag2]>;
|
|
|
|
|
def C : Separate<["-"], "C">, HelpText<"The C option">, MetaVarName<"C">, Flags<[OptFlag1]>;
|
|
|
|
|
def SLASH_C : Separate<["/", "-"], "C">, HelpText<"The C option">, MetaVarName<"C">, Flags<[OptFlag3]>;
|
2012-12-05 01:29:32 +01:00
|
|
|
def D : CommaJoined<["-"], "D">, HelpText<"The D option">, MetaVarName<"D">;
|
2013-07-19 20:05:13 +02:00
|
|
|
def E : MultiArg<["-"], "E", 2>, Flags<[OptFlag1, OptFlag2]>;
|
2012-12-05 01:29:32 +01:00
|
|
|
def F : JoinedOrSeparate<["-"], "F">, HelpText<"The F option">, MetaVarName<"F">;
|
|
|
|
|
def G : JoinedAndSeparate<["-"], "G">, HelpText<"The G option">, MetaVarName<"G">;
|
|
|
|
|
|
2013-07-19 20:05:13 +02:00
|
|
|
def Ceq : Joined<["-", "--"], "C=">, Alias<C>, Flags<[OptFlag1]>;
|
2012-12-05 01:29:32 +01:00
|
|
|
|
|
|
|
|
def H : Flag<["-"], "H">, Flags<[HelpHidden]>;
|
2013-07-22 18:18:13 +02:00
|
|
|
|
|
|
|
|
def my_group : OptionGroup<"my group">;
|
|
|
|
|
def I : Flag<["-"], "I">, Alias<H>, Group<my_group>;
|
2013-08-01 00:44:41 +02:00
|
|
|
|
|
|
|
|
def J : Flag<["-"], "J">, Alias<B>, AliasArgs<["foo"]>;
|
|
|
|
|
def Joo : Flag<["-"], "Joo">, Alias<B>, AliasArgs<["bar"]>;
|
2013-08-13 23:09:50 +02:00
|
|
|
|
2015-05-04 20:00:13 +02:00
|
|
|
def K : Flag<["-"], "K">, Alias<B>;
|
|
|
|
|
|
2013-08-13 23:09:50 +02:00
|
|
|
def Slurp : Option<["-"], "slurp", KIND_REMAINING_ARGS>;
|
2016-04-15 02:23:30 +02:00
|
|
|
|
|
|
|
|
def SlurpJoined : Option<["-"], "slurpjoined", KIND_REMAINING_ARGS_JOINED>;
|
[Option] Add 'findNearest' method to catch typos
Summary:
Add a method `OptTable::findNearest`, which allows users of OptTable to
check user input for misspelled options. In addition, have llvm-mt
check for misspelled options. For example, if a user invokes
`llvm-mt /oyt:foo`, the error message will indicate that while an
option named `/oyt:` does not exist, `/out:` does.
The method ports the functionality of the `LookupNearestOption` method
from LLVM CommandLine to libLLVMOption. This allows tools like Clang
and Swift, which do not use CommandLine, to use this functionality to
suggest similarly spelled options.
As room for future improvement, the new method as-is cannot yet properly suggest
nearby "joined" options -- that is, for an option string "-FozBar", where
"-Foo" is the correct option name and "Bar" is the value being passed along
with the misspelled option, this method will calculate an edit distance of 4,
by deleting "Bar" and changing "z" to "o". It should instead calculate an edit
distance of just 1, by changing "z" to "o" and recognizing "Bar" as a
value. This commit includes a disabled test that expresses this limitation.
Test Plan: `check-llvm`
Reviewers: yamaguchi, v.g.vassilev, teemperor, ruiu, jroelofs
Reviewed By: jroelofs
Subscribers: jroelofs, llvm-commits
Differential Revision: https://reviews.llvm.org/D41732
llvm-svn: 321877
2018-01-05 18:10:39 +01:00
|
|
|
|
|
|
|
|
def Blorp : Flag<["-", "--"], "blorp">, HelpText<"The blorp option">, Flags<[OptFlag1]>;
|
2019-04-30 19:46:00 +02:00
|
|
|
def Blarn : Flag<["--", "-"], "blarn">, HelpText<"The blarn option">, Flags<[OptFlag1]>;
|
[Option] Add 'findNearest' method to catch typos
Summary:
Add a method `OptTable::findNearest`, which allows users of OptTable to
check user input for misspelled options. In addition, have llvm-mt
check for misspelled options. For example, if a user invokes
`llvm-mt /oyt:foo`, the error message will indicate that while an
option named `/oyt:` does not exist, `/out:` does.
The method ports the functionality of the `LookupNearestOption` method
from LLVM CommandLine to libLLVMOption. This allows tools like Clang
and Swift, which do not use CommandLine, to use this functionality to
suggest similarly spelled options.
As room for future improvement, the new method as-is cannot yet properly suggest
nearby "joined" options -- that is, for an option string "-FozBar", where
"-Foo" is the correct option name and "Bar" is the value being passed along
with the misspelled option, this method will calculate an edit distance of 4,
by deleting "Bar" and changing "z" to "o". It should instead calculate an edit
distance of just 1, by changing "z" to "o" and recognizing "Bar" as a
value. This commit includes a disabled test that expresses this limitation.
Test Plan: `check-llvm`
Reviewers: yamaguchi, v.g.vassilev, teemperor, ruiu, jroelofs
Reviewed By: jroelofs
Subscribers: jroelofs, llvm-commits
Differential Revision: https://reviews.llvm.org/D41732
llvm-svn: 321877
2018-01-05 18:10:39 +01:00
|
|
|
def Cramb : Joined<["/"], "cramb:">, HelpText<"The cramb option">, MetaVarName<"CRAMB">, Flags<[OptFlag1]>;
|
|
|
|
|
def Doopf1 : Flag<["-"], "doopf1">, HelpText<"The doopf1 option">, Flags<[OptFlag1]>;
|
|
|
|
|
def Doopf2 : Flag<["-"], "doopf2">, HelpText<"The doopf2 option">, Flags<[OptFlag2]>;
|
|
|
|
|
def Ermgh : Joined<["--"], "ermgh">, HelpText<"The ermgh option">, MetaVarName<"ERMGH">, Flags<[OptFlag1]>;
|
[Option] For typo '-foo', suggest '--foo'
Summary:
https://reviews.llvm.org/rL321877 introduced the `OptTable::findNearest`
method, to find the closest edit distance option for a given string.
However, the implementation contained a bug: for a typo `-foo` with an
edit distance of 1 away from a valid option `--foo`, `findNearest`
would suggest a nearby option of `foo`. That is, the result would not
include the `--` prefix, and so was not a valid option.
Fix the bug by ensuring that the prefix string is initialized to one of
the valid prefixes for the option.
Test Plan: `check-llvm-unit`
Reviewers: v.g.vassilev, teemperor, ruiu, jroelofs, yamaguchi
Reviewed By: jroelofs
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41873
llvm-svn: 322109
2018-01-09 20:38:04 +01:00
|
|
|
def Fjormp : Flag<["--"], "fjormp">, HelpText<"The fjormp option">, Flags<[OptFlag1]>;
|
2019-05-01 16:46:17 +02:00
|
|
|
|
2019-05-01 18:45:15 +02:00
|
|
|
def Glorrmp_eq : Flag<["--"], "glorrmp=">;
|
|
|
|
|
|
|
|
|
|
def Blurmpq : Flag<["--"], "blurmp">;
|
|
|
|
|
def Blurmpq_eq : Flag<["--"], "blurmp=">;
|
2019-05-01 16:46:17 +02:00
|
|
|
|
[Option] Add 'findNearest' method to catch typos
Summary:
Add a method `OptTable::findNearest`, which allows users of OptTable to
check user input for misspelled options. In addition, have llvm-mt
check for misspelled options. For example, if a user invokes
`llvm-mt /oyt:foo`, the error message will indicate that while an
option named `/oyt:` does not exist, `/out:` does.
The method ports the functionality of the `LookupNearestOption` method
from LLVM CommandLine to libLLVMOption. This allows tools like Clang
and Swift, which do not use CommandLine, to use this functionality to
suggest similarly spelled options.
As room for future improvement, the new method as-is cannot yet properly suggest
nearby "joined" options -- that is, for an option string "-FozBar", where
"-Foo" is the correct option name and "Bar" is the value being passed along
with the misspelled option, this method will calculate an edit distance of 4,
by deleting "Bar" and changing "z" to "o". It should instead calculate an edit
distance of just 1, by changing "z" to "o" and recognizing "Bar" as a
value. This commit includes a disabled test that expresses this limitation.
Test Plan: `check-llvm`
Reviewers: yamaguchi, v.g.vassilev, teemperor, ruiu, jroelofs
Reviewed By: jroelofs
Subscribers: jroelofs, llvm-commits
Differential Revision: https://reviews.llvm.org/D41732
llvm-svn: 321877
2018-01-05 18:10:39 +01:00
|
|
|
def DashDash : Option<["--"], "", KIND_REMAINING_ARGS>;
|
2020-11-09 21:51:42 +01:00
|
|
|
|
[clang][cli] Specify KeyPath prefixes via TableGen classes
It turns out we need to handle `LangOptions` separately from the rest of the options. `LangOptions` used to be conditionally parsed only when `!(DashX.getFormat() == InputKind::Precompiled || DashX.getLanguage() == Language::LLVM_IR)` and we need to restore this order (for more info, see D94682).
We could do this similarly to how `DiagnosticOptions` are handled: via a counterpart to the `IsDiag` mix-in (e.g. `IsLang`). These mix-ins would prefix the option key path with the appropriate `CompilerInvocation::XxxOpts` member. However, this solution would be problematic, as we'd now have two kinds of options (`Lang` and `Diag`) with seemingly incomplete key paths in the same file. To understand what `CompilerInvocation` member an option affects, one would need to read the whole option definition and notice the `IsDiag` or `IsLang` class.
Instead, this patch introduces more robust way to handle different kinds of options separately: via the `KeyPathAndMacroPrefix` class. We have one specialization of that class per `CompilerInvocation` member (e.g. `LangOpts`, `DiagnosticOpts`, etc.). Now, instead of specifying a key path with `"LangOpts->UndefPrefixes"`, we use `LangOpts<"UndefPrefixes">`. This keeps the readability intact (you don't have to look for the `IsLang` mix-in, the key path is complete on its own) and allows us to specify a custom macro prefix within `LangOpts`.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D94676
2021-01-13 12:50:19 +01:00
|
|
|
class XOpts<string base> : KeyPathAndMacro<"X->", base> {}
|
|
|
|
|
|
2020-11-11 11:05:24 +01:00
|
|
|
def marshalled_flag_d : Flag<["-"], "marshalled-flag-d">,
|
[clang][cli] Specify KeyPath prefixes via TableGen classes
It turns out we need to handle `LangOptions` separately from the rest of the options. `LangOptions` used to be conditionally parsed only when `!(DashX.getFormat() == InputKind::Precompiled || DashX.getLanguage() == Language::LLVM_IR)` and we need to restore this order (for more info, see D94682).
We could do this similarly to how `DiagnosticOptions` are handled: via a counterpart to the `IsDiag` mix-in (e.g. `IsLang`). These mix-ins would prefix the option key path with the appropriate `CompilerInvocation::XxxOpts` member. However, this solution would be problematic, as we'd now have two kinds of options (`Lang` and `Diag`) with seemingly incomplete key paths in the same file. To understand what `CompilerInvocation` member an option affects, one would need to read the whole option definition and notice the `IsDiag` or `IsLang` class.
Instead, this patch introduces more robust way to handle different kinds of options separately: via the `KeyPathAndMacroPrefix` class. We have one specialization of that class per `CompilerInvocation` member (e.g. `LangOpts`, `DiagnosticOpts`, etc.). Now, instead of specifying a key path with `"LangOpts->UndefPrefixes"`, we use `LangOpts<"UndefPrefixes">`. This keeps the readability intact (you don't have to look for the `IsLang` mix-in, the key path is complete on its own) and allows us to specify a custom macro prefix within `LangOpts`.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D94676
2021-01-13 12:50:19 +01:00
|
|
|
MarshallingInfoFlag<XOpts<"MarshalledFlagD">>;
|
2020-11-11 11:05:24 +01:00
|
|
|
def marshalled_flag_c : Flag<["-"], "marshalled-flag-c">,
|
[clang][cli] Specify KeyPath prefixes via TableGen classes
It turns out we need to handle `LangOptions` separately from the rest of the options. `LangOptions` used to be conditionally parsed only when `!(DashX.getFormat() == InputKind::Precompiled || DashX.getLanguage() == Language::LLVM_IR)` and we need to restore this order (for more info, see D94682).
We could do this similarly to how `DiagnosticOptions` are handled: via a counterpart to the `IsDiag` mix-in (e.g. `IsLang`). These mix-ins would prefix the option key path with the appropriate `CompilerInvocation::XxxOpts` member. However, this solution would be problematic, as we'd now have two kinds of options (`Lang` and `Diag`) with seemingly incomplete key paths in the same file. To understand what `CompilerInvocation` member an option affects, one would need to read the whole option definition and notice the `IsDiag` or `IsLang` class.
Instead, this patch introduces more robust way to handle different kinds of options separately: via the `KeyPathAndMacroPrefix` class. We have one specialization of that class per `CompilerInvocation` member (e.g. `LangOpts`, `DiagnosticOpts`, etc.). Now, instead of specifying a key path with `"LangOpts->UndefPrefixes"`, we use `LangOpts<"UndefPrefixes">`. This keeps the readability intact (you don't have to look for the `IsLang` mix-in, the key path is complete on its own) and allows us to specify a custom macro prefix within `LangOpts`.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D94676
2021-01-13 12:50:19 +01:00
|
|
|
MarshallingInfoFlag<XOpts<"MarshalledFlagC">>,
|
2021-01-26 09:21:55 +01:00
|
|
|
ImpliedByAnyOf<[marshalled_flag_d.KeyPath], "true">;
|
2020-11-11 11:05:24 +01:00
|
|
|
def marshalled_flag_b : Flag<["-"], "marshalled-flag-b">,
|
[clang][cli] Specify KeyPath prefixes via TableGen classes
It turns out we need to handle `LangOptions` separately from the rest of the options. `LangOptions` used to be conditionally parsed only when `!(DashX.getFormat() == InputKind::Precompiled || DashX.getLanguage() == Language::LLVM_IR)` and we need to restore this order (for more info, see D94682).
We could do this similarly to how `DiagnosticOptions` are handled: via a counterpart to the `IsDiag` mix-in (e.g. `IsLang`). These mix-ins would prefix the option key path with the appropriate `CompilerInvocation::XxxOpts` member. However, this solution would be problematic, as we'd now have two kinds of options (`Lang` and `Diag`) with seemingly incomplete key paths in the same file. To understand what `CompilerInvocation` member an option affects, one would need to read the whole option definition and notice the `IsDiag` or `IsLang` class.
Instead, this patch introduces more robust way to handle different kinds of options separately: via the `KeyPathAndMacroPrefix` class. We have one specialization of that class per `CompilerInvocation` member (e.g. `LangOpts`, `DiagnosticOpts`, etc.). Now, instead of specifying a key path with `"LangOpts->UndefPrefixes"`, we use `LangOpts<"UndefPrefixes">`. This keeps the readability intact (you don't have to look for the `IsLang` mix-in, the key path is complete on its own) and allows us to specify a custom macro prefix within `LangOpts`.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D94676
2021-01-13 12:50:19 +01:00
|
|
|
MarshallingInfoFlag<XOpts<"MarshalledFlagB">>,
|
2021-01-26 09:21:55 +01:00
|
|
|
ImpliedByAnyOf<[marshalled_flag_d.KeyPath], "true">;
|
2020-11-11 11:05:24 +01:00
|
|
|
def marshalled_flag_a : Flag<["-"], "marshalled-flag-a">,
|
[clang][cli] Specify KeyPath prefixes via TableGen classes
It turns out we need to handle `LangOptions` separately from the rest of the options. `LangOptions` used to be conditionally parsed only when `!(DashX.getFormat() == InputKind::Precompiled || DashX.getLanguage() == Language::LLVM_IR)` and we need to restore this order (for more info, see D94682).
We could do this similarly to how `DiagnosticOptions` are handled: via a counterpart to the `IsDiag` mix-in (e.g. `IsLang`). These mix-ins would prefix the option key path with the appropriate `CompilerInvocation::XxxOpts` member. However, this solution would be problematic, as we'd now have two kinds of options (`Lang` and `Diag`) with seemingly incomplete key paths in the same file. To understand what `CompilerInvocation` member an option affects, one would need to read the whole option definition and notice the `IsDiag` or `IsLang` class.
Instead, this patch introduces more robust way to handle different kinds of options separately: via the `KeyPathAndMacroPrefix` class. We have one specialization of that class per `CompilerInvocation` member (e.g. `LangOpts`, `DiagnosticOpts`, etc.). Now, instead of specifying a key path with `"LangOpts->UndefPrefixes"`, we use `LangOpts<"UndefPrefixes">`. This keeps the readability intact (you don't have to look for the `IsLang` mix-in, the key path is complete on its own) and allows us to specify a custom macro prefix within `LangOpts`.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D94676
2021-01-13 12:50:19 +01:00
|
|
|
MarshallingInfoFlag<XOpts<"MarshalledFlagA">>,
|
2021-01-26 09:21:55 +01:00
|
|
|
ImpliedByAnyOf<[marshalled_flag_c.KeyPath, marshalled_flag_b.KeyPath]>;
|
