[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