[PATCH] [LLD] COFF: Define error categories for Driver, Reader and Resolver.

[Simon Atanasyan]

Just FYI

MCLinker does not use error codes returning from function at all. In
case of error/warning/etc you can print an appropriate message
something like below. The "error manager" is responsible to print the
message and to count number of errors, warnings, etc.

[[
    error(diag::error_Mips_abiflags_invalid_version) << version <<
pInput.name();
]]

The linker attempts to continue execution as much as possible but
checks the number of reported errors in some critical points like
after reading input files, after applying of relocations and of course
at the end of execution. If there is an error the linker stops and
returns non zero exit code.

If you found a serious problem and need to stop execution immediately
you can report fatal error. That causes calling of
`llvm::sys::RunInterruptHandlers();` and then `exit(1)`.

[[
    fatal(diag::fatal_cannot_read_input) << pInput.path();
]]

I think we can implement a similar approach in LLD.

On Mon, Jun 1, 2015 at 5:34 AM, Rui Ueyama <ruiu at google.com> wrote:
> The linker doesn't use error codes. All errors are fatal, and I think that's
> not going to change. The expected use case of error codes is to use this
> linker to link in-memory object files by passing command line options and
> memory buffer references. I don't know about exact use cases yet.
>
> I'll merge these categories together to make it simple. We can extend that
> later of we have to in future.
>
> 2015/05/31 午後4:23 "Rafael Espíndola" <rafael.espindola at gmail.com>:
>>
>> On 31 May 2015 at 19:05, Rui Ueyama <ruiu at google.com> wrote:
>> > ================
>> > Comment at: COFF/Error.h:21
>> > @@ +20,3 @@
>> > +// Driver errors
>> > +enum class DriverError { Success, InvalidOption };
>> > +
>> > ----------------
>> > rafael wrote:
>> >> I don't think you need Success. You can just use std::error_code(), no?
>> > Correct. I'll remove that.
>> >
>> > Does it make sense to merge all the error categories into one
>> > LLDErrorCategory and let the caller distinguish error type by its value?
>> > What do you think?
>>
>> I guess it depends on the common usage.
>>
>> The most common case I have seen so far is
>>
>> -----------------------------------------
>> if (EC == SomeParticularErrorToIgnore)
>>   return/continue;
>>
>> Report all other errors in an uniform way.
>> ---------------------------
>>
>> If that is the case, yes, it is probably better to have coarse categories.
>>
>> Thanks,
>> Rafael

-- 
Simon Atanasyan