<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Hello Community,<br>
<br>
I have been recently talking to Lang hames about OrcJIT and new Error<br>
Handling mechanism called Error ( a.k.a TypedError ). I hope the patch will<br>
be in upstream repo by 23 May, 2016.</span></blockquote><div>Update : The changes are already in upstream now. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"> So we have figured out a task for GSoC<br>
2016 and we need your suggestion for the same.<br>
<br>
The task is to design and implement Error class hierarchy for ELF in<br>
libObject and thus  avail benefits of TypedError to provide more rich<br>
diagnostics to the clients. I have read and understand the discussion going<br>
on RFC for TypedError and there are lots of benefits that helps users of<br>
the particular library. For example one benefit "Difficult to drop" that<br>
makes user aware of the error and forces to handle it. Similarly other<br>
benefits can help to understand the error better.<br>
<br>
So there is already a plan for integrating this features for MachO. I would<br>
like to work on ELF side. Roughly the work will involve identifying<br>
different class of errors and buid their hierarchy and also how to improve<br>
the error with supplying information from the context. Then implementing<br>
the design and replacing old error mechanism. I am still reading more<br>
details about this. If this work is not sufficient for 3 moths of time than<br>
I can add implementing diagnostic Errors for OrcJIT API's (as I have been<br>
experimenting with then currently) the similar work flow would be there.<br>
You may also suggest additional work on similar path.<br>
<br>
So I have some questions for this idea:<br>
<br>
1) Is this a good idea for a GSoC project ?<br>
2) If any one is available to mentor me for this ?<br>
3) How important this is for LLVM ?<br>
<br>
and any other suggestions are welcomed. As application period has already<br>
begun I need to be little quick but I think I would be able to build a good<br>
proposal if provided enough guidance.<br>
<br>
A special thanks to Lang Hames for suggesting this topic.<br>
<br>
Sincerely,<br></div></div>
*Vivek Pandya*<br></blockquote></div></div></div></blockquote></div></div></div>