aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java/com/google/devtools/build/lib/windows
Commit message (Collapse)AuthorAge
* Replace path implementation.Gravatar tomlu2018-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Path and PathFragment have been replaced with String-based implementations. They are pretty similar, but each method is dissimilar enough that I did not feel sharing code was appropriate. A summary of changes: PATH ==== * Subsumes LocalPath (deleted, its tests repurposed) * Use a simple string to back Path * Path instances are no longer interned; Reference equality will no longer work * Always normalized (same as before) * Some operations will now be slower, like instance compares (which were previously just a reference check) * Multiple identical paths will now consume more memory since they are not interned PATH FRAGMENT ============= * Use a simple string to back PathFragment * No more segment arrays with interned strings * Always normalized * Remove isNormalized * Replace some isNormalizied uses with containsUpLevelReferences() to check if path fragments try to escape their scope * To check if user input is normalized, supply static methods on PathFragment to validate the string before constructing a PathFragment * Because PathFragments are always normalized, we have to replace checks for literal "." from PathFragment#getPathString to PathFragment#getSafePathString. The latter returns "." for the empty string. * The previous implementation supported efficient segment semantics (segment count, iterating over segments). This is now expensive since we do longer have a segment array. ARTIFACT ======== * Remove Path instance. It is instead dynamically constructed on request. This is necessary to avoid this CL becoming a memory regression. RELNOTES: None PiperOrigin-RevId: 185062932
* Rename relativePath -> rootRelativePath in Root and friends.Gravatar tomlu2018-01-19
| | | | | | This makes it clearer that the path fragments in question are relative *to the root*. Confusingly, when the root is absolute, the root relative fragment is also absolute. This makes it a tiny bit clearer that the path fragment may be absolute. PiperOrigin-RevId: 182544893
* Introduce Root class.Gravatar tomlu2018-01-17
| | | | | | | | | | | This class represents a root (such as a package path or an output root) used for file lookups and artifacts. It is meant to be as opaque as possible in order to hide the user's environment from sky keys and sky functions. Roots are used by RootedPaths and ArtifactRoots. This CL attempts to make the minimum number of modifications necessary to change RootedPath and ArtifactRoot to use these fields. Deprecated methods and invasive accessors are permitted to minimise the risk of any observable changes. RELNOTES: None PiperOrigin-RevId: 182271759
* Automated rollback of commit 82e68b75304438c96ff878a0c2b8d18b42002486.Gravatar aehlig2017-12-19
| | | | | | | | | | | | | | Fixes #4322, #4306. *** Reason for rollback *** Introduces a deadlock (see https://github.com/bazelbuild/bazel/issues/4322) *** Original change description *** Make FileSystem operate on LocalPath instead of Path. PiperOrigin-RevId: 179549866
* Make FileSystem operate on LocalPath instead of Path.Gravatar tomlu2017-12-14
| | | | PiperOrigin-RevId: 179082062
* Move msys path support into DependencySet, removing it from the general Path ↵Gravatar tomlu2017-12-14
| | | | | | | | system. This is the only place that should actually need it. PiperOrigin-RevId: 179054861
* Add a new file path type, LocalPath.Gravatar tomlu2017-12-12
| | | | | | | | This path type is a local file path as a wrapper around a string. It works much the same as java.io.File, but without its file operations. For the most part, FilePath shouldn't add much overhead compared to using plain strings. Strings do get normalised on the way in, but no extra objects are allocated unless the path actually needs normalisation. PiperOrigin-RevId: 178798497
* Windows,Subcommands: argv quoting for empty argsGravatar Laszlo Csomor2017-11-14
| | | | | | | | | | | Quote empty args in the command argument vector otherwise the command's executable would not recognize them as arguments. Fixes https://github.com/bazelbuild/bazel/issues/3973 Change-Id: Iccfb59e75c748247c8df7d52fb8cf4227eae6fa7 PiperOrigin-RevId: 175672201
* Windows,JNI,logging: improve error messagesGravatar Laszlo Csomor2017-10-26
| | | | | | | | | | | | | | In this commit: - introduce the MakeErrorMessage function, which creates a structured error message with file and line information of the error's origin - update all error messages in the Windows JNI library - simplify GetLastErrorMessage to just convert an error code to string, without prepending a cause Change-Id: Ia8162bfdaee37d4b7ccb3a46d6c8a861b0a1bd94 PiperOrigin-RevId: 173402968
* Windows, jni: Don't close stdout/stderr in nativeWaitFor functionGravatar Yun Peng2017-10-24
| | | | | | | | | | | | | | | | | | | | | | | | These two close operations were added to work around #1708, but caused #2675. We found the root cause of the hanging problem in #1708 is a race condition when creating Windows processes: When Bazel trys to create two processes, one for a local command execution, one for starting the worker process. The worker process might accidentally inherits handles opened when creating the local command process, and it holds those handles as long as it lives. Therefore, ReadFile function hangs when handles for the write end of stdout/stderr pipes are released by the worker. The solution is to make Bazel native createProcess JNI function explicitly inheirts handles as needed, and use this function to start worker process. Related: http://support.microsoft.com/kb/315939 Fixed https://github.com/bazelbuild/bazel/issues/2675 Change-Id: I1c9b1ac3c9383ed2fd28ea92f528f19649693275 PiperOrigin-RevId: 173244832
* bep: Properly URI encode file pathsGravatar buchgr2017-09-14
| | | | | | RELNOTES: The Build Event Protocol's File.uri field is now properly encoded according to RFC2396. PiperOrigin-RevId: 168674865
* More BUILD file refactorings.Gravatar philwo2017-09-06
| | | | | | | | | Split collect, concurrent, vfs, windows into package-level BUILD files. Move clock classes out of "util", into their own Java package. Move CompactHashSet into its own Java package to break a dependency cycle. Give nestedset and inmemoryfs their own package-level BUILD files. PiperOrigin-RevId: 167702127
* Windows, JNI: move around sourcesGravatar Laszlo Csomor2017-07-03
| | | | | | | | | | | | | | | | | | | | | | | | Move the Java JNI sources to a separate package: c.g.devtools.build.lib.windows.jni and c.g.devtools.build.lib.windows.runfiles. Make the native method declarations private, create public wrapper methods for them that ensure that the JNI library is loaded. Split the C++ JNI source processes.cc into two parts (processes-jni.cc and file-jni.cc), extract common functionality to jni-util.{h,cc}. This change preparse the code for Android rule support on Windows, specifically it lets the Android BusyBox use the file JNI library so it can create junctions on Windows to work around long path issues when calling external tools. See https://github.com/bazelbuild/bazel/issues/3264 Change-Id: I7f1a746d73f822ae419d11b893a91f4eb45d64da PiperOrigin-RevId: 160643355
* Remove all imports of org.junit.Assert except for static imports of #fail().Gravatar lberki2017-06-01
| | | | | RELNOTES: None. PiperOrigin-RevId: 157685150
* Migrate all tests to Truth (except the ones in the examples).Gravatar lberki2017-05-31
| | | | | RELNOTES: None. PiperOrigin-RevId: 157576492
* Migrate most of the assertions to Truth that the auto-migration tool did not ↵Gravatar lberki2017-05-31
| | | | | | | | | catch. IntelliJ's "replace structurally" command was surprisingly useful. RELNOTES: None. PiperOrigin-RevId: 157463734
* Remove the last remaining public ctor from PathFragment.Gravatar nharmata2017-04-07
| | | | | RELNOTES: None PiperOrigin-RevId: 152400979
* PathFragment comparisons are now platform-aware Gravatar László Csomor2017-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | PathFragment's `equals`, `hashCode`, `compareTo`, `startsWith`, `endsWith`, and `relativeTo` are now aware of case-insensitivity when running on Windows. This approach is better than https://bazel-review.googlesource.com/c/9124/ because it preserves path casing, which is important when computing action output paths. This change contains two additional bugfixes: - `compareTo` now takes `driveLetter` into account - the `InMemoryFileSystem` in `PathWindowsTest` is not case-insensitive Fixes https://github.com/bazelbuild/bazel/issues/2613 -- Change-Id: I1a4250a373fff03fa02a6d8360457450b47a42a8 Reviewed-on: https://cr.bazel.build/9126 PiperOrigin-RevId: 149106930 MOS_MIGRATED_REVID=149106930
* Move UnixFileSystem to lib.unix, WindowsFileSystem to lib.windowsGravatar Ulf Adams2017-02-28
| | | | | | -- PiperOrigin-RevId: 148749485 MOS_MIGRATED_REVID=148749485
* Windows: use JNI CreateJunction in Java code Gravatar Laszlo Csomor2017-02-15
| | | | | | | | | | | | | | | | Use the new CreateJunction in the Windows JNI code every time we need to create junctions. This means updating WindowsFileOperations and related tests. Add test for WindowsFileSystem.createSymbolicLink. See https://github.com/bazelbuild/bazel/issues/2238 -- Change-Id: I5827e2e70e8e147f5f102fabf95fa9a148b3bcdc Reviewed-on: https://cr.bazel.build/8896 PiperOrigin-RevId: 147598107 MOS_MIGRATED_REVID=147598107
* Windows: fix off-by-one errors with MAX_PATHGravatar Laszlo Csomor2017-02-07
| | | | | | | | | | | | | | | | | | In almost every place we compared paths against MAX_PATH, we had it wrong. MAX_PATH is the null-terminated maximum length, so paths exactly MAX_PATH long (not counting the null-terminator) were incorrectly considered short. Also fix the error message in the MSVC python wrapper, because it reported an incorrect path length limit in the warning message. See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 146762382 MOS_MIGRATED_REVID=146762382
* Windows, JNI: make it work with long pathsGravatar Laszlo Csomor2017-01-16
| | | | | | | | | | | | | | When spawning a new process with CreateProcessA, convert argv0 to a 8dot3 style short path so we can support longer paths than MAX_PATH. This is the same approach we did in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144613589 MOS_MIGRATED_REVID=144613589
* Windows, JNI: arg for argv0 in nativeCreateProcessGravatar Laszlo Csomor2017-01-12
| | | | | | | | | | | | | | | | | | | Add a separate argument to nativeCreateProcess for argv[0] specifically, and another for the rest of the args. In a subsequent change I'll add code to compute the 8dot3 style short name of the argv[0] so we can use longer paths for executables in CreateProcessA than we normally could. This is the same approach as used in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144311562 MOS_MIGRATED_REVID=144311562
* Windows: remove test-specific JNI loaderGravatar Laszlo Csomor2017-01-12
| | | | | | | | | | WindowsJniLoader.loadJniForTesting is just a special case of what WindowsJniLoader.loadJni already does, so we can just use the latter. -- PiperOrigin-RevId: 144224388 MOS_MIGRATED_REVID=144224388
* Load JNI library on Windows from the runfiles tree as a fallbackGravatar Damien Martin-Guillerez2016-12-28
| | | | | | | | | | | | | | | | | This is the behavior of the UnixJniLoader. In order to do that, this change also moved the runfiles support on Windows in its own library that the WindowsJniLoader can use to load the JNI library from tests. Also add the JNI library on Windows to all test that use the JNI library on Unix. Fixes #2300. -- Change-Id: I2eb9207c3aa310d95912a48f64f676957c47cd34 Reviewed-on: https://cr.bazel.build/8045 PiperOrigin-RevId: 143114397 MOS_MIGRATED_REVID=143114397
* Windows, JNI: implement nativeGetLongPathGravatar Laszlo Csomor2016-12-15
| | | | | | | | | | | | | | | | | | | | Implement a JNI method that can resolve 8dot3 style paths. This is necessary because we need to be able to compare 8dot3 style paths and long paths [1], and because implementing this correctly in Java seems to be impossible [2]. This change also adds tests for the JNI isJunction implementation. See https://github.com/bazelbuild/bazel/issues/2101 [1] https://github.com/bazelbuild/bazel/issues/2145 [2] https://github.com/bazelbuild/bazel/issues/2145#issuecomment-266766716 -- PiperOrigin-RevId: 142123750 MOS_MIGRATED_REVID=142123750
* Windows JNI library: prepare for widechar WinAPIGravatar Laszlo Csomor2016-12-06
| | | | | | | | | | | | | | | | | | This change: - renames windows_error_handling.* to windows_util.* - moves most stuff except for the JNI method implementations into the new windows_util namespace - implements a jstring to wchar string converter - uses GetFileAttributesW in windows_file_operations.cc See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 141187291 MOS_MIGRATED_REVID=141187291
* Put stdout and stderr streams into a consistent state when they are redirected.Gravatar Lukacs Berki2016-09-12
| | | | | | | Fixes #1755. -- MOS_MIGRATED_REVID=132861187
* Windows: add a Java-native isJunction methodGravatar Laszlo Csomor2016-09-09
| | | | | | | | | | | | | | | | | Also add tests for WindowsFileSystem and some for WindowsFileOperations, so we test both the JNI-based and Java-native isJunction function, as well as handling of dangling symlinks/junctions. Having a Java-native version of this method means we don't need to use windows_jni.dll for any tests or for bootstrapping. This change could help with https://github.com/bazelbuild/bazel/issues/1735 -- MOS_MIGRATED_REVID=132556440
* Windows, tests: more refactoring in testsGravatar Laszlo Csomor2016-09-07
| | | | | | | | | Move more logic from FilesFileOperationsTest into WindowsTestUtil, and further separate test files in the BUILD file. -- MOS_MIGRATED_REVID=132417714
* Windows, tests: move code into WindowsTestUtilGravatar Laszlo Csomor2016-09-07
| | | | | | | | | | | | Additionally: - clean up the corresponding BUILD file a bit - add a comment to Path A subsequent change will add tests for WindowsFileSystem, then fix a bug there. -- MOS_MIGRATED_REVID=132408212
* Windows, JNI: implement native isJunction method.Gravatar Laszlo Csomor2016-09-06
| | | | | | | WindowsFileSystem.java does not yet use it. -- MOS_MIGRATED_REVID=132043739
* Implement timeouts on Windows.Gravatar Lukacs Berki2016-08-22
| | | | | | | Makes #1664 much less acute. -- MOS_MIGRATED_REVID=130750731
* Fix various breakages in Windows process handling that creeped in because we ↵Gravatar Lukacs T. Berki2016-07-20
| | | | | | | | | | | | | | weren't actually running the test: - Call TerminateProcess() only if the process handle is still open - Update the tests so that they expect a return value of 0 when reading a stream from a non-existent process Fixes #1538 . -- Change-Id: I4de28abbba2e2e89f285d7b8fb75bcd9af345f14 Reviewed-on: https://bazel-review.googlesource.com/4100 MOS_MIGRATED_REVID=127935621
* Fix capturing stdin/stdout on Windows.Gravatar Dmitry Lomov2016-07-11
| | | | | | | | | | | 1. Return EOF for streams representing Windows process pipes. 2. Fix the timing of process.close() 3. Un-synchronized reading of stderr and stdout. -- Change-Id: Iec98f45db9984be2c2b066962801cbd3ca60da3f Reviewed-on: https://bazel-review.googlesource.com/#/c/4000/ MOS_MIGRATED_REVID=126910063
* Fixed BazelDocumentationTests on Windows by using runfiles libraryGravatar Yun Peng2016-07-06
| | | | | | | -- Change-Id: Ic474eff981328b0a467606a01f88d72c26dfff74 Reviewed-on: https://bazel-review.googlesource.com/#/c/3965 MOS_MIGRATED_REVID=126636071
* Add an implementation for SubprocessFactory based on the new JNI interface ↵Gravatar Lukacs Berki2016-07-04
| | | | | | | | | | | to Windows process management. With this change, Bazel can build itself using native Windows process management and Ctrl-C works in server mode as expected. Yay! Flipping the flag will come in a separate change that's easy to roll back if need be. -- MOS_MIGRATED_REVID=126408264
* Add native process management for Windows and its Java bindings (without a ↵Gravatar Lukacs Berki2016-07-01
sane Java API for now) -- MOS_MIGRATED_REVID=126306559
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-03 03:48:09 +0000