<div dir="ltr">Totally a casual comment & I could be totally off: Parser error recovery can be really helpful to users (eg: Clang's error recovery), though (much like using TLS for the general error handling improvements, and my comments there) I expect this is a good first step and better error recovery can be added over time to improve the user experience here.<br><br>As you've said, it's certainly not a terribly easy thing to do great error recovery, and I wouldn't suggest trying to solve everything up-front, for sure.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 6:44 PM, Rui Ueyama via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ruiu created this revision.<br>
ruiu added a reviewer: rafael.<br>
ruiu added a subscriber: llvm-commits.<br>
<br>
Propagating errors back to callers is annoying in recursive descendent<br>
parser because they are naturally constructed as mutually recursive<br>
functions. In this patch, I took a simple approach. The accessors of<br>
the token stream behaves as if they are at EOF once we saw any errors.<br>
It naturally makes all functions to return.<br>
<br>
This is the final change to not use fatal in the linker.<br>
<br>
<a href="http://reviews.llvm.org/D16667" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16667</a><br>
<br>
Files:<br>
  ELF/LinkerScript.cpp<br>
<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>