[cfe-dev] [PATCH] libclang: report error code for bad PCH files
Dmitri Gribenko
gribozavr at gmail.com
Wed Feb 12 06:36:02 PST 2014
On Wed, Feb 12, 2014 at 11:04 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> On Wed, Feb 12, 2014 at 2:05 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
>> This seems more complicated than it’s worth, particularly since we do add a new API that the caller must be aware of, anyway.
>>
>> How about for the functions that don’t support detailed error codes we just introduce a new variant that does support error codes ?
>> Clients interested in the error codes can move to calling the new function (whether we should deprecate the existing one or not is a different question).
>
> This does seem cleaner. With this approach, we will have to introduce
> three new APIs, mirroring the following:
>
> clang_createTranslationUnitFromSourceFile
> clang_createTranslationUnit
> clang_parseTranslationUnit
>
> While these APIs already return error codes:
>
> clang_reparseTranslationUnit
> clang_indexSourceFile
I have implemented this approach in the attached patch. The new APIs
are just suffixed with "2", for example,
clang_createTranslationUnit2(), because of a lack of imagination and
to clearly show that the two parallel APIs are essentially the same.
I did not deprecate the old APIs, we can just treat them as
"convenience" wrappers.
I was thinking about changing the return type of
clang_reparseTranslationUnit and clang_indexSourceFile to 'enum
CXErrorCode', but I am not 100% that it is an ABI-compatible change on
all platforms (it is compatible on x86-64, I think), so I did not go
this way.
Please review.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
More information about the cfe-dev
mailing list