移行ガイド

ライブラリの各バージョンで行われた破壊的変更と、それに合わせてコードを更新する方法のリストです。

v30.0での変更点

以下は、ライブラリの各バージョンで行われた破壊的変更と、それに合わせてコードを更新する方法のリストです。

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

CMakeサブモジュールをFetched Depsに置き換え

以前は、デフォルトの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*

NULL許容の場合、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()

マップまたはセットへの挿入

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...)

マップまたはセットのルックアップ

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のポイズニング

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

代替: アリーナに移行してください（移行ガイド）。

API: JsonOptions

代替: JsonPrintOptions

C++14のサポート終了

Foundational C++サポートマトリックスに従い、このリリースではC++14の最小サポートバージョンを廃止し、C++17に引き上げました。

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

アリーナ上のOneofメッセージをクリアした後のASANポイズニングの導入

この変更により、アリーナを使用するC++ protobufに影響を与える強化チェックが追加されました。protobufアリーナに割り当てられたOneofメッセージは、デバッグモードではクリアされ、ASANモードではポイズニングされます。クリアを呼び出した後、将来そのメモリ領域を使用しようとすると、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のフィールドセッターは、Edition 2023で閉じられたenumを検証するようになりました。無効な値で更新された閉じられたenumフィールドはエラーを生成します。

非推奨のpy_proto_libraryマクロを削除

非推奨の内部py_proto_library Bazelマクロがprotobuf.bzlから削除されました。これは、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

代替

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

マップフィールドに対するPython setdefault動作の変更

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

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

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

例:

これはObjective-Cにとって最初の破壊的リリースです。

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はメジャーバージョンを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が用意されています。

GPBFileDescriptor

非推奨APIの削除

少なくとも1つのマイナーリリースまたはメジャーリリースで非推奨とマークされていた以下の公開ランタイムAPIを削除しました。

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: +[GPBFileDescriptor allocDescriptorForClass:rootClass:file:fields:fieldCount:storageSize:flags:]

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

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

API: -[GPBExtensionDescriptor initWithExtensionDescription:]

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

新しいローリングアップグレードポリシーの下で機能するが、次のメジャーバージョンアップで動作しなくなる古いGencodeと新しいランタイムの組み合わせについて、ポイズンピルが警告を発するように更新しました。例えば、Python 4.x.xのGencodeは5.x.xランタイムに対して機能しますが、6.x.xランタイムに対しては今後の互換性破損について警告を発します。

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

ポイズンピルの警告

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

C#とRubyにおけるUTF-8強制の変更

JSON仕様に従い、数値フィールド内の文字列のJSON解析における非準拠を修正しました。

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

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

変更元: PR #11349, PR #10750

v22.0におけるコンパイラの変更点

JSONフィールド名の競合

JSONマッピングにおけるフィールド名の競合の処理方法にいくつかの微妙な変更を加えました。proto3では、制限を部分的に緩和し、フィールド名が大文字と小文字を区別するJSONマッピング（元の名前のキャメルケース）を生成する場合にのみエラーを出すようにしました。また、json_nameオプションもチェックし、大文字と小文字を区別する競合についてはエラーを出すようにしました。proto2では、制限を少し厳しくし、2つのjson_name指定が競合する場合はエラーを出すようにします。暗黙的なJSONマッピング（キャメルケース）に競合がある場合は、proto2で警告を出します。

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

4.22.0には、8月に発表されたC++ランタイムとprotocに対する破壊的変更が含まれています。

v22.0におけるC++ APIの変更点

変更元: PR #10132

Autotoolsの廃止

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

変更元: PR #10416

Abseilの依存関係

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

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

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

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

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

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();
}

例2: マクロ展開の防止

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

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

変更元: PR #10796

変更後

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

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)();
}

C++20のサポート

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

変更元: PR #11604

Finalクラス

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

変更元: PR #11550

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

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

変更元: PR #11588, PR #11639

クリアされた要素の非推奨化

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

変更元: PR #10325

UnsafeArenaの非推奨化

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

変更元: PR #11625

Map Pairのアップグレード

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

変更元: PR #10729

新しいJSONパーサー

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

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

変更元: PR #10623

Arena::Init

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

変更元: PR #11555

ErrorCollectorの移行

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

© 2025 Google LLC All Rights Reserved プライバシーポリシー GitHub Pagesでホストされています。 GitHubプライバシーステートメント