Improve multi-compiler support in the build system by adding a SolidityCompilerConfig base interface by marianfe · Pull Request #8008 · NomicFoundation/hardhat

marianfe · 2026-02-25T23:01:16Z

Summary

This change introduces compiler-agnostic base interfaces: SolidityCompilerConfig, SolidityCompilerUserConfig and SolidityCompilerType, with a new type property to distinguish between compilers e.g. when downloading/injecting settings/getting the compiler/invoking compilation.

Note: This PR also introduces a new pattern to add post-validation hooks after a config has been resolved. We need this because we need to validate that all compiler entries in the config have been 'claimed' by an existing plugin (either the built-in solc, or other plugins) and that no remaining compiler types are 'orphaned' (e.g. due to typos).

This is the first change in a series of PRs to introduce support for solx in Hardhat 3. In later PRs, the type property will be used to split handling of downloads, settings/extra args, and compilation invocation between the current built-in solc pipeline, and a new solx compilation path (which will be made available via a plugin).

Details

SolcUserConfig/SolcConfig extend the base types, preserving backward compatibility.
Export spawnCompile() and isSolcConfig() for plugin reuse (will be used in a later PR)
Widen invokeSolc hook parameter from SolcConfig to SolidityCompilerConfig
Add zod schema type field for runtime validation

This is a backward compatible change for Hardhat users, and a mostly backward compatible change for plugin authors - it is strictly backward compatible at runtime, although at build time there is a less likely minor type-level breaking change: invokeSolc hook parameter widens from SolcConfig to SolidityCompilerConfig. Existing handlers compile and run without changes. Plugins accessing preferWasm should use the isSolcConfig() type guard.

Currently no plugins seem to actually use preferWasm, this property is only used in hardhat core for the current solc pipeline.

changeset-bot · 2026-02-25T23:01:24Z

🦋 Changeset detected

Latest commit: f344087

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
hardhat	Patch
@nomicfoundation/hardhat-errors	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Copilot

Pull request overview

This PR introduces compiler-agnostic Solidity compiler config base interfaces (SolidityCompilerConfig / SolidityCompilerUserConfig) with a type discriminator to support multiple compiler implementations (e.g. future solx integration) while keeping SolcConfig backwards compatible.

Changes:

Add SolidityCompilerConfig/SolidityCompilerUserConfig base interfaces with optional type, and widen relevant hook/config types to use the base interface.
Export isSolcConfig() type guard and spawnCompile() for plugin reuse via a new hardhat/internal/solidity export path.
Relax custom compiler version parsing to accept plain semver, add tests, and update config resolution tests to cover type behavior.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
v-next/hardhat/src/internal/builtin-plugins/solidity/type-extensions.ts	Introduces base compiler config/user config interfaces and widens hook/config types to compiler-agnostic ones.
v-next/hardhat/src/internal/builtin-plugins/solidity/config.ts	Adds `type` runtime validation and resolves configs via the new base compiler config shape.
v-next/hardhat/src/internal/builtin-plugins/solidity/build-system/build-system.ts	Adds `isSolcConfig` guard and adjusts preferWasm/version validation logic for generalized compiler configs.
v-next/hardhat/src/internal/builtin-plugins/solidity/build-system/solc-config-selection.ts	Widens selector return type from `SolcConfig` to `SolidityCompilerConfig`.
v-next/hardhat/src/internal/builtin-plugins/solidity/build-system/compiler/index.ts	Extends custom compiler `--version` parsing to accept plain semver and synthesize a long version.
v-next/hardhat/src/internal/builtin-plugins/solidity/build-system/compiler/compiler.ts	Exports `spawnCompile` for reuse.
v-next/hardhat/src/internal/builtin-plugins/solidity/exports.ts	Adds internal re-exports (`isSolcConfig`, `spawnCompile`) for plugin consumption.
v-next/hardhat/src/types/solidity/compilation-job.ts	Updates compilation job typing/docs to use the compiler-agnostic config type.
v-next/hardhat/package.json	Adds the `./internal/solidity` package export.
v-next/hardhat/test/internal/builtin-plugins/solidity/config.ts	Adds tests for `type` validation/resolution and `isSolcConfig`.
v-next/hardhat/test/internal/builtin-plugins/solidity/hooks.ts	Updates hook typing in tests to accept `SolidityCompilerConfig`.
v-next/hardhat/test/internal/builtin-plugins/solidity/build-system/compilation-job.ts	Updates test typing to `SolidityCompilerConfig`.
v-next/hardhat/test/internal/builtin-plugins/solidity/build-system/compiler/version-parsing.ts	Adds unit tests for the updated version parsing behavior.
.changeset/cold-deer-buy.md	Adds a patch changeset entry for the new abstraction/export surface.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

v-next/hardhat/src/internal/builtin-plugins/solidity/build-system/build-system.ts

Copilot · 2026-02-25T23:15:43Z

v-next/hardhat/src/internal/builtin-plugins/solidity/config.ts

+  // Resolve solc-specific preferWasm if this is a SolcUserConfig
+  if (isSolcUserConfig(compilerConfig)) {
+    // Resolve per-compiler preferWasm:
+    // If explicitly set, use that value.
+    // Otherwise, for ARM64 Linux in production, default to true only for


resolveSolidityCompilerConfig drops solc-only fields like preferWasm when type is non-solc, but the current zod schema still allows preferWasm on any compiler entry. This can silently ignore user config mistakes (e.g. type: "solx" with preferWasm: true). Consider making the per-compiler schema conditional: only allow preferWasm when type is undefined/"solc", and reject it for other type values.

Copilot

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 4 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-03-05T15:33:45Z

v-next/hardhat/package.json

+    "./internal/coverage": "./dist/src/internal/builtin-plugins/coverage/exports.js",
+    "./internal/gas-analytics": "./dist/src/internal/builtin-plugins/gas-analytics/exports.js",
+    "./internal/solidity": "./dist/src/internal/builtin-plugins/solidity/exports.js",


The package.json exports map now includes "./internal/coverage" and "./internal/gas-analytics" pointing at dist/src/internal/builtin-plugins/{coverage,gas-analytics}/exports.js, but there are no corresponding source entrypoints (exports.ts) in those directories. This will produce broken package exports at publish/build time unless those files are added or the export targets are updated to existing built artifacts (e.g. index.js).

Suggested change

"./internal/coverage": "./dist/src/internal/builtin-plugins/coverage/exports.js",

"./internal/gas-analytics": "./dist/src/internal/builtin-plugins/gas-analytics/exports.js",

"./internal/solidity": "./dist/src/internal/builtin-plugins/solidity/exports.js",

"./internal/coverage": "./dist/src/internal/builtin-plugins/coverage/index.js",

"./internal/gas-analytics": "./dist/src/internal/builtin-plugins/gas-analytics/index.js",

"./internal/solidity": "./dist/src/internal/builtin-plugins/solidity/index.js",

I wouldn't pay attention to this comment, LGTM

Copilot · 2026-03-05T15:33:46Z

v-next/hardhat/src/internal/builtin-plugins/solidity/config.ts

+    type: compilerConfig.type,
+    version: compilerConfig.version,
+    settings: resolvedSettings,
+    path: compilerConfig.path,


For non-"solc" compiler types the zod schema allows arbitrary extra fields via .passthrough(), but resolveSolidityCompilerConfig reconstructs a new object with only { type, version, settings, path }, dropping any plugin-defined fields from the resolved config. If plugins are expected to add compiler-specific options (as implied by passthrough), those options won’t be available later in the build pipeline. Consider preserving unknown fields (e.g. by spreading the original config and overriding settings with the merged value) for non-solc types.

Suggested change

type: compilerConfig.type,

version: compilerConfig.version,

settings: resolvedSettings,

path: compilerConfig.path,

...compilerConfig,

settings: resolvedSettings,

This comment is irrelevant, because we have our own resolution. This change looks good to me.

Copilot · 2026-03-05T15:33:46Z

v-next/hardhat/src/internal/builtin-plugins/solidity/build-system/solc-config-selection.ts

  public selectBestSolcConfigForSingleRootGraph(
    subgraph: DependencyGraph,
-  ): { success: true; config: SolcConfig } | CompilationJobCreationError {
+  ):
+    | { success: true; config: SolidityCompilerConfig }
+    | CompilationJobCreationError {


SolcConfigSelector now returns a generic SolidityCompilerConfig, but selection is still based only on version and doesn’t consider type. If a build profile contains multiple compiler types (or two configs share the same version but different types), the selected config can be ambiguous/non-deterministic. Consider either validating that each build profile is single-compiler-type for now, or including type as part of the selection/identity logic (and any tie-breaking).

This is an interesting point. But the whole selector class works with a single build profile. It will return the right SolidityCompilerConfig based either on the version matching logic, or overrides.

Copilot isn't aware that we only have a single compiler config per version, so the situation of matching the same version but different types is not possible.

However, we should make sure that we are considering the type when merging compilation jobs.

However, we should make sure that we are considering the type when merging compilation jobs.

Self-answer: we merge by SolidityCompilerConfig identity, not even value, so the type is taken into account.

Copilot · 2026-03-05T15:33:47Z

v-next/hardhat/src/internal/builtin-plugins/solidity/build-system/build-system.ts

    let subgraphsWithConfig: Array<
-      [SolcConfig, DependencyGraphImplementation]
+      [SolidityCompilerConfig, DependencyGraphImplementation]
    > = [];


subgraphsWithConfig now carries SolidityCompilerConfig, but the build-system logic downstream still treats compiler configs as solc-only (e.g. compiler metadata caches keyed by version, and getCompiler(version, { preferWasm, compilerPath })). With multiple compiler types this can conflate different compilers that share a version string and makes it easy to accidentally run the solc pipeline for non-solc configs. Consider incorporating type into cache keys / compiler selection, or rejecting mixed/non-solc compiler types until the build-system paths are properly split by type.

This is a very good point tbh

Yes, we would need to add type to CompileCacheEntry.

… interface

…e for the new type field

…gisteredCompilerTypes

Copilot

Pull request overview

Copilot reviewed 30 out of 30 changed files in this pull request and generated 7 comments.

Comments suppressed due to low confidence (1)

v-next/hardhat/src/internal/builtin-plugins/solidity/build-system/cache.ts:26

compilerType is required in CompileCacheEntry, but loadCache() can return entries from older cache files where this field is missing. Consider making compilerType optional in the type (and/or normalizing/migrating loaded entries) so the TypeScript type matches the runtime data shape and avoids unsafe assumptions elsewhere.

export interface CompileCacheEntry {
  jobHash: string;
  isolated: boolean;
  compilerType: string;
  buildInfoPath: string;
  buildInfoOutputPath: string;
  artifactPaths: string[];
  typeFilePath?: string;
  wasm: boolean;
}

You can also share your feedback on Copilot code review. Take the survey.

v-next/hardhat/src/internal/builtin-plugins/solidity/config.ts

+  ...incompatibleCompilerFields,
+});
+
+// This defintion needs to be aligned with solidityCompilerUserConfigType.


v-next/hardhat/src/internal/builtin-plugins/solidity/build-system/compilation-job.ts

+    const versionPart = this.solcConfig.version.replaceAll(".", "_");
+
+    // For non-solc compiler types, include the compiler type in the build ID.
+    // We keep the `solc-` prefix for all types to avoid breaking codepaths
+    // that look for it.
+    if (compilerType !== undefined && compilerType !== "solc") {
+      /* eslint-disable-next-line @typescript-eslint/restrict-template-expressions --
+        compilerType is `never` in the base type system (only "solc" is registered),
+        but plugins can extend SolidityCompilerConfigPerType to add new compiler types. */
+      return `solc-${versionPart}-${compilerType}-${jobHash}`;
+    }


v-next/hardhat/src/internal/builtin-plugins/solidity-test/edr-artifacts.ts

-const BUILD_INFO_FORMAT =
-  /^solc-(?<major>\d+)_(?<minor>\d+)_(?<patch>\d+)-[0-9a-fA-F]*$/;
+export const BUILD_INFO_FORMAT: RegExp =
+  /^solc-(?<major>\d+)_(?<minor>\d+)_(?<patch>\d+)(?:-(?<compilerType>[a-zA-Z][a-zA-Z0-9]*))?-[0-9a-fA-F]*$/;


.changeset/five-experts-beg.md

+"hardhat": patch
+---
+
+Add an compilerType field to the `SolidityBuildInfo` and their ids. Where undefined/not-present means "solc". ([#8008](https://github.com/NomicFoundation/hardhat/pull/8008))


v-next/hardhat/src/internal/builtin-plugins/solidity/config.ts

-  "Expected a string or an array of strings",
-);
+/**
+ * The top-level type SolidityUserConfig is a unition type too complex for


v-next/hardhat/src/internal/builtin-plugins/solidity/config.ts

+ * `compilers` field.
+ */
+const incompatibleCompilerFields = {
+  type: incompatibleFieldType("This field is incompatible with `profiles`"),


v-next/hardhat/src/internal/builtin-plugins/solidity/config.ts

+const commonSolidityCompilerUserConfigFields = {
+  type: z.string().optional(),
  version: z.string(),
  settings: z.any().optional(),
  path: z.string().optional(),
-  preferWasm: z.boolean().optional(),
-  compilers: incompatibleFieldType("This field is incompatible with `version`"),
-  overrides: incompatibleFieldType("This field is incompatible with `version`"),
-  profiles: incompatibleFieldType("This field is incompatible with `version`"),
-});
+};


alcuadrado

🚀

Copilot

Pull request overview

Copilot reviewed 30 out of 30 changed files in this pull request and generated 2 comments.

Copilot · 2026-03-23T10:09:12Z

v-next/hardhat/src/internal/builtin-plugins/solidity/build-system/compilation-job.ts

+      /* eslint-disable-next-line @typescript-eslint/restrict-template-expressions --
+        compilerType is `never` in the base type system (only "solc" is registered),
+        but plugins can extend SolidityCompilerConfigPerType to add new compiler types. */
+      return `solc-${versionPart}-${compilerType}-${jobHash}`;
+    }
+
+    return `solc-${versionPart}-${jobHash}`;
  }



compilerType is interpolated verbatim into the build id (solc-<version>-<compilerType>-<hash>). Because build ids are later used as filenames (e.g. artifacts/build-info/<buildId>.json), a compiler type containing path separators or extra dashes can create invalid/ambiguous ids and potentially unsafe paths. Consider validating/sanitizing compilerType before using it in the id (e.g. enforce an allowed pattern and throw a config validation error if it doesn’t match), or encode it so that it can’t contain /, .., or --delimiters.

Suggested change

/* eslint-disable-next-line @typescript-eslint/restrict-template-expressions --

compilerType is `never` in the base type system (only "solc" is registered),

but plugins can extend SolidityCompilerConfigPerType to add new compiler types. */

return `solc-${versionPart}-${compilerType}-${jobHash}`;

}

return `solc-${versionPart}-${jobHash}`;

}

const compilerTypeForId = this.#sanitizeCompilerTypeForBuildId(compilerType);

/* eslint-disable-next-line @typescript-eslint/restrict-template-expressions --

compilerType is `never` in the base type system (only "solc" is registered),

but plugins can extend SolidityCompilerConfigPerType to add new compiler types. */

return `solc-${versionPart}-${compilerTypeForId}-${jobHash}`;

}

return `solc-${versionPart}-${jobHash}`;

}

#sanitizeCompilerTypeForBuildId(compilerType: string): string {

// Restrict the compiler type used in build IDs to a safe subset of characters

// to avoid introducing path separators or ambiguous delimiters into filenames.

// This keeps behavior unchanged for "normal" identifiers while safely

// normalizing any unexpected input.

return compilerType.replace(/[^A-Za-z0-9_]/g, "_");

}

Copilot · 2026-03-23T10:09:13Z

v-next/hardhat/src/internal/builtin-plugins/solidity/config.ts

+const commonSolidityCompilerUserConfigFields = {
+  type: z.string().optional(),
  version: z.string(),
  settings: z.any().optional(),
  path: z.string().optional(),
-  preferWasm: z.boolean().optional(),
-  compilers: incompatibleFieldType("This field is incompatible with `version`"),
-  overrides: incompatibleFieldType("This field is incompatible with `version`"),
-  profiles: incompatibleFieldType("This field is incompatible with `version`"),
-});
+};


The type discriminator is currently validated as an arbitrary string (type: z.string().optional()), but downstream the build id format and EDR parsing regex assume a restricted token-like compiler type. Without restricting/validating this field, users/plugins can create compiler types that yield build ids that can’t be parsed and/or aren’t safe as filenames (e.g. containing /, .., or -). Consider tightening the schema (and/or adding a resolved-config validation) to enforce a safe pattern for compiler types that matches the build id format.

github-actions bot added the status:triaging label Feb 25, 2026

github-actions bot assigned kanej Feb 25, 2026

marianfe changed the title ~~Introduce multi-compiler abstraction with SolidityCompilerConfig base interface~~ Introduce better multi-compiler support in the build system by adding SolidityCompilerConfig base interface Feb 25, 2026

marianfe changed the title ~~Introduce better multi-compiler support in the build system by adding SolidityCompilerConfig base interface~~ Introduce better multi-compiler support in the build system by adding a SolidityCompilerConfig base interface Feb 25, 2026

marianfe requested a review from Copilot February 25, 2026 23:10

Copilot started reviewing on behalf of marianfe February 25, 2026 23:10 View session

marianfe force-pushed the feat/solx-step1-core-multi-compiler branch from 9ecf615 to 43bb131 Compare February 25, 2026 23:12

Copilot AI reviewed Feb 25, 2026

View reviewed changes

marianfe added no docs needed This PR doesn't require links to documentation no peer bump needed labels Feb 26, 2026

marianfe force-pushed the feat/solx-step1-core-multi-compiler branch 5 times, most recently from 62da1a7 to 1cd6812 Compare February 26, 2026 09:01

marianfe mentioned this pull request Feb 26, 2026

Add downloadCompilers parallel hook for extensible compiler downloads #8009

Merged

marianfe force-pushed the feat/solx-step1-core-multi-compiler branch from 1cd6812 to 0f7deb7 Compare February 26, 2026 12:03

marianfe changed the title ~~Introduce better multi-compiler support in the build system by adding a SolidityCompilerConfig base interface~~ Introduce improved multi-compiler support in the build system by adding a SolidityCompilerConfig base interface Feb 26, 2026

marianfe changed the title ~~Introduce improved multi-compiler support in the build system by adding a SolidityCompilerConfig base interface~~ Improve multi-compiler support in the build system by adding a SolidityCompilerConfig base interface Feb 26, 2026

marianfe force-pushed the feat/solx-step1-core-multi-compiler branch 2 times, most recently from d004fe7 to 7cade07 Compare March 4, 2026 12:27

Copilot AI review requested due to automatic review settings March 5, 2026 15:26

Copilot started reviewing on behalf of marianfe March 5, 2026 15:27 View session

Copilot AI reviewed Mar 5, 2026

View reviewed changes

marianfe force-pushed the feat/solx-step1-core-multi-compiler branch 2 times, most recently from 5a48ee9 to 2fe6cb9 Compare March 5, 2026 15:44

Copilot AI review requested due to automatic review settings March 6, 2026 09:24

marianfe force-pushed the feat/solx-step1-core-multi-compiler branch from 2fe6cb9 to 5b313d0 Compare March 6, 2026 09:24

Copilot started reviewing on behalf of marianfe March 6, 2026 09:24 View session

kanej removed their request for review March 9, 2026 09:40

kanej mentioned this pull request Mar 9, 2026

Integrated solx into test builds #7971

Open

4 tasks

marianfe mentioned this pull request Mar 16, 2026

Step 2: Add downloadCompilers parallel hook marianfe/hardhat-fork#2

Open

marianfe added 6 commits March 16, 2026 19:11

Introduce multi-compiler abstraction with SolidityCompilerConfig base…

6fb3c27

… interface

Refactor version parsing, add conditional zod schema for preferWasm

a015127

Address design doc comment: type-safe, extensible SolidityCompilerTyp…

ddd6566

…e for the new type field

Revert version regex fallback, add validateResolvedConfig hook and re…

db7c590

…gisteredCompilerTypes

Address PR review comments

1aab861

Address new PR comments — introduce mapped types and deprecate old ones

57d1075

marianfe force-pushed the feat/solx-step1-core-multi-compiler branch from 5544e68 to 5d68d88 Compare March 16, 2026 18:11

marianfe added 2 commits March 16, 2026 19:20

Address new PR comments — build system type awareness

ecb715b

Address new PR comments — config validation and error handling

1163e75

Copilot AI review requested due to automatic review settings March 16, 2026 18:23

marianfe force-pushed the feat/solx-step1-core-multi-compiler branch from 5d68d88 to 1163e75 Compare March 16, 2026 18:23

Copilot started reviewing on behalf of marianfe March 16, 2026 18:23 View session

Copilot AI reviewed Mar 16, 2026

View reviewed changes

Apply new PR comments: fix typos and error message in config validation

95d0f30

alcuadrado approved these changes Mar 20, 2026

View reviewed changes

Copilot AI review requested due to automatic review settings March 23, 2026 10:01

Copilot started reviewing on behalf of marianfe March 23, 2026 10:02 View session

Resolve merge conflicts

4238ea7

marianfe force-pushed the feat/solx-step1-core-multi-compiler branch from 127601c to 4238ea7 Compare March 23, 2026 10:03

Copilot AI reviewed Mar 23, 2026

View reviewed changes

Remove redundant changeset file

f344087

marianfe added this pull request to the merge queue Mar 23, 2026

Merged via the queue into main with commit 2e25edb Mar 23, 2026
249 checks passed

marianfe deleted the feat/solx-step1-core-multi-compiler branch March 23, 2026 11:23

github-actions bot mentioned this pull request Mar 23, 2026

Version Packages (v3) #8076

Merged

alcuadrado mentioned this pull request Mar 24, 2026

SolidityBuildSystem#compileBuildInfo only works for solc-created BuildInfos. #8081

Open

Conversation

marianfe commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Details

Uh oh!

changeset-bot bot commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Copilot AI Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

marianfe Feb 26, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

alcuadrado Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

alcuadrado Mar 7, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

alcuadrado Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

alcuadrado Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

alcuadrado Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

alcuadrado Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

alcuadrado Mar 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

alcuadrado left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

marianfe commented Feb 25, 2026 •

edited

Loading

changeset-bot bot commented Feb 25, 2026 •

edited

Loading

alcuadrado Mar 7, 2026 •

edited

Loading