search for: erroror

On Nov 21, 2013, at 4:07 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 3:57 PM, Nick Kledzik <kledzik at apple.com> wrote: > Michael, > > In lld, we have places that used nested a ErrorOr<std::unique_ptr<xx>> and I often hit compiler errors that require breaking up expressions to work around. Do you have suggestions on how to code the following simple examples to not error? Can some of these be fixed in ErrorOr.h? Or am I totally not getting something? > > -Ni...

Michael, In lld, we have places that used nested a ErrorOr<std::unique_ptr<xx>> and I often hit compiler errors that require breaking up expressions to work around. Do you have suggestions on how to code the following simple examples to not error? Can some of these be fixed in ErrorOr.h? Or am I totally not getting something? -Nick struc...

On Thu, Nov 21, 2013 at 3:57 PM, Nick Kledzik <kledzik at apple.com> wrote: > Michael, > > In lld, we have places that used nested a ErrorOr<std::unique_ptr<xx>> and > I often hit compiler errors that require breaking up expressions to work > around. Do you have suggestions on how to code the following simple > examples to not error? Can some of these be fixed in ErrorOr.h? Or am I > totally not getting somet...

...ple.com> wrote: > > On Nov 21, 2013, at 4:07 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > > On Thu, Nov 21, 2013 at 3:57 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> Michael, >> >> In lld, we have places that used nested a ErrorOr<std::unique_ptr<xx>> >> and I often hit compiler errors that require breaking up expressions to >> work around. Do you have suggestions on how to code the following simple >> examples to not error? Can some of these be fixed in ErrorOr.h? Or am I >> totally n...

> I like this idea in general. It's a better implementation of what > ErrorOr originally was before we removed the custom error support > because it wasn't used. In fact I would actually support outright > replacing ErrorOr with this if it can be done safely, as I find the > name TypedErrorOr a bit long. The main differences are * This will hopefully be used....

Hi Michael, Rafael, Pawel, Apologies for the delayed reply - I was out on vacation last week. > In fact I would actually support outright > replacing ErrorOr with this if it can be done safely, as I find the > name TypedErrorOr a bit long. I find the name awkward too. I'll leave these classes as TypedError and TypedErrorOr<T> when I submit the initial patch to llvm-commits, but please feel free to comment on the names in that review. If th...

Hey there, lld fails to build on Visual Studio 2013 because of ErrorOr<void>. For example, ErrorOr<void> is used in InputGraph.h as the return type of InputGraph::reset. Inside of ErrorOr, there is: typedef typename remove_reference<T>::type &reference As T is void, and remove_reference <T>::type results in void, the typedef expands to: typ...

Sometime this week, the following test started failing: FAIL: LLVM-Unit :: Support/Release+Asserts/SupportTests/ErrorOr.Comparison (21978 of 22229) ******************** TEST 'LLVM-Unit :: Support/Release+Asserts/SupportTests/ErrorOr.Comparison' FAILED ******************** Note: Google Test filter = ErrorOr.Comparison [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [...

I think I removed all uses of ErrorOr<void>. Can you try updating? On 15 November 2013 12:09, Daniel Albuschat <d.albuschat at gmail.com> wrote: > Hey there, > > lld fails to build on Visual Studio 2013 because of ErrorOr<void>. > For example, ErrorOr<void> is used in InputGraph.h as the return type...

...ject calls report_fatal_error() far too often, both when we're (a) just constructing the specific implementation of ObjectFile, and (b) when we access its contents and find out the file is broken and can't be parsed properly. We should just go and fix (a): ObjectFile factory methods return ErrorOr<std::unique_ptr<ObjectFile>>, and we should propagate the error appropriately. (b) is harder. The current approach is to use std::error_code as a return type, and store the result in by-reference argument, for instance: std::error_code getSymbolAddress(DataRefImpl Symbol, uint64_t &a...

Hello, this is a call for feedback: opinions, improvements, testers.. I use the support classes Expected<T> and ErrorOr<T> quite often recently and I like the concept a lot! Thanks Lang btw! However, from time to time I found issues in the execution paths of my error cases and got annoyed by their naturally low test coverage. So I started sketching a test that runs all error paths for a given piece of code to...

...t I think (typing on a phone) that relocations are another case where the best is to have a more specific api: the only way the relocation is invalid from the perspective of the api we provide is if the symbol index is invalid. We can just return symbol_end for that and avoid the error_code and the ErrorOr. Cheers, Rafael On Jun 1, 2015 6:19 PM, "Lang Hames" <lhames at gmail.com> wrote: > Out of interest, what parts of an object file commonly don't get mapped in > by the linker? I'd have assumed linkers would usually end up touching just > about everything. > &gt...

...() far too often, both when > we're (a) just constructing the specific implementation of ObjectFile, and > (b) when we access its contents and find out the file is broken and can't be > parsed properly. > > We should just go and fix (a): ObjectFile factory methods return > ErrorOr<std::unique_ptr<ObjectFile>>, and we should propagate the error > appropriately. > > (b) is harder. The current approach is to use std::error_code as a return > type, and store the result in by-reference argument, for instance: > std::error_code getSymbolAddress(DataRef...

...9;m currently using MSVC 2012, but I saw that Alp Toker landed a patch to LLD to make it compile with MSVC 2013, so I believe it's doable. Update and try again. On Fri, Nov 15, 2013 at 11:49 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > I think I removed all uses of ErrorOr<void>. Can you try updating? > > On 15 November 2013 12:09, Daniel Albuschat <d.albuschat at gmail.com> wrote: > > Hey there, > > > > lld fails to build on Visual Studio 2013 because of ErrorOr<void>. > > For example, ErrorOr<void> is used in In...

...() far too often, both when > we're (a) just constructing the specific implementation of ObjectFile, and > (b) when we access its contents and find out the file is broken and can't > be parsed properly. > > We should just go and fix (a): ObjectFile factory methods return > ErrorOr<std::unique_ptr<ObjectFile>>, and we should propagate the error > appropriately. > > (b) is harder. The current approach is to use std::error_code as a return > type, and store the result in by-reference argument, for instance: > std::error_code getSymbolAddress(DataRef...

...> On Thu, Jul 27, 2017 at 5:10 AM Stefan Gränitz via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hello, this is a call for feedback: opinions, improvements, testers.. > > I use the support classes Expected<T> and ErrorOr<T> quite often > recently and I like the concept a lot! Thanks Lang btw! > However, from time to time I found issues in the execution paths of my > error cases and got annoyed by their naturally low test coverage. > > So I started sketching a test that runs all...

...thought it should be varargs. > Also, parse can just return an error that > specifies the format is wrong. It would still need to call the LinkingContext to figure out if the format is associated with the target. > Specifically this would be a good place to use the user data part of > ErrorOr to specify what was expected and what was received. Couldnt follow this. Can you elaborate ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

...ude "backened.h" #include <iostream> #include "llvm/Bitcode/BitcodeReader.h" #include "llvm/IR/Function.h" #include "llvm/IR/LLVMContext.h" #include "llvm/IR/Module.h" #include "llvm/Support/CommandLine.h" #include "llvm/Support/ErrorOr.h" #include "llvm/Support/MemoryBuffer.h" #include "llvm/Support/raw_ostream.h" #include "llvm/IR/PassManager.h" #include "llvm/CodeGen/Passes.h" #include "llvm/IR/DataLayout.h" #include <llvm/Transforms/Scalar.h> #include "llvm/IR/L...

...se can just return an error that >> specifies the format is wrong. >> > It would still need to call the LinkingContext to figure out if the format > is associated with the target. Exactly. > > Specifically this would be a good place to use the user data part of >> ErrorOr to specify what was expected and what was received. >> > Couldnt follow this. Can you elaborate ? ErrorOr supports user data. See unittests/Support/ErrorOrTest.cpp. It would simply be: return ArchMismatch(expected, actual); Then an error handler higher up can extract that to form a pro...

...! to avoid gaining indentation, but still, I think that if most uses of an API will require immediately negating the return value, then maybe the sense should be inverted. > > > Mapping success/error onto a bool will always be ambiguous. Is there some better pattern? Perhaps returning ErrorOr<void> instead of a bool would make it clearer. In practice that would mean a ! in the if statement, which runs counter to your strawman that if every client uses ! that the sense should be flipped, e.g.: if (!parse(xx)) // handle error or that test for error could be made obvious...