<div dir="ltr">On 30 October 2013 13:24, Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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 class="im">On 10/30/2013 07:24 PM, Rafael Espíndola 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"><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">

<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">
do we interface<br>
"rich" non fatal errors with APIs that use error_code? Do we extend<br>
error code to carry a std::string too?<br>
</blockquote>
<br>
<br>
$ grep error_code lib/Bitcode/* -R<br>
$<br>
<br>
This gives zero results. Which API are you talking about? Do those API's<br>
really need std::string? Or are you saying they are forwarding the<br>
result of the Bitcode reader?<br>
</blockquote>
<br>
I found this when I started to implement a ObjectFile interface for<br>
bitcode files. I want that so that llvm-nm and llvm-ar (for now) can<br>
transparently use bitcode files. The interface used by ObjectFile is<br>
based on error_code.<br>
</blockquote>
<br></div>
Just out of interest. Are you planning to make the use of bitcode files supported for a wider audience? The problem I see here is that there is no good way for the tools to check if a certain bitcode file can be correctly read. At the moment, we are sometimes crashing, but e.g. the bug that I fixed caused invalid bitcode to be read. So bitcode files are only known to be really compatible for tools that use the very same version of LLVM (we try to maintain the ability to read older bitcode files, but this is not very well tested).  If we want to change this, we probably need some kind of version marker.<div class="im">

<br>
<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"><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">


Another option would be to just drop the AttributeKind id, in case Nick is<br>
OK with this.<br>
</blockquote>
<br>
Yes, that would also work.<br>
</blockquote>
<br></div>
Given the choice between this and the ability of gracefully fail if reading bitcode files, I very much prefer this.<br>
<br>
I copied Nick to get his opinion.<br></blockquote><div><br></div><div><div>Trying to loading an invalid .bc file shouldn't be fatal. I don't have a user which relies on this, but it seems like the right policy and is more important than including the number.</div>

</div><div><br></div><div>It is just intended to be a debugging aid; I can live without it as long as you can live with me cursing your name when I next get this error message. :-P</div><div><br></div><div>I haven't looked too closely. Is it that bad to make Error() take an std::string? Does this leak through the C API or something?</div>

<div><br></div><div>Nick</div></div></div></div>