<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 8, 2015 at 3:36 PM, Matthew O'Connor via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>All,<br><br></div>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?<br><br></div>We had been doing:<br><br>struct MaxThreadsParser : public llvm::cl::parser<unsigned> {<br>  bool parse(llvm::cl::Option &O, llvm::StringRef ArgName, llvm::StringRef Arg,<br>             unsigned &Val);<br>};<br><br></div>But that's now causing:<br><br>In file included from /home/lak/my_svn/llvm-carte/llvm-3.7.0/tools/carte++/tools/ir2v/ThreadSupport.cpp:1:<br>/home/lak/my_svn/llvm-carte/llvm-3.7.0/tools/carte++/tools/ir2v/ThreadSupport.h:12:34: error: <br>      base 'parser' is marked 'final'<br>struct MaxThreadsParser : public llvm::cl::parser<unsigned> {<br><br></div>What's the new way to do this now? It looks like the documentation at <a href="http://llvm.org/releases/3.7.0/docs/CommandLine.html#custom-parsers" target="_blank">http://llvm.org/releases/3.7.0/docs/CommandLine.html#custom-parsers</a> describes a way that doesn't work anymore.<br></div></div></div></blockquote><div><br></div><div>Yeah, someone filed <a href="https://llvm.org/bugs/show_bug.cgi?id=25104">https://llvm.org/bugs/show_bug.cgi?id=25104</a> for this recently.<br><br>I was the person who made this API change - hadn't seen the documentation we had suggesting/encouraging people to do this, but I'm sort of inclined to say that was a mistake - but open to discussion.<br><br>The reason for the change was to devirtualize parser<T>'s dtor - since it wasn't ever owned/destroyed polymorphically, so there was no need for it. But to keep the type safe, this meant making the dtor protected in the base class and making the derived classes final (so there couldn't be further derived classes and then polymorphic ownership of the intermediate class type).<br><br>Not sure how other people feel about it - whether this is a particularly compelling extension point for us to support.<br><br>It looks like you could just write your class as a subclass of basic_parser<unsigned> and go from there instead of deriving from parser<T> directly. You might have to implement one or two more functions that way.<br><br>- David</div></div></div></div>