Interestingly, (only) MSVC fails to compile a template function with an rvalue reference to an array, followed by a parameter with a default initializer of {} (e.g., void f(T (&&a)[N], T x = {})).
See https://godbolt.org/z/cv3dhhro7 for details and a minimal, reproducible example.
This patch uses a simple, equivalent alternative code that successfully compiles, found in the snippet above.
PiperOrigin-RevId: 731333419
From https://google.github.io/googletest/gmock_for_dummies.html#using-mocks-in-tests:
> Important note: gMock requires expectations to be set before the mock functions are called, otherwise the behavior is undefined. Do not alternate between calls to EXPECT_CALL() and calls to the mock functions, and do not set any expectations on a mock after passing the mock to an API.
This is the last (currently known) TSAN error in mozc :)
PiperOrigin-RevId: 731217246
This follows up to my previous commit [1], which introduced
src/build_tools/progress_printer.py
as a preparation to support 'clang-cl' (#1179).
Seems that a subsequent commit [2] unexpectedly appended a duplicated
copyright header because of some issue in copybara [3] rewrite rules.
This commit aims to clean it up.
[1]: 5c0b4bdab5
[2]: 992b1f49f1
[3]: https://github.com/google/copybara
PiperOrigin-RevId: 731099706
This follows up to my previous commit [1], which introduced
docs/build_mozc_for_android.md
as a dedicated build instruction page for building libmozc.so for
Android as part of removing the dependency on Docker from our build
instructions (#1181).
This commit fixes the link to the above new page in README.md.
[1]: f215eaf71a
PiperOrigin-RevId: 730872735
This follows up to my previous commit [1], which introduced
docs/build_mozc_for_android.md
as a dedicated build instruction page for building 'libmozc.so' for
Android as part of removing the dependency on Docker from our build
instructions (#1181).
While the above document uses 'python3' elsewhere, there was one place
where 'python' was used instead. It would be better to avoid 'python'
in favor of PEP 394 [2].
[1]: f215eaf71a
[2]: https://peps.python.org/pep-0394/
PiperOrigin-RevId: 730872687
This is a preparation to build Mozc for Windows with clang-cl (#1179).
Now that Windows Bazel builds rely on CC toolchain resolution (#1112),
'clang-cl' needs to be picked up based on 'platform' specified to Bazel.
This gives us an inverse problem what needs to be passed to Bazel so
that such a resolution can happen.
The simplest solution as far as I have figures out is doing the
following two steps.
1. Specify '--host_platform=//:host-windows-clang-cl', where it is
defined as follows.
platform(
name = "host-windows-clang-cl",
constraint_values = [
"@platforms//os:windows",
"@bazel_tools//tools/cpp:clang-cl",
],
parents = ["@local_config_platform//:host"],
)
By doing this, '@bazel_tools//tools/cpp:clang-cl' can be propagated
into each execution platform, which is mandatory for 'clang-cl' to be
picked up.
2. Specify '--extra_toolchains' command line options to put the
following toolchains from 'rules_cc' in higher priority than cl.exe.
* '@local_config_cc//:cc-toolchain-x64_x86_windows-clang-cl'
* '@local_config_cc//:cc-toolchain-x64_windows-clang-cl'
This is important because CC toolchain resolution picks up the first
toolchain that satisfies all the constraints. To give a higher
priority to 'clang-cl' toolchains, they need to be registered before
'cl' toolchains are registered.
Note that
register_toolchains("@local_config_cc//:all")
in 'MODULE.bazel' registers toolchains in the alphabetical order. To
give a higher priority to 'clang-cl' toolchains, '--extra_toolchains'
command line looks to be the best way.
What this commit does is the step 1. Without the step 2, there must be
no observable behavior change yet.
PiperOrigin-RevId: 730872676
This follows up to my previous commit [1], which introduced several
patches to 'rules_cc' including
bazel/rules_cc_BUILD.windows.tpl.patch
to support 'clang-cl' (#1179).
Seems that a subsequent commit [2] unexpectedly replacing '@platforms//'
with '//third_party/bazel_platforms' probably because of some issue in
copybara rewrite rules. This commit restores the above file to the
original state to fix Windows Bazel build.
[1]: 76343ffa70
[2]: c523a3b998
[3]: https://github.com/google/copybara
PiperOrigin-RevId: 730872628
As a preparation to start using clang-cl for Windows (#1179), with this
commit
python build_tools/update_deps.py
will start deploying LLVM for windows into
src/third_party/llvm/
by downloading the archive from LLVM's GitHub releases page.
The downloaded clang-cl is not yet used.
PiperOrigin-RevId: 730872577
Background:
The converter is now shared across different modules. Engine::GetConverter() returns the raw pointer of Converter. When the Engine is updated/reloaded, all clients that hold the previous Converter will access the dangling pointer. Since it is not possible to detect if any client is holding the previous pointer, Converter has virtually shared ownership, so we prefer to use std::shared_ptr. We can safely update Engine.
Ideally, EngineConverter doesn't want to hold the converter_ but call Engine::GetConverter() on-the-fly, assuming that the actual Converter is dynamically and asynchronously updated. However, such a change may cause another problem because EngineConverter is not designed or at least tested with the situation where the underlying converter is updated every method call or key event.
PiperOrigin-RevId: 730738794
Background:
Currently, Config and Request are shared by multiple components. They are not view-only objects but mutable pointers dynamically updated via setter methods. The current design is not recommended as it can easily lead to dangling pointers (e.g., forgetting to call a setter method). The style guide recommends std::shared_ptr when implementing shared objects.
PiperOrigin-RevId: 730100380
Background:
composer::Table is shared across different components.
Though we would like to avoid shared object, Table is not copyable so there is no other way to share them at this moment. The internal data of the Table is managed by std::unique_ptr, which makes simple copying impossible. Furthermore, copying the table every time would result in a significant performance degradation. Style guide says that we prefer to use std::shared_ptr for shared memory object.
PiperOrigin-RevId: 730072127
- Moves SetMedata/FixupFilePermission from public to internal function.
- Introduced GetSharedDefaultConfig(), as we will use shared_ptr to manage shared config.
- Renamed (Get|Set)ConfigFileName to (Get|Set)ConfigFileNameForTesting
- Introduced two config hash (w/ metadata and w/o metadata) to prevent unnecessary config update.
PiperOrigin-RevId: 729894073
These containers offer `constexpr` construction, by creating a sorted array at compile time, and provide read-only lookup of values.
They have a very minimal API surface, sufficient for Mozc's use, and deliberately diverge from the standard STL API for simplicity.
* `FlatSet` has `bool contains(K)`: The standard C++ interface for sets.
* `FlatMap` has `const T* FindOrNull(K)`, not `iterator find(K)`: No iterator involved.
* `FlatMultiMap` has `absl::Span<const Entry<K, V>> EqualSpan(K)`, not `pair<iterator, iterator> equal_range(K)`: No iterator, or no `std::pair` that lacks necessary `constexpr` support (yet).
These are meant for replacing patterns like `const auto *map = new std::map<...>(...)` in the codebase, reducing runtime startup work and eliminating leaked heap allocations, which is particularly important when linked in the Windows DLL.
PiperOrigin-RevId: 729741608
This is the first part towards removing the dependency on Docker from
our build instructions for Linux desktop and Android (#1181).
This commit makes it clear that you can build 'libmozc.so' on both Linux
and macOS by the same Bazel command with actually demonstrating it in
.github/workflows/android.yaml
that 'libmozc.so' can be built on both Linux and macOS GitHub Actions
runners.
With above our 'Dockerfile' can stop setting up Android NDK since
'build_mozc_in_docker.md' does not mention Android any more.
This commit is only about the build instructions of 'libmozc.so' for
Android. There must be no difference in the final artifacts.
PiperOrigin-RevId: 729468755
This is a preparation before supporting 'clang-cl' for Windows (#1179).
Our plan is to download LLVM for Windows in 'update_deps.py', and in
that process we would like to use 'ProgressPrinter' to show progress for
both downloading the archive and extracting it.
To avoid code duplicate between 'build_qt.py' and 'update_deps.py',
let's extract 'ProgressPrinter' into a new file first.
This is a mechanical refactoring commit. There must be no observable
behavior change.
PiperOrigin-RevId: 729457855
# `Singleton<T>`
* Access to both `once_` and `instance_` must be synchronized.
* Note that `absl::once_flag` itself doesn't need any sync, as it is a sync primitive itself.
* But we wrap it in a `std::optional`.
* The `instance_` could be put behind an atomic, but we need a mutex for `once_`.
* Once we have a mutex, we actually don't need `once_` because `instance_ == nullptr` inside critical section is the exact condition to perform initialization.
* Finalizer array must be put behind a mutex too.
* Logging utilities no longer depends on `//base:singleton`. Let's just use `LOG(FATAL)` on error.
# `SingletonMockable<T>`
* Access to `mock_` must be synchronized.
* We can simply use an atomic here.
* Use `absl::NoDestructor` for storing the real impl.
PiperOrigin-RevId: 728982963
This follows up to our previous commit [1], which not only updated the
copyright year but also replaced "Google Inc." with "Google LLC" for
consistency.
This commit takes care of the remaining instances of "Google Inc." that
are user visible.
[1]: 060367d120
PiperOrigin-RevId: 728143764
This is a preparation to build Mozc for Windows with clang-cl (#1179).
This commit pulls my pull request [1] to let rules_cc register clang-cl
as a valid toolchain to build x86 (32-bit) Windows executables. While
when and how my pull request will get merged into upstream, having these
local patches allows us to go ahead to see if we can fully migrate to
clang-cl or not.
There must be no impact on Bazel with msvc build in this commit.
[1]: https://github.com/bazelbuild/rules_cc/pull/360
PiperOrigin-RevId: 728118916
With this commit Bazel 8.1.0 [1] starts being used to build Mozc unless
USE_BAZEL_VERSION environment variable is specified or the bazel command
is directly invoked.
There is expected to be no compatibility issue between Bazel 8.0.0 and
Bazel 8.1.0 as far as I know.
[1]: https://github.com/bazelbuild/bazel/releases/tag/8.1.0
PiperOrigin-RevId: 728118776
This follows up to our previous commit [1], which introduced
.bazelversion
so that we can centralize where to specify the expected version of Bazel
in our CI and build instructions.
This commit replaces the remaining usage of
bazel
command with
bazelisk
command then explain where the expected bazel version is specified.
This is just a documentation change. There must be no behavior change in
the final artifacts.
[1]: 8d704f0f82
PiperOrigin-RevId: 728118770
This is a preparation before removing the dependency on Docker from our
Android build instructions (#1181).
Suppose we want to specify 'path' attribute to
'android_ndk_repository_extension' so that we can specify the actual
path to the Android NDK in our MODULE.bazel.
android_ndk_repository_extension = use_extension(
"@rules_android_ndk//:extension.bzl",
"android_ndk_repository_extension",
)
android_ndk_repository_extension.configure(
path = "$WORKSPACE_ROOT/third_party/ndk/android-ndk-r28",
)
use_repo(android_ndk_repository_extension, "androidndk")
The problem is that there is currently no way to conditionally the the
above path attribute depending on the host platform and/or the target
platform. As a result, the above configuration takes effect not only on
Linux but also on Windows environment, where we do not plan to support
building libmozc.so right now.
To gracefully handle the above scenario, this commit updates our patch
to 'rules_android_ndk' to generate an empty BUILD.bazel file when an
Android NDK does not exist at the location specified by ANDROID_NDK_HOME
or the path attribute. Basically this is a superset of the behavior of
the current patch, where an empty BUILD.bazel file is generated unless
ANDROID_NDK_HOME is explicitly specified or the path attribute is set.
In general there should be no observable behavior change as long as the
build is currently passing.
PiperOrigin-RevId: 728118761
This is a preparation before removing the dependency on Docker from our
Android build instructions (#1181).
With this commit running the 'update_deps.py' also downloads Android NDK
for macOS and Linux then extract it under third_party/ndk/.
This would enable us to fully control which version of Android NDK
should be used to build Android Library ('libmozc.so') in a subsequent
commit.
At this moment only the observable difference is that the Android NDK
will be extracted under third_party/ndk/. There must be no difference
in the final artifact yet.
PiperOrigin-RevId: 728118756
This is performance lint, which is useless in tests, but let's burn it.
Also, slightly updated the code to make it look more pretty (and that's how I silenced the lint).
PiperOrigin-RevId: 727725125
This module is internal and only used by mozc_transliterator.
Moves the logic to mozc_transliterator to reduce the maintenance cost.
PiperOrigin-RevId: 726396597
- Stop passing config to request to create engine_converter. They are set via Set config and SetRequest in the first place. Currently, default objects are passed, which are not used.
PiperOrigin-RevId: 726376247
As seen in the following thread, the protobuf team is planning to stop
supporting the combination of Bazel and cl.exe due to well-known its
path length limitation.
* https://github.com/protocolbuffers/protobuf/issues/20085
As a preparation before switching to protobuf v30 (#1177), let's
explicitly add a commandline option as explained to continue using this
combination as a short term solution.
This commit should have no impact on Probobuf v29.x.
PiperOrigin-RevId: 725882774
