Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@kpfleming
Copy link
Contributor

Change summary

Rust 1.91.1 includes a fix for the incompatibility which appeared in 1.91.0. The CLI will now allow usage of that version, and any later patch releases in 1.91.x, but not 1.92 or later. A future CLI version will support 1.92 once beta releases of that version have been tested.

All Submissions:

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Example output when Rust 1.91.0 is used:

kpfleming@kpfleming:~/src/fastly/http-me$ ~/src/fastly/cli/fastly compute build
✓ Verifying fastly.toml
✓ Identifying package name
✓ Identifying toolchain

ERROR: version '1.91.0' of Rust is not compatible with Fastly Compute.

Consult the Rust guide for Compute at https://www.fastly.com/documentation/guides/compute/rust/ for more information.

Rust 1.91.1 includes a fix for the incompatibility which appeared in
1.91.0. The CLI will now allow usage of that version, and any later
patch releases in 1.91.x, but not 1.92 or later. A future CLI version
will support 1.92 once beta releases of that version have been tested.
@kpfleming kpfleming marked this pull request as ready for review November 10, 2025 21:53
@kpfleming kpfleming requested a review from a team as a code owner November 10, 2025 21:53
Copy link
Member

@philippschulte philippschulte left a comment

Choose a reason for hiding this comment

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

Instead of assuming that the semver parser supports your constraint I would recommend to add a table-driven test. I put it already for you together because I needed it to test your changes:

pkg/commands/compute/language_rust_test.go

package compute

import (
	"errors"
	"fmt"
	"strings"
	"testing"

	"github.com/Masterminds/semver/v3"
)

func TestRustToolchainConstraint(t *testing.T) {
	const constraint = ">= 1.78 != 1.91.0 < 1.92"

	tests := []struct {
		name              string
		rustVersion       string
		wantErr           bool
		wantErrorContains string
	}{
		{
			name:              "rejects 1.91.0",
			rustVersion:       "1.91.0",
			wantErr:           true,
			wantErrorContains: "not compatible",
		},
		{
			name:        "allows 1.90.1",
			rustVersion: "1.90.1",
			wantErr:     false,
		},
		{
			name:        "allows 1.91.1",
			rustVersion: "1.91.1",
			wantErr:     false,
		},
	}

	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			// Parse the Rust version being tested
			v, err := semver.NewVersion(tt.rustVersion)
			if err != nil {
				t.Fatalf("failed to parse version: %v", err)
			}

			// Parse the semver constraint (shared across tests)
			c, err := semver.NewConstraint(constraint)
			if err != nil {
				t.Fatalf("failed to parse constraint: %v", err)
			}

			// Validate version against constraint
			valid, errs := c.Validate(v)

			var resultErr error
			if !valid {
				for _, e := range errs {
					if strings.Contains(e.Error(), "is greater than") {
						resultErr = fmt.Errorf("version '%s' of Rust has not been validated for use with Fastly Compute", v)
					}
					if strings.Contains(e.Error(), "is equal to") {
						resultErr = fmt.Errorf("version '%s' of Rust is not compatible with Fastly Compute", v)
					}
				}
				if resultErr == nil {
					resultErr = fmt.Errorf("the Rust version requirement was not satisfied: '%w'", errors.Join(errs...))
				}
			}

			// Check if error presence matches expectation
			if (resultErr != nil) != tt.wantErr {
				t.Errorf("unexpected error result: got %v, wantErr %v", resultErr, tt.wantErr)
			}

			// If error was expected, check it contains the expected string
			if tt.wantErr && tt.wantErrorContains != "" && !strings.Contains(resultErr.Error(), tt.wantErrorContains) {
				t.Errorf("expected error to contain %q, got %q", tt.wantErrorContains, resultErr.Error())
			}
		})
	}
}

Please also update the changelog entry. Thanks!

@kpfleming
Copy link
Contributor Author

I debated adding a test like this initially, but I opted not to because it's not testing the code in the CLI, it's testing the behavior of the semver module. While that may be valuable on its own, if we wanted to add tests to ensure that the semver module continues to behave according to its documentation/contract, I would approach those tests quite differently (for example, I would not be testing that specific versions of Rust are rejected, but instead test that a constraint string with a 'not-equals' clause is respected and a candidate version which matches that clause is rejected). I'll try to modify this test to work that way, but as far as I'm aware it will be the first set of tests in the CLI which test the behavior of code that isn't present in the CLI itself.

In order for this to be a proper unit test as you've proposed, we would need to modify the toolchainConstraint function of the Rust struct to unit testable, which it definitely is not today.

@kpfleming
Copy link
Contributor Author

After investigating the tests already present in the semver module, I don't think we need to test the module's behavior ourselves. That test suite includes tests which cover the type of constraint we're using.

Since the actual constraint modified in this PR is configuration data and not code, I'm not really certain that a good testing strategy exists. It would almost require a complete 'functional' test which uses a built copy of the CLI and tests against various types of config.toml content to ensure that constraints specified there are applied properly.

@kpfleming
Copy link
Contributor Author

Please also update the changelog entry. Thanks!

Done in 3e35b08.

@kpfleming kpfleming merged commit cbc743e into fastly:main Nov 12, 2025
15 of 17 checks passed
@kpfleming kpfleming deleted the allow-rust-1.91.1 branch November 12, 2025 14:33
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