search for: pathv1

...y "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 thre...

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

...l 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 wan...

...uot; 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 >>>>>> inte...

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

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

...would do bad thing, thank you. dir = GetTemporaryDirectory(); dir.eraseFromDisk(erase_contents = true); dir = GetTemporaryDirectory(); /* It doesn't create anything on Win32 due to caching */ I suppose Manuel wants GetTemporaryDirectory() to keep semantics similar mkdtemp(3). Though it is in PathV1, could we fix? ...Takumi 2012/5/29 Manuel Klimek <klimek at google.com>: > Additionally, from looking at the PathV1.h comments, it looks like the > Windows version actually violates the contract "@brief Construct a path to > an new, unique, existing temporary directory."...

...he header 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-c...

...plications 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 wh...

...y "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 thre...

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

...l 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 wan...

...le 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 wh...

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

...hat the 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 setLastModificationAndAcce...

Nikola, Your patchset does not work; e>bin\clang.exe -S なかむら\たくみ.c error: error reading '邵コ・ェ邵コ荵昴・郢ァ蝎らクコ貅假ソ・邵コ・ソ.c' 1 error generated. - Would it be not enough in somewhere? I suspect clang still might be pathv1-dependent. (I guess, pathv1 would assume ansi) - raw_ostream does not handle utf8, but ansi, on win32. I would like to propose; - converting utf8 and utf16 may move to llvm/lib/Support. - we may get rid of CP_UTF8 with Win32 API. It must be trivial. ps. excuse me, I might respond you m...

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

AFAIK Clang internals do assume utf8, and llvm::sys::path converts strings to utf16 on windows and calls W API functions. If somebody would like to take a look at my changes and comment on them. Here's a brief explanation of what I did: - Convert argv to utf8 using current system locale for win32 (this is done as soon as possible inside ExpandArgv). This makes the driver happy since calls to

...rs 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 decl...

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