[DirectoryWatcher] Do not use FSEvents on non-macOS platformsThe FSEvents APIs are available on iOS6+: however, the DirectoryWatchercode isn't wired up to really use FSEvents on embedded platforms
[DirectoryWatcher] Do not use FSEvents on non-macOS platformsThe FSEvents APIs are available on iOS6+: however, the DirectoryWatchercode isn't wired up to really use FSEvents on embedded platforms.I've duplicated code from DirectoryWatcher-not-implemented.cpp here andused TargetConditionals instead of adding cmakery to check try_compile;I couldn't get that to work properly.
show more ...
[DirectoryWatcher] Fix misuse of FSEvents API and data raceI observed two bugs in the DirectoryWatcher on macOS1. We were calling FSEventStreamStop and FSEventStreamInvalidate beforewe called FS
[DirectoryWatcher] Fix misuse of FSEvents API and data raceI observed two bugs in the DirectoryWatcher on macOS1. We were calling FSEventStreamStop and FSEventStreamInvalidate beforewe called FSEventStreamStart and FSEventStreamSetDispatchQueue, if theDirectoryWatcher was destroyed before the initial async work was done.This violates the requirements of the FSEvents API.2. Calls to Receiver could race between the initial work and theinvalidation during destruction.The second issue is easier to see when using TSan.Differential Revision: https://reviews.llvm.org/D74371rdar://59215667
Fix another implicit conversion in the directory watcher
Fix more implicit conversions
[Clang] Migrate llvm::make_unique to std::make_uniqueNow that we've moved to C++14, we no longer need the llvm::make_uniqueimplementation from STLExtras.h. This patch is a mechanical replacemento
[Clang] Migrate llvm::make_unique to std::make_uniqueNow that we've moved to C++14, we no longer need the llvm::make_uniqueimplementation from STLExtras.h. This patch is a mechanical replacementof (hopefully) all the llvm::make_unique instances across the monorepo.Differential revision: https://reviews.llvm.org/D66259llvm-svn: 368942
[clang][DirectoryWatcher][NFC] Swapping asserts for llvm fatal_error in createI also have replaced all the instances of"auto DW = DirectoryWatcher::create" withllvm::Expected<std::unique_ptr<Dire
[clang][DirectoryWatcher][NFC] Swapping asserts for llvm fatal_error in createI also have replaced all the instances of"auto DW = DirectoryWatcher::create" withllvm::Expected<std::unique_ptr<DirectoryWatcher>> DW = DirectoryWatcher::createto make it more clear that DirectoryWatcher::create is returning an Expected.I've also allowed for logAllUnhandledErrors to consume errors in the case wereDirectoryWatcher::create produces them.Differential Revision: https://reviews.llvm.org/D65829llvm-svn: 368108
[DirectoryWatcher] Fix asserts Mac buildsAdd a missing semicolon after an assert. Remove the period from theassert message while I'm here, because we don't usually have those.llvm-svn: 367984
[clang][DirectoryWatcher] Adding llvm::Expected error handling to create.Prior to this patch Unix style errno error reporting from the inotify layer wasused by DirectoryWatcher::create to simply r
[clang][DirectoryWatcher] Adding llvm::Expected error handling to create.Prior to this patch Unix style errno error reporting from the inotify layer wasused by DirectoryWatcher::create to simply return a nullptr on error. Thiswould generally be ok, except that in LLVM we have much more robust errorreporting through the facilities of llvm::Expected.The other critical thing I stumbled across was that the unit tests forDirectoryWatcher were not failing abruptly when inotify_init() was reporting anerror, but would continue with the testing and eventually hit a deadlock in apathological machine state (ie in the unit test, the return nullptr on ::createwas ignored).Generally this pathological state never happens on any build bot, so it istotally understandable that it was overlooked, but on a Linux desktop runninga dubious desktop environment (which I will not name) there is a chance thatsaid desktop environment could use up enough inotify instances to exceed theuser's limit. These are the conditions that led me to hit the deadlock I amaddressing in this patch with more robust error handling.With the new llvm::Expected error handling when your system runs out of inotifyinstances for your user, the unit test will be forced to handle the error orcrash and report the issue to the user instead of weirdly deadlocking on acondition variable wait.Differential Revision: https://reviews.llvm.org/D65704llvm-svn: 367979
[DirectoryWatcher] Relax assumption to prevent test flakinessllvm-svn: 367632
Reland [clang] DirectoryWatcherThis reverts commit f561227d133224d2d6a5a016abe4be051fa75501.- DirectoryWatcher- Fix the build for platforms that don't have DW implementated.- Fix the threading
Reland [clang] DirectoryWatcherThis reverts commit f561227d133224d2d6a5a016abe4be051fa75501.- DirectoryWatcher- Fix the build for platforms that don't have DW implementated.- Fix the threading dependencies (thanks to compnerd).llvm-svn: 365954
Revert "Reland [clang] DirectoryWatcher"This reverts commit fdcb7f47e783933e0af8a5fae91132269a208268.llvm-svn: 365948
Reland [clang] DirectoryWatcherThis reverts commit abce8c457dd3de6b156756e547cc0eefb7653c79.+ Fix the build for platforms that don't have DW implementated.llvm-svn: 365947
Revert [clang] DirectoryWatcherThis reverts r365574 (git commit 31babea94a3ed38a140540f2252cf043dacec1f7)llvm-svn: 365581
[clang] DirectoryWatcherAsynchronously monitors specified directory for changes and passes notifications to provided callback.Dependency for index-while-building.Differential Revision: https://
[clang] DirectoryWatcherAsynchronously monitors specified directory for changes and passes notifications to provided callback.Dependency for index-while-building.Differential Revision: https://reviews.llvm.org/D58418llvm-svn: 365574