Skip to content

[skia-sync] Merge upstream Skia main (tip)#4263

Closed
mattleibow wants to merge 3 commits into
mainfrom
skia-sync/main
Closed

[skia-sync] Merge upstream Skia main (tip)#4263
mattleibow wants to merge 3 commits into
mainfrom
skia-sync/main

Conversation

@mattleibow

Copy link
Copy Markdown
Contributor

Automated bleeding-edge sync from the tip of upstream Skia (google/skia main).

Companion skia PR: mono/skia#269

SkiaSharp tip-merge sync — mainskia-sync/main

Automated sync via auto-skia-sync workflow.

Summary

Field Value
Base branch main @ 0d83945c9
Submodule before mono/skia @ b16789ec3540beaa43e8a71b050d9d328eb68025 (skiasharp)
Submodule after mono/skia @ b38065ae120a8c5cef6ecd54d18f128429a65866 (skia-sync/main)
Upstream merge commit google/skia main @ 6d89b67e641382d98c3b0eaa693b023b9b5c4f56
Upstream commits merged 303

⚠ Milestone boundary crossed

The workflow was scheduled as a main (tip) sync with CURRENT == TARGET == 150,
which is normally not a version bump. However, upstream main has moved past
the m150 → m151 milestone boundary (#define SK_MILESTONE 151 in
include/core/SkMilestone.h). The native build aborts when the milestone in
SkMilestone.h does not match scripts/VERSIONS.txt, so this sync does bump
the SkiaSharp version line:

  • scripts/VERSIONS.txt: milestone 150 → 151, soname 150.0.0 → 151.0.0, all 4.150.0 → 4.151.0
  • scripts/azure-templates-variables.yml: SKIASHARP_VERSION 4.150.0 → 4.151.0
  • cgmanifest.json: chrome_milestone 150 → 151, version "chrome/m150" → "chrome/m151",
    commitHash, upstream_merge_commit
  • SK_C_INCREMENT: unchanged (0) — no new C API functions in this sync

This is effectively a m150 → m151 milestone bump even though it was scheduled as
a tip-mode sync. The companion mono/skia PR is chrome/m151-equivalent.

Build args changed (cross-platform impact)

Upstream Skia's BUILD.gn now imports //src/partition_alloc unconditionally, but
our DEPS does not vendor the third_party/externals/partition_alloc source tree.
Per skill Phase 7 / gotcha #23,
a required upstream gn arg goes in native/**/build.cake, not a one-off
--gnArgs flag, and must be applied to every clang platform.

skia_use_partition_alloc=false added to:

  • native/android/build.cake
  • native/ios/build.cake
  • native/linux/build.cake (both libSkiaSharp and libHarfBuzzSharp targets)
  • native/macos/build.cake
  • native/tizen/build.cake
  • native/tvos/build.cake
  • native/wasm/build.cake (both libSkiaSharp and libHarfBuzzSharp targets)
  • native/windows/build.cake

(native/{linuxnodeps,maccatalyst,linux-clang-cross,nanoserver,winui,winui-angle}/build.cake
delegate to one of the above, so they inherit the flag automatically.)

Only the Linux x64 native build was exercised here — the other clang platforms
need human verification that the same flag is sufficient (it should be: the failure
is from BUILD.gn's top-level partition_alloc import, which is platform-independent).

C API changes

  • externals/skia/src/c/sk_font.cpp: #include "include/private/base/SkTemplates.h"
    #include "include/private/SkTemplates.h" (upstream d2b9e48baf header move).

This is the only C API change in this sync. Committed in the submodule as
b38065ae12.

Breaking-change analysis

  • C API: No signature changes. Regenerated binding/SkiaSharp/SkiaApi.generated.cs
    produced zero diff (git diff --stat -- binding/ was empty).
  • C# wrappers: No changes required — no new functions to wrap.
  • ABI: Stable; soname bumped 150.0.0 → 151.0.0 as expected for a milestone bump.

Build & test results (Linux x64)

Step Result
dotnet cake --target=externals-linux --arch=x64 libSkiaSharp.so.151.0.0 + libHarfBuzzSharp.so.0.61421.0 produced
pwsh utils/generate.ps1 (via regenerate-bindings.ps1) ✅ no binding diff
dotnet build binding/SkiaSharp/SkiaSharp.csproj ✅ 0 warnings, 0 errors
dotnet test tests/SkiaSharp.Tests.Console/... 5571 passed, 0 failed, 172 skipped (2m 43s)

Full test log uploaded as test-output.txt artifact.

Items needing human attention

  1. Milestone boundary — this PR effectively bumps SkiaSharp to m151 even though
    the workflow was triggered as a tip-mode sync. Please confirm the version line
    is the intended direction (alternative would be to skip this sync until upstream
    cuts a chrome/m151 branch and run a proper milestone-bump workflow).
  2. skia_use_partition_alloc=false added to 8 platforms × 2 targets (Skia + HarfBuzz)
    but only Linux x64 was exercised. Please verify Android, iOS, macOS, MacCatalyst,
    tvOS, tizen, wasm and Windows still build via CI before merging.
  3. bazel/external/dawn/dawn_files.bzl deletion in the submodule — informational
    (we do not build via Bazel), but noted in the mono/skia PR.
  4. 303 upstream commits — large diff, please review for any
    behavioural/API changes that should be called out in release notes.

Created by skia-upstream-sync.

Merge google/skia main HEAD (6d89b67e64) into the skiasharp fork.
Upstream main has crossed the m150 -> m151 milestone boundary, so this
sync also bumps the SkiaSharp version line (libSkiaSharp / nuget) to 151.

Submodule:  b16789ec35..b38065ae12 (mono/skia, skia-sync/main)
Upstream merge commit: 6d89b67e641382d98c3b0eaa693b023b9b5c4f56
SK_C_INCREMENT: 0 (no new C API functions in this sync)

Build args:
- Added 'skia_use_partition_alloc=false' to every clang/gn build.cake
  (android, ios, linux, macos, tizen, tvos, wasm, windows) plus the
  linux/wasm libHarfBuzzSharp targets. Required because upstream Skia
  now imports //src/partition_alloc unconditionally from BUILD.gn, and
  our DEPS does not vendor the third_party/externals/partition_alloc
  source tree.

Only the Linux x64 native build was exercised in CI; the other clang
platforms inherit the same flag for cross-platform consistency and
need human verification.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@github-actions

Copy link
Copy Markdown
Contributor

📦 Try the packages from this PR

Warning

Do not run these scripts without first reviewing the code in this PR.

Step 1 — Download the packages

bash / macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/mono/SkiaSharp/main/scripts/get-skiasharp-pr.sh | bash -s -- 4263

PowerShell / Windows:

iex "& { $(irm https://raw.githubusercontent.com/mono/SkiaSharp/main/scripts/get-skiasharp-pr.ps1) } 4263"

Step 2 — Add the local NuGet source

dotnet nuget add source ~/.skiasharp/hives/pr-4263/packages --name skiasharp-pr-4263
More options
Option Description
--successful-only / -SuccessfulOnly Only use successful builds
--force / -Force Overwrite previously downloaded packages
--list / -List List available artifacts without downloading
--build-id ID / -BuildId ID Download from a specific build

Or download manually from Azure Pipelines — look for the nuget artifact on the build for this PR.

Remove the source when you're done:

dotnet nuget remove source skiasharp-pr-4263

@github-actions

Copy link
Copy Markdown
Contributor

📖 Documentation Preview

The documentation for this PR has been deployed and is available at:

🔗 View Staging Site
🔗 View Staging Docs
🔗 View Staging Gallery (Blazor)
🔗 View Staging Gallery (Uno Platform)
🔗 View Staging SkiaFiddle

This preview will be updated automatically when you push new commits to this PR.


This comment is automatically updated by the documentation staging workflow.

Merge google/skia main HEAD (e47bb0549c) into the skiasharp fork on top
of the existing skia-sync/main branch. The previous tip merge stopped
at 6d89b67e64; upstream main has advanced by 2 trivial commits:

* 63c19a2761 Migrate SkIcoCodec to generic registry-based APIs
* e47bb0549c Roll recipe dependencies (trivial)

Neither touches the C API, BUILD.gn, DEPS, or any header consumed by
the binding generator, so:

* SK_MILESTONE remains 151 (no version bump)
* SkiaApi.generated.cs / SkottieApi.generated.cs / SceneGraphApi.generated.cs
  / ResourcesApi.generated.cs are unchanged after regeneration
* No new gn args required
* SK_C_INCREMENT stays at 0

Submodule:  b38065ae12..be3b5cac3a (mono/skia, skia-sync/main)
Upstream merge commit: e47bb0549c20841e6c5681d1890d0436e3d5ecf8

Built and tested on Linux x64 only (libSkiaSharp.so.151.0.0 +
libHarfBuzzSharp.so.0.61421.0). Full test suite: 5571 passed,
172 skipped, 0 failed (2m 49s). Other clang platforms inherit the
existing skia_use_partition_alloc=false flag from the previous tip
merge and were not exercised in this CI run.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
mattleibow added a commit that referenced this pull request Jun 29, 2026
…ne skill, honest run signal (#4258)

Harden Skia upstream-sync: conflict policy, durable gn args, standalone skill, honest run signal (#4258)

Follow-up to the mode=main tip work (#4254) and release-line targeting
(#4239). The first real tip runs exposed three rough edges in the
auto-skia-sync automation, plus that key Skia-update knowledge lived only
in the workflow prompt where the update-skia skill couldn't reach it.

~~ Verify-upstream-or-reapply conflict resolution ~~

A tip merge runs ~291 commits ahead of our submodule base and conflicts on
every file carrying an [M1xx] fork cherry-pick. The old "keep ours / resolve
what you reasonably can" guidance risked silently dropping a not-yet-
upstreamed patch (--theirs) or freezing a stale form of one upstream had
since refined (--ours; e.g. our SDF-LCD patch used getMaxScale() while
upstream relanded it as sk_ieee_float_divide(1.f, getMinScale())).

Replace it with an explicit, auditable policy: classify each fork patch on a
conflicted file as upstreamed (take upstream's form, record the SHA) or not
upstreamed (re-apply ours on top) -- never a blanket --theirs/--ours, never
a silent drop. A mandatory before-merge fork-patch snapshot is cross-checked
so every patch lands in the resolution table as upstreamed or re-applied; a
patch that is neither is a lost patch -> stop and fix. Applied across gotcha
#15, SKILL.md Phase 5, and the workflow tip note.

~~ Allow a required new gn arg through build.cake ~~

The tip build needed skia_use_partition_alloc=false because upstream now
defaults it to is_clang while our DEPS deliberately omits partition_alloc;
Skia ships an official zero-overhead noop raw_ptr for exactly this case, so
=false is the supported embedder path, not a hack. The rule banned all
build.cake edits, forcing a one-off --gnArgs CLI flag and leaving durable
config non-durable.

Split the rule into two tiers: still forbid changing compiler/linker flags
(or scripts/infra/native/**) to silence a host build error, but allow adding
a genuinely required new upstream gn arg to the affected platforms'
native/**/build.cake gn-args lists, flagged in both PR summaries for cross-
platform review. Sequencing is honored: the toggle doesn't exist in m150, so
the relaxed rule lets the next milestone merge add it in-context rather than
breaking the current build. Recommendation for the eventual bump (gotcha #23):
keep partition_alloc disabled via the supported noop, not by vendoring the
Chromium allocator.

~~ Make the skill standalone; reduce the workflow to CI overrides ~~

main/tip mode and the required-new-gn-arg rule were documented only in the
workflow prompt, so the update-skia skill couldn't drive them locally. Move
both into the skill: tip mode becomes a first-class third option in Phase 1
(new {UPSTREAM_REF} variable, merge-base..upstream/main milestone diffs,
generalized Phase 5 merge command), and the gn-arg rule lands in Phase 7
backed by gotcha #23. Trim the workflow's duplicated build.cake/mode prose to
short pointers, keeping only genuinely CI-specific guardrails (can't apt-
install in the sandbox; a missing host dep is a workflow bug, not a flag hack;
Linux-only-build cross-platform review). These are prompt-body edits, so the
lock stays byte-identical.

~~ Stop mislabeling a real sync as a no-op ~~

A sync that merged upstream, built, tested, and opened both PRs was reported
by the gh-aw conclusion job as a no-op, which then failed trying to file a
no-op issue (the workflow has no issues: write). Cause: safe-outputs staged
mode blocks the agent from creating anything directly -- the real PRs are
opened by the host post-step skia-sync-push-prs.sh with the autobump token --
so noop was the agent's only completion signal and every run, real or not,
signalled noop.

Give the agent an honest signal: declare create-pull-request in safe-outputs,
kept staged (preview-only; the safe_outputs job is ubuntu-slim with
permissions:{} and never touches the workspace) so a real sync registers as a
pull-request output, while real PRs still come only from the post-step. Set
noop: report-as-issue: false so noop is reserved for genuine no-work runs and
no longer files an uncreatable issue; drop the unused create_issue offer; and
add a "Completion signal" section to the prompt. This is the one frontmatter
edit in the PR, so auto-skia-sync.lock.yml is regenerated.

Validated end-to-end by run 28269474099 (mode=main, real 2-commit merge): the
agent emitted a staged create_pull_request, the conclusion logged no noop with
no failed issue step, and the post-step still pushed skia-sync/main to both
repos and updated the real PRs (#4263 + #269). Rebased on main to pick up the
#4260 workflow rename (lock recompiled to a 0-diff) and confirm consistency
with the #4267 support-status model.

Co-authored-by: Matthew Leibowitz <mattleibow@live.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Submodule advances be3b5cac3a..f1e0d6e222 (merge) and brings in upstream/main
tip up to 94dd812d73 ("Roll recipe dependencies (trivial).").

Notable changes:
- Mostly recipe rolls and dependency rolls (vulkan-deps, etc.)
- [graphite] Signal identity sRGB curve, PreAlpha+PostAlpha shader logic
- [codecs] Fix potential overflow in SkBmpRLECodec
- New SkFont::breakText overloads, SkRefCnt::getRefCount, SkTextBlob
  optional bounds param (all ABI-safe additions, no C# wrapper changes)
- New file src/gpu/graphite/sparse_strips/StripProcessorSimd.h
  (Graphite-only, not in our libSkiaSharp build path)

DEPS conflict: resolved with --ours (fork pins preserved for brotli @028fb5a23661
and all commented-out fork deps — angle2, dawn, abseil-cpp, etc.). No upstream
changes were lost.

No version bump (CURRENT == TARGET == 150 tip mode, milestone already at 151
from prior auto-sync). SK_C_INCREMENT unchanged. Bindings regenerated with no
diff. C# build + tests pass (5571/5743, 172 skipped for missing hardware).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@mattleibow mattleibow closed this Jun 30, 2026
@mattleibow
mattleibow deleted the skia-sync/main branch June 30, 2026 00:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant