similar to: [CommandLine] Unable to implement a custom parser -- all marked final

Hi David: I'd actually like to use a custom parser in a tool I'm developing, parsing YAML files. The partial fix for my purposes was: --- a/llvm/include/llvm/Support/CommandLine.h +++ b/llvm/include/llvm/Support/CommandLine.h @@ -1044,7 +1044,7 @@ extern template class basic_parser<float>; //-------------------------------------------------- // parser<std::string> //

All, I'm upgrading some code that uses LLVM from 3.6 to 3.7. It looks like the llvm::cl::parser subclasses are now final? We had been doing: struct MaxThreadsParser : public llvm::cl::parser<unsigned> { bool parse(llvm::cl::Option &O, llvm::StringRef ArgName, llvm::StringRef Arg, unsigned &Val); }; But that's now causing: In file included from

Hi David, Is there a reason that we need to have "final" for parser<bool> ??? This breaks the compilation of mclinker which derives a class from this. In file included from /home/rkotler/workspace/mclinker/lib/Support/CommandLine.cpp:9:0: /home/rkotler/workspace/mclinker/include/mcld/Support/CommandLine.h:49:7: error: cannot derive from ‘final’ base

//===----------------------------------------------------------------------===// // FalseParser //===----------------------------------------------------------------------===// class FalseParser : public parser<bool> { public: explicit FalseParser(Option &O) : parser<bool>(O) { } // parse - Return true on error. bool parse(cl::Option& O, StringRef ArgName, StringRef

One could argue that mclinker is doing something good or not by how it's using this class but I don't see the need for parser<bool> to be final. That is a subjective opinion that mclinker needs to be changed. I think that "final" was added to some of these command line classes to avoid some kind of clang warning. That seems wrong to me that the tools are dictating

Folks, It seems we got the same issue with Clang alignment as before: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/3025 http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/485 http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/118 Commits between 231213 and 231255. There are a few issues that could have brought it: *

On 03/19/2015 08:55 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 4:30 AM, Reed Kotler <Reed.Kotler at imgtec.com > <mailto:Reed.Kotler at imgtec.com>> wrote: > > One could argue that mclinker is doing something good or not by > how it's using this class > but I don't see the need for parser<bool> to be final. That is a >

Well, you are an mclinker contributor and Google uses mclinker and now it's broken as the result of your change. I still don't see any justification to making a change in a public interface that is used by other non LLVM projects to fix some issue with clang warnings. People should be able to derive from those classes. I can't understand your reasoning as to why these classes must

On 03/19/2015 09:24 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > Well, you are an mclinker contributor > > > Me personally? Not that I know of. Sorry. I thought i had seen your name in an mclinker commit. > > and Google uses mclinker >

On Sat, Oct 14, 2017 at 4:22 PM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > The only way I could reproduce the problem you are seeing was to rerun > cmake with -DCMAKE_BUILD_TYPE=Debug in a build directory previously > configured with -DCMAKE_BUILD_TYPE=Release. I can fix that, but not sure > if it's what you are seeing. > > If this isn't your

On 03/19/2015 09:38 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:34 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > On 03/19/2015 09:24 AM, David Blaikie wrote: >> >> >> On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler >> <reed.kotler at imgtec.com <mailto:reed.kotler at

On Sun, Oct 15, 2017 at 10:58 AM, Don Hinton <hintonda at gmail.com> wrote: > Thanks Aaron. > > I don't have a Windows system, and haven't seen any buildbot failures, so I > it's difficult to come up with a patch for something I can't reproduce > locally or see any actual failures. Could you send me the commands you used > that uncovered the failure? This

On Sat, Oct 14, 2017 at 11:38 AM, Don Hinton <hintonda at gmail.com> wrote: > Sorry, LLVM_FORCE_ENABLE_DUMP is the variable, which is used along with > LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP. > > Again, I'm working on a fix, but could you also provide your cmake > command? Looks like we aren't handling your use case correctly. > > thanks.. > don >

On 03/19/2015 09:57 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:52 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > On 03/19/2015 09:38 AM, David Blaikie wrote: >> >> >> On Thu, Mar 19, 2015 at 9:34 AM, Reed Kotler >> <reed.kotler at imgtec.com <mailto:reed.kotler at

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along > with the rest of llvm. I'll work up a complete patch shortly. > > Btw, I'm curious how this happened. Do you have a stale CMakeCache.txt by > any chance? You might check the value for

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along with > the rest of llvm. I'll work up a complete patch shortly. This also broke the build for MSVC when doing a debug build (though no builder seems to be picking up the failure!). After

Hi, It looks like the "Writing a custom parser" example from the CommandLine 2.0 Library Manual is broke for 3.0+. This used to work with llvm-2.9. When I try to compile it I get: ../include/llvm/Support/CommandLine.h:964:20: error: no viable conversion from 'const FileSizeParser' to 'parser<unsigned>' I fixed it by changing struct FileSizeParser : public

On Sun, Oct 15, 2017 at 11:19 AM, Don Hinton <hintonda at gmail.com> wrote: > On Sun, Oct 15, 2017 at 8:06 AM, Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> On Sun, Oct 15, 2017 at 10:58 AM, Don Hinton <hintonda at gmail.com> wrote: >> > Thanks Aaron. >> > >> > I don't have a Windows system, and haven't seen any

On Sat, Oct 14, 2017 at 10:25 AM, Don Hinton <hintonda at gmail.com> wrote: > Hi Jack: > > Looks like I missed this one in my recent change. > > Please let me know if this solves your problem: > > $ git diff > diff --git a/utils/TableGen/InfoByHwMode.cpp > b/utils/TableGen/InfoByHwMode.cpp > index 7e1e1864356..8d3636432aa 100644 > ---

On Sun, Oct 15, 2017 at 12:40 PM, Don Hinton <hintonda at gmail.com> wrote: > On Sun, Oct 15, 2017 at 8:34 AM, Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> FWIW, most of the ones I was fixing up were guarded by NDEBUG instead >> of LLVM_ENABLE_DUMP. Switching to LLVM_ENABLE_DUMP fixed the link >> errors for me -- the only one I struggled with