[PATCH] Separate file parsing from File's constructors.
Rui Ueyama
ruiu at google.com
Sat Dec 13 05:27:10 PST 2014
On Sat, Dec 13, 2014 at 5:25 AM, kledzik at apple.com <kledzik at apple.com>
wrote:
>
> The method Reader::parseFile() no longer has an appropriate name (since it
> no longer parses). It now just constructs a File object.
>
I will rename that later when everything is done.
>
>
> ================
> Comment at: include/lld/Core/File.h:157-171
> @@ -155,1 +156,17 @@
>
> + /// \brief Subclasses should override this method to parse the
> + /// memory buffer passed to this file's constructor.
> + virtual std::error_code doParse() { return std::error_code(); }
> +
> + /// \brief If a file is parsed using a different method than doParse(),
> + /// one must use this method to set the last error status, so that
> + /// doParse will not be called twice. Only YAML reader uses this
> + /// (because YAML reader does not read blobs but structured data).
> + void setLastError(std::error_code err) { _lastError = err; }
> +
> + std::error_code parse() {
> + if (!_lastError.hasValue())
> + _lastError = doParse();
> + return _lastError.getValue();
> + }
> +
> ----------------
> It is not clear why we need "lastError". You say it is for YAML, but the
> YAML reader could be changed to return some File object which you can later
> call parse() on. With that gone, you don't need to parse() and
> doParse(). You can have just parse() which subclasses override to do the
> actual parsing.
>
The reason to have parse() and doParse() is because I wanted to make it
safe to call parse() more than once. Currently parse() is called more than
once -- just after being instantiated and from Driver::link. If we provide
only parse(), then all subclasses need to implement that guard themselves.
>
> http://reviews.llvm.org/D6633
>
> EMAIL PREFERENCES
> http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141213/6b41f37e/attachment.html>
More information about the llvm-commits
mailing list