similar to: [LLVMdev] lld fails to build on Visual Studio 2013

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 > of InputGraph::reset. > Inside of ErrorOr, there is:

I'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

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 struct Foo { void doit(); };

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

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

On Thu, Nov 21, 2013 at 4:33 PM, Nick Kledzik <kledzik at apple.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

2013/10/31 Daniel Albuschat <d.albuschat at gmail.com>: > on the lld main page at http://lld.llvm.org, it says: > > "lld is in its early stages of development. > It can currently self host on Linux x86-64 with -static." > > Is this information up-to-date? I made a quick test on a Windows 8 64bit system: test.c: int main () { return 42; } > clang -c test.c

On Sep 4, 2013, at 9:28 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > These are the below modifications needed in lld to start processing groups :- > > 1) LinkerInput would be moved to FileNode that contains the following functions > - getBuffer > - takeBuffer > - getPath > > 2) The driver will process the vector of

Hi Nick, These are the below modifications needed in lld to start processing groups :- 1) LinkerInput would be moved to FileNode that contains the following functions - getBuffer - takeBuffer - getPath 2) The driver will process the vector of InputElements and call /*process */on each of them. process() would create a lld::File object within the InputElement if its a

On Sep 4, 2013, at 2:32 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 9/4/2013 4:04 PM, Nick Kledzik wrote: >> I do think we have too many classes. > Agree. >> I thought InputGraph was going to replace InputFiles. > Interesting idea. >> It seems link LinkerInput could be merged into FileNode. > Agree. >> >> Originally InputFiles

I do think we have too many classes. I thought InputGraph was going to replace InputFiles. It seems link LinkerInput could be merged into FileNode. Originally InputFiles was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the methods forEachInitalAtom() and searchLibraries() then we could get rid of InputFiles and have the Resolver uses InputGraph

On Wed, Sep 4, 2013 at 2:04 PM, Nick Kledzik <kledzik at apple.com> wrote: > I do think we have too many classes. I thought InputGraph was going to > replace InputFiles. It seems link LinkerInput could be merged into > FileNode. > > Originally InputFiles was the abstract interface that he Resolver used to > see all the inputs. If InputGraph supported the methods >

Hi Nick, On 9/4/2013 4:04 PM, Nick Kledzik wrote: > I do think we have too many classes. Agree. > I thought InputGraph was going to replace InputFiles. Interesting idea. > It seems link LinkerInput could be merged into FileNode. Agree. > > Originally InputFiles was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the methods

IRBuilder is a templated class, and one of the template arguments is the constant folder to use. By default it uses the ConstantFolder class which does target-independant constant folding. If you want to disable constant folding you can specify the NoFolder class instead, i.e. declare the builder as follows: IRBuilder<true, llvm::NoFolder> builder(body) On 26 Nov 2013, at 19:23, Daniel

Hello list, on the lld main page at http://lld.llvm.org, it says: "lld is in its early stages of development. It can currently self host on Linux x86-64 with -static." Is this information up-to-date? I'm interested in using lld on Windows (win32 on PC) with object files created by llvm (no clang involved). Is that possible at this time? It would be awesome to be able to create a

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,

Shankar, I think your proposal and mine are pretty much the same. The difference is passing back info to the InputGraph as a parameter in nextFile() vs as a separate method call. My original draft email had a parameter in nextFile(), but it seemed a little confusing because the information was referring to the previous file. That is, if the current resolver state has newDefinedAtoms, that

> 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. *

On Sep 20, 2013, at 3:37 PM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Sep 20, 2013 at 3:29 PM, Nick Kledzik <kledzik at apple.com> wrote: > Rui, > > I like this in general, but have a few questions. > > On Sep 20, 2013, at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote: > >> 2. We would instead add a new method nextFile() to LinkingContext,

Hi, With the inputGraph now, lld models command line options, input files as nodes in the InputGraph called InputElements. In the current approach, each InputElement is converted to a LinkerInput, which works if all lld deals with individual files. Dealing with ControlNodes (Groups), have a problem with it, on how to model that as a LinkerInput. Joerg/Me were chatting on the IRC about this