aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/native
Commit message (Collapse)AuthorAge
* Windows,JNI: graceful error-handlingGravatar Laszlo Csomor2018-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CreateJunction and DeletePath are now more resilient to errors: - CreateJunction opens the junction path to check its target requesting fewer rights and with greater sharing permission. This way it can check junction targets even if the junction name is opened by another process with no sharing. - DeletePath attempts to call FindFirstFileW if GetFileAttributesW fails with ERROR_ACCESS_DENIED. There's hardly any info about this error mode online, except for a code comment in the .NET CoreFX library. (See new code comments in this commit.) Also: - Change the error codes for DeletePath. - Wrap the DeletPath error codes in a struct for better readability. Fixes https://github.com/bazelbuild/bazel/issues/5433 Change-Id: I5b6e0f27b5b22c1cf00da90104495eda84178283 Closes #5590. Change-Id: I5b6e0f27b5b22c1cf00da90104495eda84178283 PiperOrigin-RevId: 204438994
* Windows,JNI: more robust nativeCreateJunctionGravatar Laszlo Csomor2018-07-09
| | | | | | | | | | | | | | | | | | | | | | | | Rewrite the CreateJunction function in the Windows JNI library. The new implementation's improvements: - succeeds if the junction already exists with the desired target; hopefully this will fix issue https://github.com/bazelbuild/bazel/issues/5433 - tolerant to concurrent filesystem modifications, e.g. if the junction's path suddenly disappears, the function reports the error correctly Fixes https://github.com/bazelbuild/bazel/issues/5433 Change-Id: I58a2314a00f6edaa7c36c35ba54616168b44eb7d Closes #5528. Change-Id: I9f5dc9237b70a433d0d8c2578a826de3d462d110 PiperOrigin-RevId: 203744515
* Windows,JNI: implement native DeletePath methodGravatar laszlocsomor2018-07-06
| | | | | | | | | | | | | | | | | | Implement a native DeletePath method that can delete files, directories, and junctions. The method should tolerate when concurrent processes delete the file. The new JNI function is more robust than Java IO file deletion function because it can also delete readonly files. See https://github.com/bazelbuild/bazel/issues/5513 Closes #5520. Change-Id: I21ea36dd64960b294e2b51600273bf4290ad7c0f PiperOrigin-RevId: 203448581
* Remove usage of COMPILER_MSVC in Bazel and ijarGravatar Loo Rong Jie2018-06-11
| | | | | | | | | | | | | Convert most `COMPILER_MSVC` to `_WIN32` (as they apply to Windows platform, not MSVC compiler). Only `src/tools/singlejar/zip_headers.h` and `src/main/cpp/util/md5.h` actually need `_MSC_VER`. `COMPILER_MSVC` in `third_party/protobuf` are not removed. They can be fixed by updating dependency to newer version. /cc @meteorcloudy Closes #5350. Change-Id: Ibc131abfaf34a0cb2bd338549983ea9d28eaabfe PiperOrigin-RevId: 200019793
* Add dependency on googletest, so we can use gmock along with gtest.Gravatar ccalvarin2018-03-23
| | | | | | | third_party/gtest can go away after this. RELNOTES: None. PiperOrigin-RevId: 190221581
* Clean up Windows config_settingsGravatar Yun Peng2018-01-12
| | | | | | | | | | | | | | 1.Deleted config_setting for --cpu=x64_windows_msys, because we don't build Bazel with MSYS gcc anymore. 2.Deleted config_setting for --cpu=x64_windows_msvc, because it uses exactly the same toolchain as --cpu=x64_windows, it'll be removed in the future. This change reduces the complexity of our BUILD files and make them less confusing. Change-Id: I939831a6861413b0f745fb1be98aacd4fb780e0a PiperOrigin-RevId: 181751853
* Move bazel conditions into src/conditions.Gravatar tomlu2017-11-30
| | | | | | | This will enable an easier transition from checked-in BUILD files to ones generated by copybara. RELNOTES: None PiperOrigin-RevId: 177514519
* 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: use wstrings onlyGravatar Laszlo Csomor2017-10-20
| | | | | | | | | | | | | | | | | | | | In this commit: - fix the Windows JNI library to only use UTF-16 strings Converting between multi-byte strings (UTF-8) and wstrings (UTF-16) always carries the risk of incorrectly handling the strings. It also takes time, even if not much. Not converting the strings but using the raw Java strings (which are in fact UTF-16 strings) simplifies the code and allows using non-ASCII paths (at least in the JNI module, even if Bazel as a whole doesn't support non-ASCII characters). Change-Id: I827fbe92a1bbefac049a1e34ac1738c965ed2e9c PiperOrigin-RevId: 172715277
* CI,windows: create test_suites for Windows testsGravatar L?szl? Csomor2017-09-19
| | | | | | | | | | | | | | | Add recursive test_suite rules for all tests that ci.bazel.io runs for Windows, and set the top-level test_suite as the CI test target. Doing so shortens the command line and works around https://github.com/bazelbuild/bazel/issues/3742 I verified that the old set of tests are the same as the new set. Change-Id: Id8d5da3f0c03c9b8969a9f8e1e9a3096888365aa PiperOrigin-RevId: 169242858
* Windows, JNI: move around sourcesGravatar Laszlo Csomor2017-06-29
| | | | | | | | | | | | | | | | Move the Windows JNI C++ sources to a separate package and separate namespace. This no-op refactoring allows other build rules than Bazel's client library to depend on file I/O and/or JNI functionality. A follow-up commit will split the //src/main/native/windows:processes library into :jni-processes and :jni-file. Change-Id: I33c5f8ebd8961cc440db3b4a95ff78024d7c1d74 PiperOrigin-RevId: 160404298
* Fix //src/test/native:windows_jni_test on WindowsGravatar Yun Peng2017-03-09
| | | | | | | | -- Change-Id: I35f2ce0e8c50f4167c783d5e4b9f60417e2b0aa1 Reviewed-on: https://cr.bazel.build/9312 PiperOrigin-RevId: 149647513 MOS_MIGRATED_REVID=149647513
* Make Bazel build with MSVC-default-toolchain Bazel Gravatar Yun Peng2017-03-08
| | | | | | | | | | | | | After this change, a msys bazel can be built with a MSVC-default Bazel by adding --cpu=x64_windows_msys --host=x64_windows_msys See https://github.com/bazelbuild/bazel/issues/2627 -- Change-Id: Iaa82bf4dd911c5740b98d3b2739dfccca6203f79 Reviewed-on: https://cr.bazel.build/9293 PiperOrigin-RevId: 149532274 MOS_MIGRATED_REVID=149532274
* Bazel client, JNI, Windows: impl. CreateJunction Gravatar Laszlo Csomor2017-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Implement a CreateJunction function in the Windows JNI library. Also move a bit of code from file_windows to the JNI library, where it is (also) needed. This implementation is an improved version of `blaze_util::SymlinkDirectories` in blaze_util_windows: this version handles Windows paths as `name` and `target`, and performs more validation (e.g. on the length of `target`), plus has more comments explaining the logic. In a subsequent change I'll start using this new function in blaze_util_windows. This method will also be helpful in tests: we will no longer have to shell out to mklink. See https://github.com/bazelbuild/bazel/issues/2107 -- Change-Id: I7e9b085fdc2ba47be83da5319bded02bd323e71b Reviewed-on: https://cr.bazel.build/8892 PiperOrigin-RevId: 147585207 MOS_MIGRATED_REVID=147585207
* Windows JNI: refactoringsGravatar Laszlo Csomor2017-01-19
| | | | | | | | | | | | | | | | | | | In this change: - rename //src/main/native:windows_jni_utils to //src/main/native:windows_jni_lib and make it visible to //src/main/cpp:__subpackages__ because we will use some methods there from this library - move AutoHandle into windows_util.h, we'll use it from blaze_util_windows.cc / file_windows.cc later See https://github.com/bazelbuild/bazel/issues/2107 -- PiperOrigin-RevId: 144946842 MOS_MIGRATED_REVID=144946842
* Tests: empty windows_util_test on other platformsGravatar Laszlo Csomor2017-01-18
| | | | | | | | | | | | //src/test/native:windows_util_test now has a dummy source file on platforms other than Windows. This allows continuous integration to run all tests in this package on any platform. -- PiperOrigin-RevId: 144834522 MOS_MIGRATED_REVID=144834522
* Windows, JNI: add tests for windows_utilGravatar Laszlo Csomor2017-01-18
Add tests for the AsExecutablePathForCreateProcess method, since its logic is pretty complex. Unfortunately testing it also requires complex logic, as we need to test what exactly happens when the input path is shorter than MAX_PATH or when it's longer than it. To test that reliably, we need a base path that we know will not get shortened. Creating that base path under the temp directory is a nightmare, we need to: (1) retrieve the temp dir, shorten it so we know that it won't be shortened further (2) keep creating subdirectories that have a short name so they also won't get shortened, but keep the entire path below MAX_PATH while leaving enough space for a file name in the end (3) append a file name such that the path is just below MAX_PATH, or is exactly that long, or is longer than it. Because of steps (1) and (2) we can be sure that no other component in the path will get shortened, so we can test exactly what's going on with the shortener logic and its error handling. But oh boy is it complicated. Side note, we need to use the Widechar WinAPI functions to create/delete the directories and files, because the POSIX API on Windows appears to be backed by the ASCII API functions, so attempting to `mkdir` with a path longer than CreateDirectoryA's limit is going to fail. But on the positive side, adding tests caught two bugs in the method, so we have that going for us which is nice. See https://github.com/bazelbuild/bazel/issues/2107 See https://github.com/bazelbuild/bazel/issues/2181 -- PiperOrigin-RevId: 144823029 MOS_MIGRATED_REVID=144823029
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-08 11:09:46 +0000