aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/cpp
Commit message (Collapse)AuthorAge
* Change the list of rc files accepted.Gravatar ccalvarin2018-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The old list was, in order: - %workspace%/tools/bazel.rc (unless --nomaster_bazelrc) - %binary_dir%/bazel.bazelrc (unless --nomaster_bazelrc) - system rc, /etc/bazel.bazelrc or in %ProgramData% for Windows (unless --nomaster_bazelrc) - the first of the following gets called the "user" bazelrc - path passed by flag --bazelrc - %workspace%/.bazelrc - $HOME/.bazelrc The new list is hopefully a bit more consistent, as: - system rc (unless --nosystem_rc) - workspace, %workspace%/.bazelrc (unless --noworkspace_rc) - user, $HOME/.bazelrc (unless --nohome_rc) - command-line provided, passed as --bazelrc or nothing if the flag is absent. This list removes two less than useful locations, duplication in the Workspace directory, and the rc next to the bazel binary. This location made sense at Google but is generally nonsensical elsewhere so we are removing it. It also stops the user local rc file from being overriden by passing in a custom file in --bazelrc. In both old and new, --ignore_all_rc_files disables all of the above. For a transition period, any file that you would have loaded but was not read will cause a WARNING to be printed. If you want the old file to still be read without moving its location, you can always import it into one of the new standard locations, or create a symlink. Closes #4502, except for cleanup to remove the warning after a transition period of 1 Bazel version has passed. RELNOTES[INC]: New bazelrc file list. PiperOrigin-RevId: 207189212
* Add a normal startup-option for setting the digest function.Gravatar ccalvarin2018-08-01
| | | | | | | | | We continue to support the jvm property -Dbazel.DigestFunction, for backwards compatibility, but this will go away. The startup-option is marked experimental for now as we iron out issues. (note: leaving this out of release notes until the experimental tag is removed) As part of this refactor, the default constructor calls for FileSystem and derived classes will now use this default. This should remove the need for constructors that accept custom hash functions. RELNOTES: None. PiperOrigin-RevId: 207035217
* Make sure that user-level log messages are not lost in a buffer if debugGravatar ccalvarin2018-08-01
| | | | | | | | | | | logging is turned off. WARNINGs, ERRORs, and simple USER messages get printed to stderr when debug logging is disabled, which it is by default. However, before this change, these were lost if they were sent to BAZEL_LOG before Bazel knew whether or not debug logging was requested. This fixes that by maintaining separate buffers, and dumping only the appropriate one to stderr once we know whether or not it is wanted. Maintaining the separate buffer also allows for it to be easy to, in the future, allow logging to multiple places, if we are logging details to a file and user-level details to stderr, for example. RELNOTES: None. PiperOrigin-RevId: 206960686
* Add a --server_javabase startup option as an alias for the LHS --host_javabaseGravatar cushon2018-07-25
| | | | | | | | | | to avoid confusion between the LHS and RHS host_javabases. The LHS --host_javabase option should be considered deprecated and will eventually be removed. RELNOTES: Rename the startup flag --host_javabase to --server_javabase to avoid confusion with the build flag --host_javabase PiperOrigin-RevId: 206015757
* Fix block_for_lock.Gravatar ccalvarin2018-07-23
| | | | | | | | | | | | | | | | | | | | | | | | | | On two fronts: First, it should follow standard command line semantics. Second, it should work as intended: --noblock_for_lock means the client will not wait for another command to finish, but will exit eagerly. It can be useful for preventing hanging in applications that are non-interactively calling bazel. It should have standard startup-option semantics: the default value is accepted as a no-op or can be provided to override a previous value. The next issue involves 2 different locks - the client lock, and the server-side command lock. This duality exists because we would like, one day, to be able to run certain commands, like info or help, at the same time, so multiple commands would need specialized locks that allow some duality but blocks others. This can only be done at the server level, so as soon as the client gets the "we're connected" grpc message from the server, it releases the client lock and lets the server manage multiple requests. There are basically 3 possible states that are relevant to this option: 1) no other client is active, so no one holds the client lock or the command lock - the server can be used, shutdown or started as needed. - no blocking, but no need to block, either, so we're safe 2) another client (client1) holds the lock, but it is currently using a server that we want to reuse. If client1 still holds the client lock, we fail fast. Same thing if client1 is holding the server-side lock: we will exit gracefully when the BlazeCommandDispatcher responds with a failure. 3) client1 holds the lock but its server cannot be reused. (batch clients also fall into this category, as there is no server to reuse - but in this case, the client lock is still in play). However, for server mode, this is broken - the following happens: - Server is occupied with client1's request, holds the command lock - client2 wants to restart the server, so sends the old server a "shutdown" command - the BlazeCommandDispatcher says - nuh-uh, this is busy, and you said you didn't want to wait for the lock - client2 absorbs this response - waits (blocks...) - for a minute - then force shuts-down the old server. So we had 2 problems - we block, and we shutdown a server that we truly intended to keep going. Now, if the server responds saying another action is using it, the client will exit correctly, and leave the old server to do its thing. RELNOTES: None. PiperOrigin-RevId: 205671817
* 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
* Bazel client: add a simple profilerGravatar Laszlo Csomor2018-06-27
| | | | | | | | | | | | | | | | | | | | | | | | Add a simple profiler that can measure function call counts and durations, and report statistics by printing to stderr. Motivation: I recently needed a profiler for PR #5445 and PR #5448, so I'm adding the polished code now. Usage: 1. depend on //src/main/cpp/util:profiler 2. use StopWatch, Task, and ScopedTask objects as shown in profiler.h's class documentation See https://github.com/bazelbuild/bazel/issues/5444 Change-Id: I43f0afd124b486c694f451e8455a66ffca8137b6 Closes #5461. Change-Id: I43f0afd124b486c694f451e8455a66ffca8137b6 PiperOrigin-RevId: 202314319
* Windows: Native launcher now works with unicode.Gravatar Yun Peng2018-06-25
| | | | | | | | | | | | | | The native launcher can now launch Java and Bash binary in directory with non-English characters. Unfortunately, python doesn't support running python zip file under directory with non-English characters. eg. python ./??/bin.zip will still fail. See https://github.com/bazelbuild/bazel/issues/4473 Change-Id: I77fe9cdaabffc2e0d25c7097da5c0c9333a9c4a3 PiperOrigin-RevId: 201939391
* Windows,Bazel client: check embedded tools fasterGravatar Laszlo Csomor2018-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | The Bazel client on Windows is now 50% faster to check the embedded tools than it was before. Results: - Linux: 20 ms -> 6 ms - Windows: 294 ms -> 133 ms Measurements were done with n=10 runs and a hot server, using blaze::GetMillisecondsMonotonic(). Previously the client performed the same tasks multiple times while trying to determine if a path was a good extracted binary. (E.g. converted the path to Windows format multiple times, checked if it was a directory twice, opened the path twice.) Now the client performes these tasks only once, e.g. it converts path once and stats only once. See https://github.com/bazelbuild/bazel/issues/5444 Closes #5445. PiperOrigin-RevId: 201913758
* Automatic ClangTidyReadability code cleanup.Gravatar Googler2018-06-22
| | | | PiperOrigin-RevId: 201680493
* Make the system bazelrc configurable.Gravatar ccalvarin2018-06-20
| | | | | | | | | | | The master bazelrc is now defined by preprocessor macro at (Bazel's) compile time. The default is still /etc/bazel.bazelrc for most platforms, but windows now has a %ProgramData% relative default value as well. Users wishing to change this default when building Bazel for a new platform should edit BAZEL_SYSTEM_BAZELRC_PATH in src/main/cpp/BUILD. Part of https://github.com/bazelbuild/bazel/issues/4502, relevant to the duplicate issue #4809. TESTED: default settings were tested manually, since they cannot be tested in a sandbox RELNOTES: Windows default system bazelrc is read from the user's ProgramData if present. PiperOrigin-RevId: 201423446
* Add better tests for the -h and -help accepted values.Gravatar ccalvarin2018-06-20
| | | | | | | It looks like this test was intended to add coverage for these option-like values that we accept as commands, but it did not actually test this. RELNOTES: None. PiperOrigin-RevId: 201380534
* Make blaze_util::AsAbsoluteWindowsPath support wstring as inputGravatar Yun Peng2018-06-20
| | | | | | | | | | | | | | Now we have: bool AsAbsoluteWindowsPath(const std::wstring& path, std::wstring* result, std::string* error); This change helps making the C++ native launcher work with UTF-16. See https://github.com/bazelbuild/bazel/issues/4473 Closes #5406. Change-Id: I7eaf55f9fe5a4d41e3dd09edc2a21e9b3cc9277c PiperOrigin-RevId: 201352866
* Add a utility function to accept windows-style envvars in paths.Gravatar ccalvarin2018-06-19
| | | | | | | | | | | For paths passed to Bazel on the command line, the shell expands these variables, but for hardcoded defaults, we must make the library call ourselves. We do not add similar support in Posix systems, where it is less common to rely on standard path-related variables. Prerequisit for issue #4502. RELNOTES: None. PiperOrigin-RevId: 201183214
* 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
* Automatic ClangTidyReadability code cleanup.Gravatar Googler2018-06-08
| | | | PiperOrigin-RevId: 199769337
* blaze_util::ConvertPath should not make paths absolute.Gravatar ccalvarin2018-06-07
| | | | | | | | | It does not claim to, and this was already true for posix platforms. Windows platforms, however, always made the path absolute, which was a hard-to-diagnose difference between the two. Similarly, MakeAbsolute was relying on this to be correct for windows, so this change splits the implementation and keeps the behavior consistent. While we're here, also remove the empty-string behavior from MakeAbsolute, and instead make it clear at all sites that this behavior is present and affects accepted flag syntax. We may want to remove this later. RELNOTES: None. PiperOrigin-RevId: 199663395
* Automatic ClangTidyPerformance code cleanup.Gravatar Googler2018-06-06
| | | | PiperOrigin-RevId: 199449250
* Move path-manipulation functions to own library file.Gravatar ccalvarin2018-06-05
| | | | | | | | | | | Leave functions that make file accesses in the file library, and general blaze utilities in the blaze_util file, but move the functions that boil down to string manipulation and path formatting to their own file. (With the exception of getCWD, since absolute path syntax is relevant here.) Doing this largely to consolidate all Windows path control into a single place, so that it's easier to notice inconsistencies. For instance, ConvertPath currently makes Windows paths absolute, but not Posix paths, and MakeAbsolute relies on this behavior. In addition, JoinPath assumes Posix path syntax, which leads to some odd looking paths. These will be fixed in a followup change. (Found these issues while working on #4502, trying to fix the windows-specific system bazelrc.) RELNOTES: None. PiperOrigin-RevId: 199368226
* Add --ignore_all_rc_files startup options.Gravatar ccalvarin2018-05-15
| | | | | | | | | | | | | This overrides --bazelrc and --[no]master_bazelrc regardless of order. Like --bazelrc and --[no]master_bazelrc, it cannot be mentioned in an rc file, this would be a contradiction. This flag is useful for testing, and for having a version-agnostic way to turn off all rc files, such as in the canonical command line reporting. Now that blazerc and bazelrc are separate, this is necessary. If explicit values for --bazelrc or --master_bazelrc are provided which are now ignored, Bazel will warn the user. #4502 Alternatives considered - We could avoid this flag but would need to have some well-documented, reusable list of the startup flags that effectively come to the same effect. This would be necessary in our integration tests and in the CommandLineEvent and other places where rc files need to be completely disabled for correctness. We decided that this startup option was more straightforward and usable for both users and Bazel devs: it shouldn't be used when more fine-grained control is needed, but provides warnings if users are likely to be confused by the outcome. RELNOTES: None. PiperOrigin-RevId: 196750704
* Break out the rc file tests from the more general option parsing tests.Gravatar ccalvarin2018-05-01
| | | | | | | | | This allows us to have clear file setup and tear down, so we can more carefully test cases where files are present but intentionally ignored due to flags. Also stop using re2 and rely on gmock's MatchesRegex instead, which is more concise. RELNOTES: None. PiperOrigin-RevId: 195007726
* windows,client: no longer support Unix-style pathsGravatar Laszlo Csomor2018-04-26
| | | | | | | | | | | | | | The Bazel client no longer supports MSYS paths. The only exception is "/dev/null" which the client treats as "NUL". After this change you can no longer pass MSYS paths as Bazel flag values on Windows. See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: I39d81843015c5a4014dd5953bac2e1c29dcd5bed PiperOrigin-RevId: 194372504
* windows,client: fix error reportingGravatar Laszlo Csomor2018-04-24
| | | | | | | | | | | | | | | | | | | | | | Fix error reporting in the path conversion methods of the Bazel client. Previously the error reporting logic used GetLastErrorString in places where it was not appropriate (i.e. it was not a failed Windows API call that caused an error). This cleanup prepares removing the concept of the MSYS root from the Bazel client, since MSYS paths are no longer supported and we want to cut Bazel's dependency on Bash (thus MSYS) completely. See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: Ie50a20e0ee0c572592f637340a2f2948c7f53088 Closes #5072. Change-Id: Ie50a20e0ee0c572592f637340a2f2948c7f53088 PiperOrigin-RevId: 194052665
* Remove overlap between the blazerc and bazelrc names.Gravatar ccalvarin2018-04-20
| | | | | | | | Bazel now has its own subclass of StartupOptions to specify bazel-only options. This is needed for https://github.com/bazelbuild/bazel/issues/4502. RELNOTES(INC): No longer accepts --blazerc or --[no]master_blazerc, accepts bazelrc name only. PiperOrigin-RevId: 193718297
* Refactor where rc files are controlled.Gravatar ccalvarin2018-04-19
| | | | | | | In preparation for https://github.com/bazelbuild/bazel/issues/4502, make OptionProcessor::GetRcFiles contain the logic for both the user bazelrcs and the master bazelrcs. RELNOTES: None PiperOrigin-RevId: 193521683
* Fix signedness warnings in cpp tests.Gravatar Benjamin Peterson2018-04-17
| | | | | | | | | | | | | | | | | | | | The compiler infers the type of unsuffixed literals as signed. That causes GCC warnings like this with gtest's ASSERT_EQ if one side is a literal and other is an unsigned type: ``` In file included from src/test/cpp/option_processor_test.cc:23:0: external/com_google_googletest/googletest/include/gtest/gtest.h: In instantiation of 'testing::AssertionResult testing::internal::CmpHelperEQ(const char*, const char*, const T1&, const T2&) [with T1 = int; T2 = long unsigned int]': external/com_google_googletest/googletest/include/gtest/gtest.h:1449:23: required from 'static testing::AssertionResult testing::internal::EqHelper<lhs_is_null_literal>::Compare(const char*, const char*, const T1&, const T2&) [with T1 = int; T2 = long unsigned int; bool lhs_is_null_literal = false]' src/test/cpp/option_processor_test.cc:98:3: required from here external/com_google_googletest/googletest/include/gtest/gtest.h:1421:11: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (lhs == rhs) { ~~~~^~~~~~ ``` Closes #4994. Change-Id: Ic40e8714531aaa0e0d748dd59658a6de15bfe12d PiperOrigin-RevId: 193161516
* Break out the SuccessfulIs(Un|Null)aryTest into a helper file.Gravatar ccalvarin2018-04-13
| | | | | RELNOTES: None. PiperOrigin-RevId: 192805836
* Create BAZEL_DIE macro.Gravatar ccalvarin2018-04-03
| | | | | | | Will migrate die() instances in a later change, to keep this one clean. RELNOTES: None. PiperOrigin-RevId: 191491701
* Remove startup JVM version checkGravatar cushon2018-03-29
| | | | | | | | | | | | This was added during the JDK 7->8 transition to improve the diagnostic when an older-than-supported host_javabase was used. The version number handling doesn't work with JDK 9 (see [1]), and using Bazel binaries with a bundled host_javabase avoid the error entirely so the message is less important. [1] http://openjdk.java.net/jeps/223 PiperOrigin-RevId: 190944476
* Remove the --allow_configurable_attributes startup option.Gravatar ccalvarin2018-03-27
| | | | | | | It was removed from the java code 4 years ago, mentioning it causes the server to crash at startup. RELNOTES: None. PiperOrigin-RevId: 190636455
* Remove final third_party/gtest reference.Gravatar ccalvarin2018-03-26
| | | | | | | Missed this in https://github.com/bazelbuild/bazel/commit/8e9f4a8591d65c7972aea3957c57601570e0a39b. RELNOTES: None. PiperOrigin-RevId: 190506543
* Fold in warning and error output into client logging.Gravatar ccalvarin2018-03-23
| | | | | | | To replace blaze_util::die and blaze_util::pdie as well, FATAL statements need to accept blaze exit codes. RELNOTES: None. PiperOrigin-RevId: 190285798
* 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
* Update the client's skeleton logging framework to use it for --client_debug.Gravatar ccalvarin2018-03-21
| | | | | | | | | We are still unable to turn this on to write to files, but there are currently 2 logging systems in use in the client: the inactive one, and the print-to-stderr option triggered by --client_debug. Combine these, so we can use the same logging format for both. Also combine it with the VerboseLogging functionality - it was not documented anywhere and seems redundant. RELNOTES: None. PiperOrigin-RevId: 189979051
* Add unit tests for rc parsing.Gravatar ccalvarin2018-03-08
| | | | | | | | | | | | | | | | | These provide some testing for the following cases: - tokenization - recognizing comments - grouping of different lines by command - import ordering - import cycles - bad imports There's still room for more, in particular in the multi-command case, but this feels like a good start. Also identified some surprising behaviors that should be fixed. Leaving them tested as documentation of their broken nature. RELNOTES: None. PiperOrigin-RevId: 188355929
* Combine WorkspaceRcFileSearchPath and FindCandidateBlazercPaths and add a test.Gravatar ajmichael2018-02-07
| | | | | RELNOTES: None PiperOrigin-RevId: 184865343
* Support negated flags in SearchNullaryOption with last-wins semantics.Gravatar ajmichael2018-01-24
| | | | | | | `blaze --nomaster_bazelrc --master_bazelrc` now uses the master bazelrc. RELNOTES: None PiperOrigin-RevId: 183083839
* 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: 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
* Delete unused BlazeUtil#SearchNullaryOptionEverywhere.Gravatar lpino2017-09-20
| | | | PiperOrigin-RevId: 169370539
* 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
* Send Bazel startup options to server.Gravatar ccalvarin2017-08-16
| | | | | | | | | | | Send the startup options tagged with their origin so that the server has correct information about the command line as the client received it. Removes the unconditional stderr printing of all bazelrc startup options in the bazel client. Instead, the startup options are sent to the server and the same informational printing is gated on the --announce_rc option. This avoids unconditional log spam to stderr early in startup. If the server is unreachable or there are errors parsing startup options, the message is still printed to stderr. Fixes https://github.com/bazelbuild/bazel/issues/2530. RELNOTES: --announce_rc now controls whether bazelrc startup options are printed to stderr. PiperOrigin-RevId: 165211007
* Polish blaze_util.ccGravatar lpino2017-08-11
| | | | PiperOrigin-RevId: 164850909
* Internal changeGravatar Googler2017-08-01
| | | | PiperOrigin-RevId: 163799447
* Bazel client: add blaze_util::IsDevNullGravatar Laszlo Csomor2017-07-25
| | | | | | | | | | | | | | | | | | | | | | Add a method to test if a path is /dev/null (or case-insensitive "NUL" on Windows), and use it in blaze::MakeAbsolute. In this commit: - implement blaze_util::IsDevNull with POSIX and Windows semantics + add tests - blaze::MakeAbsolute calls blaze::ConvertPath on its input to convert MSYS paths on Windows - blaze_util::GetCwdW (thus GetCwd) always returns a lowercase path so that it is deterministic - blaze_util::GetCurrentDrive returns lowercase letter to be consisent with blaze::ConvertPath, which also returns a lowercase path Fixes https://github.com/bazelbuild/bazel/issues/3440 Change-Id: I3af5ba0a033d542fe64a676d67f27472298d1089 PiperOrigin-RevId: 163038503
* Windows: add blaze_util::AsAbsoluteWindowsPathGravatar laszlocsomor2017-07-24
| | | | | | | | | | | Replace blaze_util::AsWindowsPathWithUncPrefix with AsAbsoluteWindowsPath, which always returns an absolute path. Fixes https://github.com/bazelbuild/bazel/issues/2935 RELNOTES: none PiperOrigin-RevId: 162727218
* Windows: more robust path handling.Gravatar laszlocsomor2017-07-24
| | | | | | | | | | | | | | | In this change: - add support for absolute-on-current-drive paths (e.g. "\foo", meaning "c:\foo") - report error for relative-on-current-drive paths (e.g. "c:" and "c:foo") - report error for remote Windows paths (e.g. "\\servername\path\on\server") - update blaze_util::AsWindowsPath comments - update tests RELNOTES: none PiperOrigin-RevId: 162719763
* Windows: clean up error reportingGravatar Laszlo Csomor2017-07-20
| | | | | | | | | | | | | | | | | | | In this commit: - remove blaze::PrintError in favor of blaze_util::PrintError - remove Ijar's PrintLastErrorMessage in favor of blaze_util::PrintError - use pdie every time path conversion fails, because that indicates a fatal error (bad user input for a path flag, or downright bug) - remove explicitly printing GetLastErrror; pdie and PrintError do it already - unify the pdie/PrintError message formats Fixes https://github.com/bazelbuild/bazel/issues/2935 Change-Id: I5feaf73885cab95c43a28c529ada6942e037b162 PiperOrigin-RevId: 162587490
* Bazel CI: fix broken compilationGravatar laszlocsomor2017-07-11
| | | | | | | Fixes https://github.com/bazelbuild/bazel/issues/3357 RELNOTES: none PiperOrigin-RevId: 161516302
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-02 04:16:27 +0000