移行ガイド

ライブラリのバージョンに加えられた破壊的変更の一覧と、変更に対応するためにコードを更新する方法。

v30.0 での変更点

以下は、ライブラリのバージョンに加えられた破壊的変更の一覧と、変更に対応するためにコードを更新する方法です。

これは、v30.x のニュース発表およびv30.0 のリリースノートで発表された破壊的変更について説明しています。

CMake サブモジュールをフェッチされた依存関係に置き換え

以前は、デフォルトの CMake の動作は、Git サブモジュールを使用してピン留めされた依存関係を取得することでした。-Dprotobuf_ABSL_PROVIDER=package を指定すると、CMake 構成が反転し、Abseil のローカルインストール（jsoncpp および gtest 用の同様のオプション付き）を探すようになりました。これらのオプションは存在しなくなり、デフォルトの動作は、まずすべての依存関係のインストールを探し、必要に応じて GitHub からピン留めされたバージョンをフェッチするようにフォールバックします。

（以前の package の動作と同様に）フォールバックフェッチを防ぐには、CMake を次のように呼び出すことができます。

cmake . -Dprotobuf_LOCAL_DEPENDENCIES_ONLY=ON

（以前のデフォルトの動作と同様に）常に固定バージョンから依存関係をフェッチするには、CMake を次のように呼び出すことができます。

cmake . -Dprotobuf_FORCE_FETCH_DEPENDENCIES=ON

string_view の戻り値の型

戻り値の型は、次の記述子 API に対して absl::string_view になりました。これにより、メモリを節約できます。

  • MessageLite::GetTypeName
  • UnknownField::length_delimited
  • FieldDescriptor::full_name などの記述子 API 名関数

将来の破壊的リリースでは、追加の API を absl::string_view に移行し続ける予定です。

ほとんどの場合、型を更新して安全な場所で absl::string_view を使用するか、必要な場合は元の型に明示的にコピーするようにしてください。関数でこれが返される場合は、呼び出し元も更新する必要がある場合があります。

影響を受ける API メソッドによって返された文字列が次のように使用されている場合

型移行

std::string

既存の動作を維持するには、std::string に明示的に変換します。

または、より高性能な absl::string_view に切り替えます。

const std::string&

absl::string_view に移行します。

（依存関係が多数あるなど）実行不可能な場合は、std::string にコピーする方が簡単な場合があります。

const std::string*

const char*

nullable の場合は、std::optional<absl::string_view> に移行します。

それ以外の場合は、absl::string_view に移行します。

absl::string_view は null 終端される保証がないため、data() を呼び出すときは注意してください。

一般的なコンテナやその他の API の場合、absl::string_view と互換性のあるバリアントに移行できる場合があります。以下に、一般的な例をいくつか示します。

カテゴリ移行前移行
std::vector<std::string> への挿入

push_back()

push_front()

push()

emplace_back()

emplace_front()

emplace()

map または set の挿入

set.insert(key)

map.insert({key, value})

map.insert({key,
{value_params...}})

set.emplace(key)

map.emplace(key, value)

map.try_emplace(key,
value_params...)

map または set のルックアップ

find()

count()

contains()

Abseil コンテナに移行します。

または、透過的なコンパレータを定義します。

std::set<std::string, std::less<>>
std::map<std::string, T, std::less<>>

https://abseil.io/tips/144 を参照してください

文字列連結

operator+

operator+=

absl::StrCat()

absl::StrAppend()

これらは、いずれにせよパフォーマンス上の理由から推奨されています。https://abseil.io/tips/3 を参照してください。

absl::string_view の使用に関する一般的なヒントについては、https://abseil.io/tips/1 も参照してください。

MSVC + Bazel の Poison

Windows の Bazel ユーザーは、この例のように、プロジェクトに以下を追加して clang-cl を使用するように切り替える必要があります。

.bazelrc

common --enable_platform_specific_config build:windows
--extra_toolchains=@local_config_cc//:cc-toolchain-x64_windows-clang-cl
--extra_execution_platforms=//:x64_windows-clang-cl

MODULE.bazel

bazel_dep(name = "platforms", version = "0.0.10")
bazel_dep(name = "rules_cc", version = "0.0.17")

# For clang-cl configuration
cc_configure = use_extension("@rules_cc//cc:extensions.bzl", "cc_configure_extension")
use_repo(cc_configure, "local_config_cc")

WORKSPACE

load("//:protobuf_deps.bzl", "PROTOBUF_MAVEN_ARTIFACTS", "protobuf_deps")

protobuf_deps()

load("@rules_cc//cc:repositories.bzl", "rules_cc_dependencies", "rules_cc_toolchains")

rules_cc_dependencies()

rules_cc_toolchains()

BUILD

Bazel 8 のみとの互換性が必要なユーザー向け。

platform(
    name = "x64_windows-clang-cl",
    constraint_values = [
        "@platforms//cpu:x86_64",
        "@platforms//os:windows",
        "@bazel_tools//tools/cpp:clang-cl",
    ],
)

Bazel 7 および 8 との互換性が必要なユーザー向け。

platform(
    name = "x64_windows-clang-cl",
    constraint_values = [
        "@platforms//cpu:x86_64",
        "@platforms//os:windows",
        # See https://github.com/bazelbuild/rules_cc/issues/330.
        "@rules_cc//cc/private/toolchain:clang-cl",
    ],
)

ユーザーは、次の破壊的リリースまで、オプトアウトフラグ --define=protobuf_allow_msvc=true を設定することで、エラーを一時的に抑制することもできます。

または、MSVC を引き続き使用したいユーザーは、CMake の使用に切り替えることができます。これは、Visual Studioを使用するか、CMake コマンドラインに MSVC ジェネレーターを提供することで実行できます。例：

cmake -G "Visual Studio 17 2022" -A Win64 .

FieldDescriptor オプションから ctype を削除

FieldDescriptor オプションから ctype を公開しなくなりました。代わりに、v28 リリースで追加された FieldDescriptor::cpp_string_type() API を使用できます。

機密フィールドを編集するためにデバッグ API を変更

Protobuf C++ デバッグ API (Protobuf AbslStringify、proto2::ShortFormat、proto2::Utf8Format、Message::DebugString、Message::ShortDebugString、Message::Utf8DebugString を含む) は、debug_redact で注釈が付けられた機密フィールドを編集するように変更されました。これらの API の出力には、プロセスごとのランダム化されたプレフィックスが含まれており、Protobuf TextFormat パーサーでは解析できなくなりました。ユーザーは、人間が判読できる出力（ロギングなど）が必要なほとんどの場合、新しい編集されたデバッグ形式を採用するか、シリアライゼーションとデシリアライゼーションのためにバイナリ形式に切り替えることを検討する必要があります。古いデシリアライズ可能な形式が必要なユーザーは、TextFormat.printer().printToString(proto) を使用できますが、これは機密フィールドを編集しないため、注意して使用する必要があります。

詳細については、2024 年 12 月 4 日にリリースされたニュース記事を参照してください。

非推奨 API を削除

少なくとも 1 回のマイナーまたはメジャーリリースで非推奨 (ABSL_DEPRECATED など) とマークされ、廃止されたか、または置き換えられた、次のパブリックランタイム API を削除しました。

API: Arena::CreateMessage

代替: Arena::Create

API: Arena::GetArena

代替: value->GetArena()

API: RepeatedPtrField::ClearedCount

代替: Arena への移行 (移行ガイド)。

API: JsonOptions

代替: JsonPrintOptions

C++14 のサポートを終了

このリリースでは、C++ 14 を最小サポートバージョンとして廃止し、Foundational C++ Support matrix に従って 17 に引き上げました。

ユーザーは C++17 にアップグレードする必要があります。

Arena 上の Oneof メッセージのクリア後に ASAN Poisoning を導入

この変更により、Arena を使用する C++ protobuf に影響を与える強化チェックが追加されました。protobuf アリーナに割り当てられた Oneof メッセージは、デバッグでクリアされ、ASAN モードで Poison されます。clear を呼び出した後、メモリ領域を再度使用しようとすると、use-after-free エラーとして ASAN でクラッシュが発生します。

この実装には C++17 が必要です。

C++ CocoaPods リリースを廃止

v4.x.x 以降壊れている C++ CocoaPods リリースを廃止しました。C++ ユーザーは代わりにGitHub リリースを直接使用する必要があります。

Python での変更点

Python はメジャーバージョンを 5.29.x から 6.30.x に上げました。

Python 3.8 のサポートを終了

最小サポート Python バージョンは 3.9 です。ユーザーはアップグレードする必要があります。

bazel/system_python.bzl エイリアスを削除

レガシー bazel/system_python.bzl エイリアスを削除しました。

system_python.bzl への直接参照を削除して、代わりに protobuf_deps.bzl を使用してください。直接参照が必要な場合は、v5.27.0 で移動された python/dist/system_python.bzl を使用してください。

フィールドセッターの検証の変更

Python と upb のフィールドセッターは、エディション 2023 でクローズド enum を検証するようになりました。無効な値で更新されたクローズド enum フィールドはエラーを生成します。

非推奨の py_proto_library マクロを削除

protobuf.bzl の非推奨の内部 py_proto_library Bazel マクロが削除されました。これは、v29.x の bazel/py_proto_library の protobuf に移動された公式の py_proto_library に置き換えられました。この実装は、以前は v29.x より前の rules_python で利用可能でした。

非推奨 API を削除

少なくとも 1 回のマイナーまたはメジャーリリースで非推奨とマークされた、次のパブリックランタイム API を削除しました。

リフレクションメソッド

API: reflection.ParseMessage、reflection.MakeClass

代替: message_factory.GetMessageClass()

RPC サービスインターフェース

API: service.RpcException、service.Service、service.RpcController、および service.RpcChannel

代替: バージョン 2.3.0 以降、RPC 実装はこれらを基盤に構築しようとするのではなく、特定の RPC 実装に固有のコードを生成するコードジェネレータープラグインを提供する必要があります。

MessageFactory および SymbolDatabase メソッド

API: MessageFactory.GetPrototype、MessageFactory.CreatePrototype、MessageFactory.GetMessages、SymbolDatabase.GetPrototype、SymbolDatabase.CreatePrototype、および SymbolDatabase.GetMessages

代替: message_factory.GetMessageClass() および message_factory.GetMessageClassesForFiles()。

GetDebugString

API: GetDebugString

代替

代替なし。Python C++ のみに存在し、リリースされなくなりました。純粋な Python または UPB ではサポートされていません。

マップフィールドの Python setdefault の動作変更

setdefault は ScalarMap の dict と似ていますが、キーと値の両方を設定する必要があります。setdefault は MessageMaps では拒否されます。

Python ネストされたメッセージクラス __qualname__ には外部メッセージ名が含まれる

Python ネストされたメッセージクラス __qualname__ に外部メッセージ名が含まれるようになりました。以前は、__qualname__ はネストされたメッセージに対して __name__ と同じ結果であり、外部メッセージ名は含まれていませんでした。

例：

message Foo {
  message Bar {
    bool bool_field = 1;
  }
}
nested = test_pb2.Foo.Bar()
self.assertEqual('Bar', nested.__class__.__name__)
self.assertEqual('Foo.Bar', nested.__class__.__qualname__) # It was 'Bar' before

Objective-C での変更点

これは Objective-C の最初の破壊的リリースです.

Objective-C はメジャーバージョンを 3.x.x から 4.30.x に上げました。

既存の API のほとんどを非推奨にする未知のフィールド処理 API のオーバーホール

GPBUnknownFieldSet を非推奨にし、GPBUnknownFields に置き換えました。新しい型は、メッセージが書き戻されるときに順序のセマンティックな意味が維持されるように、元の入力または API 呼び出しからの未知のフィールドの順序を保持します。

これの一環として、GPBUnknownField 型にも API の変更があり、既存の API のほぼすべてが非推奨になり、新しい API が追加されました。

非推奨のプロパティ API

  • varintList
  • fixed32List
  • fixed64List
  • lengthDelimitedList
  • groupList

非推奨の変更 API

  • addVarint
  • addFixed32
  • addFixed64
  • addLengthDelimited
  • addGroup

非推奨のイニシャライザ initWithNumber:。

新しいプロパティ API

  • type
  • varint
  • fixed32
  • fixed64
  • lengthDelimited
  • group

この型は、特定のフィールド番号のすべての値をグループ化するのではなく、その値で単一のフィールド番号をモデル化します。新しいフィールドを作成するための API は、GPBUnknownFields クラスの add* API です。

-[GPBMessage unknownFields] も非推奨になりました。代わりに、メッセージの未知のフィールドを抽出および更新するための新しい API があります。

非推奨 API を削除

少なくとも 1 回のマイナーまたはメジャーリリースで非推奨とマークされた、次のパブリックランタイム API を削除しました。

GPBFileDescriptor

API: -[GPBFileDescriptor syntax]

代替: 廃止。

GPBMessage mergeFrom:extensionRegistry

API: -[GPBMessage mergeFrom:extensionRegistry:]

代替: -[GPBMessage mergeFrom:extensionRegistry:error:]

GPBDuration timeIntervalSince1970

API: -[GPBDuration timeIntervalSince1970]

代替: -[GPBDuration timeInterval]

GPBTextFormatForUnknownFieldSet

API: GPBTextFormatForUnknownFieldSet()

代替: 廃止 - GPBTextFormatForMessage() を使用してください。これには、不明なフィールドが含まれます。

GPBUnknownFieldSet

API: GPBUnknownFieldSet

代替: GPBUnknownFields

GPBMessage unknownFields

API: GPBMessage unknownFields プロパティ

代替: -[GPBUnknownFields initFromMessage:]、-[GPBMessage mergeUnknownFields:extensionRegistry:error:]、および -[GPBMessage clearUnknownFields]

古い gencode 用の非推奨ランタイム API を削除

このリリースでは、3.22.x リリースより前の Objective-C gencode をサポートしていた非推奨のランタイムメソッドを削除しました。ライブラリは、古い生成コードが起動すると、ランタイムにログメッセージも発行します。

API: +[GPBFileDescriptor allocDescriptorForClass:file:fields:fieldCount:storageSize:flags:]

代替: 最新バージョンのライブラリで再生成します。

API: +[GPBFileDescriptor allocDescriptorForClass:rootClass:file:fields:fieldCount:storageSize:flags:]

代替: 最新バージョンのライブラリで再生成します。

API: +[GPBEnumDescriptor allocDescriptorForName:valueNames:values:count:enumVerifier:]

代替: 最新バージョンのライブラリで再生成します。

API: +[GPBEnumDescriptor allocDescriptorForName:valueNames:values:count:enumVerifier:extraTextFormatInfo:]

代替: 最新バージョンのライブラリで再生成します。

API: -[GPBExtensionDescriptor initWithExtensionDescription:]

代替: 最新バージョンのライブラリで再生成します。

Poison Pill 警告

新しいローリングアップグレードポリシーの下で動作するが、次のメジャーバージョンアップで壊れる古い gencode + 新しいランタイムの組み合わせに対して警告を発するように poison pill を更新しました。たとえば、Python 4.x.x gencode は 5.x.x ランタイムに対して動作するはずですが、6.x.x ランタイムに対する今後の破損について警告します。

C# および Ruby での UTF-8 強制の変更

UTF-8 強制を言語間で一貫させるための修正を含めました。文字列フィールドに不正な非 UTF-8 データがあるユーザーは、UTF-8 強制エラーが以前よりも早く表面化する可能性があります。

JSON パースにおける Ruby および PHP のエラー

JSON 仕様に従って、数値フィールドの文字列の JSON パースにおける非準拠を修正しました。

この修正はメジャーバージョンアップを伴いませんが、Ruby と PHP は、数値フィールドの非数値文字列 (""、"12abc"、"abc" など) に対してエラーを発生させるようになりました。v29.x には、これらのエラーケースに関する警告が含まれています。

v22.0 でのコンパイラの変更点

JSON フィールド名の衝突

変更のソース: PR #11349、PR #10750

JSON マッピングに関するフィールド名の衝突の処理方法に微妙な変更を加えました。proto3 では、制限を部分的に緩和し、フィールド名がケースセンシティブな JSON マッピング (元の名前のキャメルケース) を生成する場合にのみエラーを発生させます。また、json_name オプションもチェックし、ケースセンシティブな衝突に対してエラーを発生させるようになりました。proto2 では、制限を少し厳しくし、2 つの json_name 仕様が衝突する場合にエラーを発生させます。暗黙的な JSON マッピング (キャメルケース) に衝突がある場合は、proto2 で警告を表示します。

レガシー動作を復元するための一時的なメッセージ/enum オプションを提供しました。競合するフィールドの名前を変更することがすぐに実行できないオプションである場合は、特定のメッセージ/enum で deprecated_legacy_json_field_conflicts オプションを設定します。このオプションは今後のリリースで削除されますが、移行するための時間を稼ぐことができます。

v22.0 での C++ API の変更点

4.22.0 には、8 月に発表されたように、C++ ランタイムと protoc の破壊的変更があります。

Autotools の段階的廃止

変更のソース: PR #10132

v22.0 では、protobuf コンパイラと C++ ランタイムからすべての Autotools サポートを削除しました。Autotools を使用してこれらをビルドしている場合は、CMake または Bazel に移行する必要があります。CMake で protobuf をセットアップするための専用の手順があります。

Abseil 依存関係

変更のソース: PR #10416

v22.0 では、Abseilへの明示的な依存関係を取り入れました。これにより、stubsのほとんどを削除することができました。これらは、後に Abseil になった古い内部コードから分岐したものです。微妙な動作変更が多数ありますが、ほとんどはユーザーにとって透過的であるはずです。注目すべき変更点は次のとおりです。

  • string_view - absl::string_view が多くの API で const std::string& に置き換わりました。これは、ユーザーにとって目立った変更がないはずの入力引数に最も一般的に使用されます。一部のケース (仮想メソッド引数や戻り値の型など) では、ユーザーは新しいシグネチャを使用するために明示的な変更を行う必要がある場合があります。

  • テーブル - STL セット/マップの代わりに、Abseil の flat_hash_map、flat_hash_set、btree_map、および btree_set を使用するようになりました。これらはより効率的で、ヘテロジニアスルックアップを可能にします。これはユーザーにはほとんど見えませんが、テーブルの順序付けに関連する微妙な動作変更を引き起こす可能性があります。

  • ロギング - Abseil のロギングライブラリは、古いロギングコードと非常によく似ており、スペルがわずかに異なるだけです (たとえば、GOOGLE_CHECK の代わりに ABSL_CHECK)。最大の違いは、例外をサポートしておらず、FATAL アサーションが失敗した場合に常にクラッシュするようになったことです。（以前は、例外に切り替えるための PROTOBUF_USE_EXCEPTIONS フラグがありました。）これらは重大な問題が発生した場合にのみ発生するため、無条件のクラッシュが適切な対応であると考えています。

    ロギングの変更のソース: PR #11623

  • ビルド依存関係 - 新しいビルド依存関係は、常にダウンストリームユーザーに破損を引き起こす可能性があります。Abseil LTS 20230125 以降をビルドする必要があります。

    • Bazel ビルドの場合、protobuf_deps が WORKSPACE から実行されると、Abseil がピン留めされた LTS リリースで自動的にダウンロードおよびビルドされます。これは透過的であるはずですが、古いバージョンの Abseil に依存している場合は、依存関係をアップグレードする必要があります。

    • CMake ビルドの場合、最初にトップレベルの CMake 構成によってプルされた既存の Abseil インストールを探します (手順を参照)。それ以外の場合、protobuf_ABSL_PROVIDER が module (デフォルト) に設定されている場合は、git サブモジュールから Abseil をビルドしてリンクしようとします。protobuf_ABSL_PROVIDER が package に設定されている場合は、プリインストールされたシステムバージョンの Abseil を探します。

GetCurrentTime メソッドの変更点

Windows では、GetCurrentTime() はシステムによって提供されるマクロの名前です。v22.x より前では、Protobuf は GetCurrentTime() のマクロ定義を誤って削除していました。これにより、<protobuf/util/time_util.h> を含めた後、Windows 開発者にとってマクロが使用できなくなりました。v22.x 以降、Protobuf はマクロ定義を保持します。これにより、google::protobuf::util::TimeUtil::GetCurrentTime() 式を使用するなど、以前の動作に依存する顧客コードが破損する可能性があります。

アプリを新しい動作に移行するには、コードを次のいずれかに変更します。

  • GetCurrent マクロが定義されている場合は、GetCurrentTime マクロを明示的に未定義にします。
  • (google::protobuf::util::TimeUtil::GetCurrentTime)() または同様の式を使用することにより、マクロ展開を防ぎます。

例: マクロの未定義化

Windows からマクロを使用しない場合は、このアプローチを使用します。

以前

#include <google/protobuf/util/time_util.h>

void F() {
  auto time = google::protobuf::util::TimeUtil::GetCurrentTime();
}

以後

#include <google/protobuf/util/time_util.h>
#ifdef GetCurrentTime
#undef GetCurrentTime
#endif

void F() {
  auto time = google::protobuf::util::TimeUtil::GetCurrentTime();
}

例 2: マクロ展開の防止

以前

#include <google/protobuf/util/time_util.h>

void F() {
  auto time = google::protobuf::util::TimeUtil::GetCurrentTime();
}

以後

#include <google/protobuf/util/time_util.h>

void F() {
  auto time = (google::protobuf::util::TimeUtil::GetCurrentTime)();
}

C++20 サポート

変更のソース: PR #10796

C++20 をサポートするために、C++ で生成された protobuf コードで新しいキーワードを予約しました。他の予約済みキーワードと同様に、フィールド、enum、またはメッセージにそれらを使用すると、有効な C++ にするためにアンダースコアサフィックスを追加します。たとえば、concept フィールドは concept_() ゲッターを生成します。これらのキーワードを使用する既存の proto があるシナリオでは、それらを参照する C++ コードを更新して、適切なアンダースコアを追加する必要があります。

Final クラス

変更のソース: PR #11604

Protobuf ライブラリで行われた仮定を強化するための大規模な取り組みの一環として、継承されることを意図していなかった一部のクラスを final とマークしました。これらから継承する既知の使用例はなく、そうすると問題が発生する可能性があります。コードがこれらのクラスから継承している場合の軽減策はありませんが、使用している継承に正当な理由があると思われる場合は、issue を開いてください。

コンテナの静的アサーション

変更のソース: PR #11550

Protobuf ライブラリで行われた仮定を強化するための大規模な取り組みの一環として、Map、RepeatedField、および RepeatedPtrField コンテナに静的アサーションを追加しました。これらは、ドキュメントで説明されているように、これらのコンテナを予期される型でのみ使用していることを保証します。これらの静的アサーションにヒットした場合は、コードを移行して Abseil または STL コンテナを使用する必要があります。std::vector は繰り返しフィールドコンテナの良いドロップイン代替であり、std::unordered_map または absl::flat_hash_map は Map のドロップイン代替です (前者は同様のポインタ安定性を提供し、後者はより効率的です)。

Cleared Element の非推奨化

変更のソース: PR #11588、PR #11639

“クリアされたフィールド” 周りの RepeatedPtrField API は非推奨になり、後の破壊的リリースで完全に削除されます。これは元々、クリアされた後に要素を再利用するための最適化として追加されましたが、うまく機能しませんでした。この API を使用している場合は、メモリの再利用を改善するためにアリーナへの移行を検討する必要があります。

UnsafeArena の非推奨化

変更のソース: PR #10325

アリーナセーフでない API を削除するための大規模な取り組みの一環として、RepeatedField::UnsafeArenaSwap を非表示にしました。これは、これまでに削除した唯一の API ですが、今後のリリースでは、削除を続け、アリーナ間の効率的な借用パターンを処理するためのヘルパーを提供します。単一のアリーナ (またはスタック/ヒープ) 内では、Swap は UnsafeArenaSwap と同じくらい効率的です。利点は、異なるアリーナ間で誤って呼び出した場合に無効なメモリ操作が発生しないことです。

Map Pair のアップグレード

変更のソース: PR #11625

v22.0 では、Map API をクリーンアップして、Abseil および STL との一貫性を高め始めました。特に、MapPair クラスを std::pair へのエイリアスに置き換えました。これはほとんどのユーザーにとって透過的であるはずですが、クラスを直接使用していた場合は、コードを更新する必要がある場合があります。

新しい JSON パーサー {:#json-parser}

変更のソース: PR #10729

このリリースでは、C++ JSON パーサーを書き直しました。ほとんどが隠れた変更であるはずですが、必然的にドキュメント化されていない一部の癖が変更されている可能性があります。それに応じてテストしてください。RFC-8219 JSON として有効でないドキュメント (引用符が欠落しているものや、非標準の bool を使用しているものなど) を解析することは非推奨であり、今後のリリースで削除されます。フィールドのシリアライゼーション順序は、以前は決定論的ではなかったフィールド番号順序と一致することが保証されるようになりました。

この移行の一環として、util/internalの下にあるすべてのファイルが削除されました。これらは古いパーサーで使用されており、外部で使用されることを意図していませんでした。

Arena::Init

変更のソース: PR #10623

Arena の Init メソッドは何も実行しないコードであり、削除されました。このメソッドを呼び出していた場合は、おそらく ArenaOptions のセットを使用して Arena コンストラクターを直接呼び出すことを意図していたのでしょう。呼び出しを削除するか、そのコンストラクターに移行する必要があります。

ErrorCollector の移行

変更のソース: PR #11555

Abseil 移行の一環として、const std::string& から absl::string_view に移行しています。3 つのエラーコレクタークラスの場合、既存のコードを壊さずにこれを行うことはできません。v22.0 では、両方のバリアントをリリースし、メソッドの名前を AddError および AddWarning から RecordError および RecordWarning に変更することにしました。古いシグネチャは非推奨とマークされており、（文字列コピーのために）わずかに効率が低下しますが、それ以外の場合は引き続き機能します。Add* メソッドは後の破壊的リリースで削除されるため、これらを新しいバージョンに移行する必要があります。