Skip to content

no-std checks#33

Open
grod220 wants to merge 1 commit intomainfrom
no-std-checks
Open

no-std checks#33
grod220 wants to merge 1 commit intomainfrom
no-std-checks

Conversation

@grod220
Copy link
Copy Markdown
Member

@grod220 grod220 commented May 8, 2026

Introduces optional no-std package check to main action.

API

The consumer is required to have a makefile command that looks like:

check-no-std-%:
	cargo $(nightly) hack check \
		--target bpfel-unknown-none \
		--each-feature \
		--package $* \
		$(ARGS)

And a workflow that uses solana-program/actions it like so:

name: Main

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  NO_STD_PACKAGES: >-
    [
      {
        "package": "spl-token-2022-interface",
        "build_std": "alloc,core",
        "exclude_features": "serde"
      }
    ]

jobs:
  set_env:
    name: Set variables to be used in strategy definitions in reusable workflow
    runs-on: ubuntu-latest
    outputs:
      RUST_TOOLCHAIN_NIGHTLY: ${{ steps.compute.outputs.RUST_TOOLCHAIN_NIGHTLY }}
      NO_STD_PACKAGES: ${{ steps.compute.outputs.NO_STD_PACKAGES }}
    steps:
      - name: Git Checkout
        uses: actions/checkout@v4

      - name: Compute variables
        id: compute
        shell: bash
        run: |
          {
            echo "RUST_TOOLCHAIN_NIGHTLY=$(make rust-toolchain-nightly)"
            echo "NO_STD_PACKAGES=${{ env.NO_STD_PACKAGES }}"
          } >> "$GITHUB_OUTPUT"

  main:
    needs: set_env
    uses: solana-program/actions/.github/workflows/main.yml@main
    with:
      no-std-toolchain: ${{ needs.set_env.outputs.RUST_TOOLCHAIN_NIGHTLY }}
      no-std-packages: ${{ needs.set_env.outputs.NO_STD_PACKAGES }}

Iterated on a few different API options and found it tricky when feature excludes were global (like in solana-sdk) in combination with a separate no-alloc run. An API comparable to that would look like:

NO_STD_PACKAGES: []
NO_STD_ALLOC_PACKAGES: []
NO_STD_INCOMPATIBLE_FEATURES: []
NO-STD-ALLOC-FEATURES: []

Settled on the per-package definitions.

@grod220 grod220 requested a review from joncinque May 8, 2026 00:20
Copy link
Copy Markdown
Contributor

@joncinque joncinque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The JSON configuration feels a bit over-engineered -- how about having two separate jobs, one for core and one for alloc?

As for features, we should be able to keep the interfaces and programs simple enough that they don't need default features, which means we don't need to exclude.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants