search for: pathv2

...ame: solaris_limit.patch Type: application/octet-stream Size: 460 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110914/fa41d994/attachment.obj> -------------- next part -------------- — Sample failure for 2.9 build which is fixed: llvm[1]: Compiling PathV2.cpp for Debug build In file included from /export/home/jocke/2.9/llvm/lib/Support/PathV2.cpp:770:0: /export/home/jocke/2.9/llvm/lib/Support/Unix/PathV2.inc: In function ‘llvm::error_code llvm::sys::fs::unique_file(const llvm::Twine&, int&, llvm::SmallVectorImpl<char>&)’: /export/h...

...e local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >>> >>>> Pro: >>>> - only one interface for developers to learn on the project (no more >>>> PathV1 vs PathV2 vs FileManager) >>>> - only one implementation (per-platform) for easier maintenance of the >>>> file system platform abstraction >>>> - one point to insert synchronization guarantees for tools / IDE >>>> integration that wants to run clang in multipl...

...tem." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >>>> >>>>> Pro: >>>>> - only one interface for developers to learn on the project (no more >>>>> PathV1 vs PathV2 vs FileManager) >>>>> - only one implementation (per-platform) for easier maintenance of the >>>>> file system platform abstraction >>>>> - one point to insert synchronization guarantees for tools / IDE >>>>> integration that wants to run...

...leManager/SourceManager dance used to provide in-memory content for a > (virtual or old) file is quite the mess. > >>>> > >>>>> Pro: > >>>>> - only one interface for developers to learn on the project (no more > >>>>> PathV1 vs PathV2 vs FileManager) > >>>>> - only one implementation (per-platform) for easier maintenance of > the > >>>>> file system platform abstraction > >>>>> - one point to insert synchronization guarantees for tools / IDE > >>>>> integ...

...urrent FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >>>>> >>>>>> Pro: >>>>>> - only one interface for developers to learn on the project (no more >>>>>> PathV1 vs PathV2 vs FileManager) >>>>>> - only one implementation (per-platform) for easier maintenance of the >>>>>> file system platform abstraction >>>>>> - one point to insert synchronization guarantees for tools / IDE >>>>>> integration th...

...ab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >> >>> Pro: >>> - only one interface for developers to learn on the project (no more >>> PathV1 vs PathV2 vs FileManager) >>> - only one implementation (per-platform) for easier maintenance of the >>> file system platform abstraction >>> - one point to insert synchronization guarantees for tools / IDE >>> integration that wants to run clang in multiple threads at onc...

...simply "grab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. > >> Pro: >> - only one interface for developers to learn on the project (no more >> PathV1 vs PathV2 vs FileManager) >> - only one implementation (per-platform) for easier maintenance of the >> file system platform abstraction >> - one point to insert synchronization guarantees for tools / IDE >> integration that wants to run clang in multiple threads at once (for >>...

On Jun 24, 2013, at 4:18 PM, Stefan Teleman <stefan.teleman at gmail.com> wrote: > I'll file the bug about the endian stuff, but we'll also have to have > an <endian.h> in Solaris as well. Do you still have issues after r182419? commit 01ef4f6982451e6a7c00a713d9ae677d3a15d042 Author: Jakob Stoklund Olesen <stoklund at 2pi.dk> Date: Tue May 21 13:36:13 2013

On Mon, Jun 24, 2013 at 6:17 PM, Jorge Rodrigues <skeept at gmail.com> wrote: > Norm, > > thanks for the help. Applying the fix solves the issue I mentioned but now I > have more issues. > > I can install clang, but when running I cannot compile and link files. > If I compile with -c flag it works but compiling the following x.c file > gives an error: >

...search tries to access the file system driectly in rather brittle ways, relying on implementation details and #ifdefs. So why not make FileManager a more principled (and still blazing fast) file system abstraction? Pro: - only one interface for developers to learn on the project (no more PathV1 vs PathV2 vs FileManager) - only one implementation (per-platform) for easier maintenance of the file system platform abstraction - one point to insert synchronization guarantees for tools / IDE integration that wants to run clang in multiple threads at once (for example when re-indexing on 12-ht-core machin...

...ab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >> >>> Pro: >>> - only one interface for developers to learn on the project (no more >>> PathV1 vs PathV2 vs FileManager) >>> - only one implementation (per-platform) for easier maintenance of the >>> file system platform abstraction >>> - one point to insert synchronization guarantees for tools / IDE >>> integration that wants to run clang in multiple threads at onc...

...local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >>> >>>> Pro: >>>> - only one interface for developers to learn on the project (no more >>>> PathV1 vs PathV2 vs FileManager) >>>> - only one implementation (per-platform) for easier maintenance of the >>>> file system platform abstraction >>>> - one point to insert synchronization guarantees for tools / IDE >>>> integration that wants to run clang in multipl...

...that aren't simply "grab stuff from the local file system." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. > Pro: > - only one interface for developers to learn on the project (no more > PathV1 vs PathV2 vs FileManager) > - only one implementation (per-platform) for easier maintenance of the > file system platform abstraction > - one point to insert synchronization guarantees for tools / IDE > integration that wants to run clang in multiple threads at once (for > example when re-inde...

This is a proposed patch to enhance FileSystem.h to add functionality (getting and setting permission bits and mapping an unmapping files). This implementation follows the N3365 proposal regarding permission bits. This functionality is needed for my next patch which will implement llvm/include/Support/FileOutputBuffer.h which is needed by lld. -------------- next part -------------- A

On Fri, May 18, 2012 at 3:07 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> +  error_code ec = sys::fs::status(filePathTwine, stat); > > stat is undefined if ec isn't success. ec will be success even in the case of > file_not_found. Actually I was wrong. The Windows and UNIX implementation disagree on this point. I'm going to change it to match

...tem." The current FileManager/SourceManager dance used to provide in-memory content for a (virtual or old) file is quite the mess. >>>> >>>>> Pro: >>>>> - only one interface for developers to learn on the project (no more >>>>> PathV1 vs PathV2 vs FileManager) >>>>> - only one implementation (per-platform) for easier maintenance of the >>>>> file system platform abstraction >>>>> - one point to insert synchronization guarantees for tools / IDE >>>>> integration that wants to run...

...> driectly in rather brittle ways, relying on implementation details and > #ifdefs. > > So why not make FileManager a more principled (and still blazing fast) > file system abstraction? > Pro: > - only one interface for developers to learn on the project (no more > PathV1 vs PathV2 vs FileManager) > - only one implementation (per-platform) for easier maintenance of the > file system platform abstraction > - one point to insert synchronization guarantees for tools / IDE > integration that wants to run clang in multiple threads at once (for > example when re-inde...

...ntation details and >>> #ifdefs. >>> >>> So why not make FileManager a more principled (and still blazing fast) >>> file system abstraction? >>> Pro: >>> - only one interface for developers to learn on the project (no more >>> PathV1 vs PathV2 vs FileManager) >>> - only one implementation (per-platform) for easier maintenance of the >>> file system platform abstraction >>> - one point to insert synchronization guarantees for tools / IDE >>> integration that wants to run clang in multiple threads at onc...

...Android headers don't define the relevant system call number and it varies between platforms). Right now the only part of LLVM that uses this function is llvm-ar, so it's not as if lack of support for this function is a serious shortcoming. I don't really know the history of PathV1/PathV2 but I think the simplest solutions are: 1. Have setLastModificationAndAccessTime fail on platforms without futimes/futimens (by ENOSYS). This is pretty ugly because having a function which can never succeed seems likely to confuse users. 2. Only declare setLastModificationAndAccessTime...

...le is distributed under the University of Illinois Open Source > +// License. See LICENSE.TXT for details. > +// > +//===----------------------------------------------------------------------===// > + > +#include "llvm/Support/FileSystem.h" > +#include "llvm/Support/PathV2.h" > +#include "llvm/Support/ErrorHandling.h" > +#include "llvm/Support/raw_ostream.h" > +#include "llvm/Support/FileOutputBuffer.h" > +#include "llvm/ADT/OwningPtr.h" > + > +#include "gtest/gtest.h" > + > +using namespa...