Bump libdatadog to 36.0.0.1.0

[lloeki]

What does this PR do?

Bumps the libdatadog dependency from ~> 35.0.0.1.0 to ~> 36.0.0.1.0, in
datadog.gemspec and the matching LIBDATADOG_VERSION constant in
ext/libdatadog_extconf_helpers.rb (kept in sync by
spec/datadog/core/libdatadog_extconf_helpers_spec.rb), and updates all
gemfiles/*.lock plus tools/yard.gemfile.lock to match.

Motivation:

Pick up the libdatadog 36.0.0 release.

Change log entry

None. (Internal dependency bump; no user-visible behavior change.)

Additional Notes:

• The bump mirrors Bump libdatadog to 35.0.0 #5859 and is split into separate commits:
  • Bump libdatadog to 36.0.0.1.0 — gemspec + extconf constant + all
    gemfiles/*.lock (constraint, resolved version, per-platform specs) plus the
    refreshed sha256 checksums in the one lockfile that records a CHECKSUMS
    section, using the values published on RubyGems.org.
  • Update YARD lockfile for libdatadog 36.0.0.1.0 — tools/yard.gemfile
    inherits the gemspec via gemspec path: '..', and yard.yml runs with
    BUNDLE_FROZEN=true, so its frozen lockfile must pin the same version.
• gemfiles/*.lock are updated in this PR (not left to the bot). Since Use frozen lockfiles in CI #5831
  made CI use frozen lockfiles, the pinned libdatadog version must already
  match in every lockfile or bundle install fails.

Known issue + temporary stopgap

libdatadog v36's vendored common.h regressed its header dedup and now ships
duplicate typedefs (forward + full-struct collisions for
ddog_prof_EncodedProfile, ddog_prof_StringId, OpaqueStringId, and
exact-duplicate opaque typedefs for ddog_prof_StringId2,
ddog_prof_MappingId2, ddog_prof_FunctionId2). These are benign at runtime,
but under DATADOG_GEM_CI=true the native extensions compile with -Werror,
so the -Wtypedef-redefinition (C11) warnings become fatal and break
crashtracker.o in both the libdatadog_api and profiling native extensions.

As a temporary stopgap, the final commit appends
-Wno-error=typedef-redefinition (keeping it a warning, not an error) to the
affected extconfs, gated on DATADOG_GEM_CI like the -Werror it relaxes. A
proper fix — restoring the header dedup so common.h no longer emits duplicate
typedefs — is being pursued upstream in libdatadog / libdatadog-rb; this
suppression should be removed once a fixed header ships.

• AI was used to accelerate implementation; all code was reviewed and understood.

How to test the change?

CI (36.0.0.1.0 is published to RubyGems.org). Locally:
DATADOG_GEM_CI=true bundle exec rake clean compile — fails with fatal
-Wtypedef-redefinition errors after the bump-only commits, and succeeds after
the stopgap commit.

Note

One of three coordinated changes for the libdatadog v36 duplicate-typedef header issue (increasing order of permanence):

• This PR (dd-trace-rb#5928) — immediate CI mitigation: bump to v36 plus a temporary -Wno-error=typedef-redefinition stopgap.
• libdatadog-rb#62 — gem-level fix: strip the duplicate typedefs during vendoring and ship 36.0.0.1.1, without waiting for a libdatadog release. Once consumed, the stopgap here can be dropped.
• libdatadog#2149 — upstream fix in dedup_headers: makes common.h clean by construction; the durable fix.

[datadog-prod-us1-4]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 90.03% (+0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: cb494a1 | Docs | Datadog PR Page | Give us feedback!}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-06-24 12:05:43

Comparing candidate commit cb494a1 in PR branch lloeki/bump-libdatadog-36 with baseline commit 63e6998 in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 48 metrics, 1 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

[lloeki]

Rebased, hoping to get rid of that unrelated failure.

[lloeki]

Root cause

libdatadog v36 intentionally changed FFE semantics: an invalid/unsupported per-flag config now resolves to caller-default instead of error.

• libdatadog #2109 fix(ffe): honor shared fixture result metadata (commit c79d783f7) adds EvaluationError::FlagConfigurationInvalid, mapped in datadog-ffe-ffi/src/assignment.rs to Reason::Default + ErrorCode::Ok (was Reason::Error + ParseError). Shared fixtures bumped via ffe-system-test-data#15.
• The OpenFeature provider just surfaces libdatadog's result (ext/libdatadog_api/feature_flags.c → ddog_ffe_*), so the bump 35→36 changes the reported reason.

Effect

System tests tests/ffe/test_flag_eval_metrics.py::Test_FFE_Eval_Metric_Parse_Error_Invalid_Regex and ::Test_FFE_Eval_Metric_Parse_Error_Variant_Type_Mismatch still assert reason == "error" / error.type == "parse_error", but v36 now returns reason: default. Fails only on rails72 (the only weblog running the FFE scenario).

• Green on master (libdatadog 35), red on the v36 bump branch — same system-tests ref 153bc29.
• main of system-tests is not updated for the new behavior (lines 780/831 still expect error), so there's no newer ref to bump to.

Action

Not a dd-trace-rb or libdatadog defect — system-tests must be updated to the v36 caller-default semantics (owned by FFE team, mirroring ffe-system-test-data#15). Until then, either update/relax those two tests or gate them off for the Ruby weblog so the libdatadog 36 bump can land.

[dd-octo-sts]

Typing analysis

Note: Ignored files are excluded from the next sections.

Untyped methods

This PR introduces 2 partially typed methods, and clears 1 partially typed method. It decreases the percentage of typed methods from 65.53% to 65.52% (-0.01%).

Partially typed methods (+2-1)

❌ Introduced:

sig/datadog/open_feature/native_evaluator.rbs:10
└── def get_assignment: (
        ::String flag_key,
        default_value: untyped,
        context: ::OpenFeature::SDK::EvaluationContext::fields_t,
        expected_type: ::Symbol
      ) -> (Core::FeatureFlags::ResolutionDetails | ResolutionDetails)
sig/datadog/open_feature/native_evaluator.rbs:21
└── def invalid_flag_configuration_error: (untyped default_value) -> ResolutionDetails

✅ Cleared:

sig/datadog/open_feature/native_evaluator.rbs:8
└── def get_assignment: (
        ::String flag_key,
        default_value: untyped,
        context: ::OpenFeature::SDK::EvaluationContext::fields_t,
        expected_type: ::Symbol
      ) -> Core::FeatureFlags::ResolutionDetails

If you believe a method or an attribute is rightfully untyped or partially typed, you can add # untyped:accept on the line before the definition to remove it from the stats.