Skip to content

Conversation

@knutties
Copy link
Collaborator

@knutties knutties commented Sep 16, 2025

Problem

@SanchithHegde pointed out the missing rust-version and edition values in our crates.

Solution

Set the value in the top-level Cargo.toml and reference it in all the crates.

Summary by CodeRabbit

  • Chores
    • Updated minimum required Rust version to 1.85.0 across the workspace
    • Standardized Rust edition and version configuration at the workspace level
    • Updated Rust toolchain to 1.90.0

✏️ Tip: You can customize this high-level summary in your review settings.

description = "Rust SDK to work with Superposition"
edition = "2021"
edition = { workspace = true }
rust-version = { workspace = true }
Copy link
Collaborator

Choose a reason for hiding this comment

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

if I am not wrong, this would get reverted in smithy generation
and I suppose we should use a different value just for the provider, so that we can have a higher inclusion percent

the server can be at a high MSRV like 1.82.0 but the sdk and the provider should not be dependent on this high of a number

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This was based on @SanchithHegde's comment using the cargo msrv command (I think uniffi forces it). Running it currently. Will add the output to the PR.

Can we configure smithy to generate this the way we want it? cc: @ShubhranshuSanjeev @ShreyBana

Copy link
Collaborator

Choose a reason for hiding this comment

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

@knutties
smithy-build.json takes minimumSupportedRustVersion as config

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

➜  superposition git:(fix-msrv) ✗ cargo msrv verify --rust-version 1.81
  [Meta]   cargo-msrv 0.18.4  

Compatibility Check #1: Rust 1.81.0
◝ Rust 1.81.0      Elapsed 2s                                                                                                                                                                                                                                 ◞ Rust 1.81.0      Elapsed 3s                                                                                                                                                                                                                                 ◡ Rust 1.81.0      Elapsed 3s                                                                                                   ◜ Rust 1.81.0      Elapsed 4s                                                                                                         [FAIL]   Is incompatible 

...

uniffi errors

One option is to skip uniffi in rust builds via feature flag (which is actually a good idea by @SanchithHegde). I will do this as well in this PR.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@knutties you would need to check the MSRV for the crate individually I guess
also, uniffi would be needed for the provider only (from the import point of view)

I was thinking something:
sdk and provider to have their respective MSRVs
and all other crates can use a common one from workspace (if at all a common MSRV is needed)

Copy link
Collaborator Author

@knutties knutties Sep 17, 2025

Choose a reason for hiding this comment

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

Yes - that is the plan. For crates that wider people have to use - we can lower the msrv - but we will need to remove uniffi dependency in Rust SDKs as it is not needed. uniffi is not needed for the Rust provider - it is needed only in the other language bindings.

We might need some additional CI checks to ensure we compile with some lower msrv as well. I will do that in this PR.

Copy link
Collaborator

Choose a reason for hiding this comment

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

But the rust sdk does not include uniffi

@knutties
Copy link
Collaborator Author

knutties commented Jan 9, 2026

MSRV and Edition Strategy Recommendations
Based on my review of this PR and the codebase, here are my recommendations:

Current State Analysis
The project currently:

Uses Rust 1.86.0 in CI and rust-toolchain.toml
Has edition = "2021" hardcoded in all crates
Has no rust-version (MSRV) specified anywhere
Already centralizes workspace dependencies in root Cargo.toml
Recommendations

  1. Edition Strategy
    Add to root Cargo.toml workspace section:

[
workspace.package
]
edition = "2021"

Then update all crate Cargo.toml files to use:

edition = { workspace = true }

Rationale: Edition 2021 is stable and well-supported. No need to upgrade to 2024 yet unless you need specific features.

  1. Differentiated MSRV Strategy
    Based on the PR discussion, implement a tiered MSRV approach:

Tier 1: Public SDK/Provider Crates (Lower MSRV for broader compatibility)
superposition_sdk → 1.75.0 (Smithy-generated, needs to support older Rust)
superposition_provider → 1.75.0 (depends on SDK)
superposition_types → 1.75.0 (shared types)
Tier 2: Client Crates (Medium MSRV)
cac_client → 1.78.0
experimentation_client → 1.78.0
Tier 3: Core/FFI with uniffi (Higher MSRV)
superposition_core → 1.81.0 (uniffi requirement)
Tier 4: Server Crates (Match CI/toolchain)
context_aware_config → 1.81.0
experimentation_platform → 1.81.0
superposition (main binary) → 1.81.0
service_utils → 1.81.0
Tier 5: Macros/Derives
superposition_macros → 1.75.0
superposition_derives → 1.75.0
Implementation:

In each crate's Cargo.toml

[
package
]
rust-version = "1.75.0" # or appropriate version per tier

  1. Smithy Build Configuration
    Update smithy/smithy-build.json to specify MSRV for code generation:

{
"plugins": {
"rust-client-codegen": {
"codegen": {
"addMessageToErrors": true,
"renameErrors": true,
"enableNewSmithyRuntime": "orchestrator",
"minimumSupportedRustVersion": "1.75.0"
},
...
}
}
}

  1. CI/CD Integration
    Add MSRV verification job to .github/workflows/ci_check_pr.yaml:

msrv-check:
name: Check MSRV compliance
runs-on: anton1
strategy:
matrix:
crate:
- name: superposition_sdk
msrv: "1.75.0"
- name: superposition_provider
msrv: "1.75.0"
- name: superposition_types
msrv: "1.75.0"
steps:
- name: Checkout repository
uses: actions/checkout@v4

- name: Install Rust ${{ matrix.crate.msrv }}
  uses: dtolnay/rust-toolchain@master
  with:
    toolchain: ${{ matrix.crate.msrv }}

- name: Verify MSRV for ${{ matrix.crate.name }}
  run: |
    cargo check -p ${{ matrix.crate.name }}
  1. Why NOT use workspace-level MSRV
    Don't add rust-version to [workspace.package] because:

Different crates have different MSRV requirements (uniffi constraint)
SDK needs lower MSRV for broader ecosystem compatibility
Server can use newer features (matches CI's 1.86.0)
6. Verification Steps
After implementing:

Verify SDK builds with lower MSRV

rustup install 1.75.0
cargo +1.75.0 check -p superposition_sdk
cargo +1.75.0 check -p superposition_provider

Verify server builds with specified MSRV

cargo +1.81.0 check -p context_aware_config
cargo +1.81.0 check -p experimentation_platform

Verify everything builds with current toolchain

cargo check --all-features

  1. Documentation Updates
    Add to README.md:

Minimum Supported Rust Version (MSRV)

  • SDK crates (superposition_sdk, superposition_provider): 1.75.0
  • Server crates: 1.81.0
  • Development: 1.86.0 (see rust-toolchain.toml)

Summary
The key insight from this PR is that a one-size-fits-all MSRV doesn't work for this project. The differentiated approach balances:

SDK compatibility (lower MSRV for wider ecosystem adoption)
Uniffi requirements (higher MSRV for core)
Server development velocity (can use newer features)
This approach gives you flexibility while maintaining clear guarantees for downstream consumers of your SDK.

@coderabbitai
Copy link

coderabbitai bot commented Jan 12, 2026

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

Standardizes workspace-wide Rust version and edition by adding rust-version = "1.85.0" and edition = "2024" to the root workspace, updating child crates to reference workspace settings, and updating the toolchain channel from 1.86.0 to 1.90.0.

Changes

Cohort / File(s) Summary
Workspace Root Configuration
Cargo.toml, rust-toolchain.toml, smithy/smithy-build.json
Added rust-version = "1.85.0" and edition = "2024" to root workspace; updated toolchain channel from 1.86.0 to 1.90.0; added minimumSupportedRustVersion = "1.85.0" to smithy build config
Crates Using Workspace Rust Version Only
crates/cac_client/Cargo.toml, crates/experimentation_client/Cargo.toml, crates/superposition_core/Cargo.toml, crates/superposition_sdk/Cargo.toml
Added rust-version.workspace = true to reference workspace-scoped Rust version
Crates Updating Edition and Rust Version
crates/cac_toml/Cargo.toml, crates/context_aware_config/Cargo.toml, crates/experimentation_platform/Cargo.toml, crates/frontend/Cargo.toml, crates/service_utils/Cargo.toml, crates/superposition/Cargo.toml, crates/superposition_derives/Cargo.toml, crates/superposition_macros/Cargo.toml
Replaced edition = "2021" with edition.workspace = true; added rust-version.workspace = true
Crates with Workspace Version Syntax
crates/superposition_provider/Cargo.toml, crates/superposition_types/Cargo.toml
Added rust-version = { workspace = true } using table syntax; updated version syntax to workspace reference
Smithy Patch File
smithy/patches/rust.patch
Updated crates/superposition_sdk manifest: switched to workspace version, added license and homepage workspace references, explicit rust-version and readme fields

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~8 minutes

Poem

🐰 From version constraints we hop with glee,
One-eighty-five is now our decree,
Workspace-wide settings, harmonized and fine,
All carrots aligned on the version line! 🥕

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: setting up MSRV (minimum supported Rust version) and edition consistently across all Cargo.toml files in the workspace.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 3

🤖 Fix all issues with AI agents
In @crates/superposition_types/Cargo.toml:
- Around line 3-5: The Cargo manifest sets edition = "2021" explicitly; change
it to inherit the workspace edition by replacing the hardcoded edition with
workspace inheritance (e.g., use edition.workspace = true or edition = {
workspace = true } to match other crates), so the 'edition' key follows the same
workspace-based configuration as 'rust-version'.
🧹 Nitpick comments (4)
crates/cac_client/Cargo.toml (1)

5-6: Same edition inconsistency as experimentation_client.

The rust-version.workspace = true addition is correct. However, edition = "2021" remains hardcoded while cac_toml uses edition.workspace = true.

For consistency, either:

  1. Set workspace edition = "2021" and use edition.workspace = true in all crates, or
  2. Explicitly document why some crates hardcode edition while others inherit it.
crates/superposition_core/Cargo.toml (1)

4-5: Inconsistent edition handling compared to other crates.

This crate retains edition = "2021" hardcoded while adopting rust-version.workspace = true. Other crates in this PR (e.g., service_utils) use edition.workspace = true. This creates an inconsistency where:

  • If workspace edition is "2024" (as set in root Cargo.toml), this crate stays on "2021"
  • If the intent is to keep all crates on "2021", then edition.workspace = true shouldn't be used in other crates

Consider aligning the approach—either all crates inherit edition from workspace or all specify it explicitly.

crates/superposition_provider/Cargo.toml (1)

4-5: Inconsistent edition handling; consider SDK MSRV requirements.

Same inconsistency as superposition_core: hardcoded edition = "2021" while using rust-version = { workspace = true }.

Additionally, per the reviewer's tiered MSRV recommendation, superposition_provider is a Tier 1 public SDK crate that should have a lower MSRV (1.75.0) for wider compatibility. Using the workspace's 1.85.0 may unnecessarily restrict consumers.

If the intent is to keep this crate at edition 2021 with a lower MSRV, consider setting rust-version = "1.75.0" explicitly rather than inheriting from workspace.

Suggested approach for tiered MSRV
 [package]
 name = "superposition_provider"
 version.workspace = true
 edition = "2021"
-rust-version = { workspace = true }
+rust-version = "1.75.0"
 license = { workspace = true }
smithy/patches/rust.patch (1)

13-13: Consider using edition.workspace = true for consistency.

Other crates in this PR adopt edition.workspace = true to centralize the edition setting. This patch keeps edition = "2021" hardcoded. If the Smithy codegen allows patching this field, consider aligning it with the workspace pattern:

-edition = "2021"
+edition.workspace = true

If the Smithy generator enforces a specific edition and re-generates this line, the hardcoded value may be acceptable—but document this exception.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1236863 and bcb4162.

📒 Files selected for processing (18)
  • Cargo.toml
  • crates/cac_client/Cargo.toml
  • crates/cac_toml/Cargo.toml
  • crates/context_aware_config/Cargo.toml
  • crates/experimentation_client/Cargo.toml
  • crates/experimentation_platform/Cargo.toml
  • crates/frontend/Cargo.toml
  • crates/service_utils/Cargo.toml
  • crates/superposition/Cargo.toml
  • crates/superposition_core/Cargo.toml
  • crates/superposition_derives/Cargo.toml
  • crates/superposition_macros/Cargo.toml
  • crates/superposition_provider/Cargo.toml
  • crates/superposition_sdk/Cargo.toml
  • crates/superposition_types/Cargo.toml
  • rust-toolchain.toml
  • smithy/patches/rust.patch
  • smithy/smithy-build.json
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2026-01-03T13:25:40.584Z
Learnt from: ayushjain17
Repo: juspay/superposition PR: 816
File: crates/frontend/src/pages/webhook.rs:136-137
Timestamp: 2026-01-03T13:25:40.584Z
Learning: In the superposition codebase (Rust frontend), the `Workspace` and `OrganisationId` newtype wrappers implement `Deref`, which allows `&Workspace` and `&OrganisationId` to be automatically coerced to `&str` when passed to functions expecting `&str` parameters. Manual `.0` dereferencing is not needed.

Applied to files:

  • crates/superposition_sdk/Cargo.toml
  • crates/superposition_derives/Cargo.toml
  • crates/superposition_types/Cargo.toml
📚 Learning: 2026-01-03T10:25:41.325Z
Learnt from: ayushjain17
Repo: juspay/superposition PR: 814
File: crates/superposition_types/src/api/workspace.rs:70-77
Timestamp: 2026-01-03T10:25:41.325Z
Learning: The `auto_populate_control` field in `CreateWorkspaceRequest` (`crates/superposition_types/src/api/workspace.rs`) is expected to default to `true`, not `false`. This is implemented using `#[serde(default = "default_true")]`.

Applied to files:

  • crates/experimentation_client/Cargo.toml
  • crates/frontend/Cargo.toml
  • crates/superposition_types/Cargo.toml
  • crates/superposition_core/Cargo.toml
  • crates/superposition_provider/Cargo.toml
📚 Learning: 2026-01-03T13:27:14.072Z
Learnt from: ayushjain17
Repo: juspay/superposition PR: 816
File: crates/frontend/src/pages/type_template.rs:82-87
Timestamp: 2026-01-03T13:27:14.072Z
Learning: In the frontend crate, both `Workspace` and `OrganisationId` types implement `Deref` trait (via `#[derive(Deref)]`), allowing automatic coercion from `&Workspace` to `&str` and `&OrganisationId` to `&str`. When passing these types to functions expecting `&str`, use `&workspace` or `&org` directly instead of `&workspace.0` or `&org.0`.

Applied to files:

  • crates/frontend/Cargo.toml
🔇 Additional comments (13)
crates/experimentation_client/Cargo.toml (1)

5-6: Inconsistent edition handling across crates.

This file hardcodes edition = "2021" while crates/cac_toml/Cargo.toml uses edition.workspace = true. If the workspace defines edition = "2024" (per AI summary), this creates intentional divergence.

Clarify the intent:

  • If all crates should remain on edition 2021 (as per reviewer recommendation), consider setting edition = "2021" at workspace level and using edition.workspace = true everywhere.
  • If this crate intentionally stays on 2021 while others move to 2024, this is fine but should be documented.
crates/superposition_sdk/Cargo.toml (1)

11-11: LGTM for generated code.

The hardcoded rust-version = "1.85.0" is appropriate here since this file is auto-generated by Smithy. The value correctly corresponds to the minimumSupportedRustVersion setting in smithy/smithy-build.json. Any MSRV adjustments for this SDK should be made in the Smithy configuration, not directly in this file.

smithy/smithy-build.json (1)

37-37: The 1.85.0 MSRV is required by Rust's 2024 edition.

The codebase uses Rust's 2024 edition (edition = "2024" in the workspace Cargo.toml), which mandates Rust 1.85.0 as the minimum. This MSRV is set consistently across the workspace and all SDK crates (superposition_types, superposition_provider, and superposition_sdk all use 1.85.0), and is not a compatibility concern but rather a hard requirement of the edition selection. No change is possible without reconsidering the edition choice itself.

Likely an incorrect or invalid review comment.

crates/service_utils/Cargo.toml (1)

5-6: Workspace inheritance is consistent here.

The changes correctly inherit both edition and rust-version from the workspace. However, note that the workspace sets edition = "2024", which inherently requires Rust 1.85.0+. This means the effective MSRV for this crate will be at least 1.85.0 regardless of any tiered MSRV strategy discussed in the PR comments.

rust-toolchain.toml (1)

2-2: Rust 1.90.0 exists and is stable as of January 2026.

The toolchain has been updated from 1.86.0 to 1.90.0. This is a valid, stable version (confirmed as of January 12, 2026, with 1.92.0 being the latest stable release). If there are concerns about the version bump magnitude, those should be addressed separately as an architectural decision rather than a toolchain availability issue.

crates/superposition_derives/Cargo.toml (1)

4-5: LGTM - Workspace inheritance for edition and rust-version.

The changes correctly inherit edition and rust-version from the workspace, ensuring consistent configuration across the codebase.

crates/superposition/Cargo.toml (1)

5-6: LGTM - Consistent workspace inheritance.

The main server crate correctly inherits edition and rust-version from the workspace configuration.

crates/experimentation_platform/Cargo.toml (1)

5-6: LGTM - Workspace inheritance applied consistently.

The edition and rust-version settings correctly inherit from the workspace.

crates/superposition_macros/Cargo.toml (1)

5-6: LGTM - Workspace inheritance applied correctly.

The workspace-scoped settings are properly configured for this macros crate.

crates/context_aware_config/Cargo.toml (1)

5-6: LGTM - Workspace inheritance applied consistently.

The edition and rust-version settings correctly inherit from the workspace configuration.

crates/frontend/Cargo.toml (1)

5-6: LGTM - Workspace inheritance applied correctly.

The workspace-scoped edition and rust-version settings are correctly inherited. The workspace's Rust 1.85.0 is fully compatible with the WASM crate's dependencies, including wasm-bindgen.

smithy/patches/rust.patch (2)

17-17: Verify SDK MSRV aligns with compatibility goals.

The PR discussion recommends a tiered MSRV strategy with SDK crates (superposition_sdk) at 1.75.0 for wider downstream compatibility. This sets rust-version = "1.85.0", which is significantly higher.

If the Smithy-generated code genuinely requires 1.85.0 features, this is unavoidable—but if not, consider lowering the MSRV to expand the SDK's usability. Also ensure this value stays synchronized with minimumSupportedRustVersion in smithy/smithy-build.json.


10-18: Workspace metadata fields look good.

The adoption of version.workspace = true, license = { workspace = true }, and homepage = { workspace = true } properly centralizes package metadata. Adding readme = "README.md" is a sensible default.

Comment on lines +9 to +10
package.rust-version = "1.85.0"
package.edition = "2024"
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

Implementation diverges from reviewer's tiered MSRV and edition recommendations.

The PR comments from knutties provide detailed recommendations that differ from this implementation:

Aspect Recommended Implemented
Edition Keep "2021" "2024"
MSRV strategy Tiered per crate (1.75.0–1.81.0) Single workspace value (1.85.0)
SDK crates MSRV 1.75.0 (for wider compatibility) 1.85.0

Concerns:

  1. Edition 2024 introduces breaking changes (e.g., gen becomes a keyword, changes to prelude, unsafe requirements in extern blocks). This requires code migration across all crates.

  2. Single MSRV means SDK consumers must use Rust 1.85.0+, which may limit adoption. The tiered approach allows superposition_sdk, superposition_provider, and superposition_types to support older Rust versions.

Please confirm whether the tiered MSRV strategy should be implemented, or if the decision is to proceed with a single workspace-level MSRV.

Comment on lines +5 to +6
edition.workspace = true
rust-version.workspace = true
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check workspace-level edition and rust-version settings
echo "=== Root Cargo.toml workspace.package settings ==="
grep -A 10 '\[workspace\.package\]' Cargo.toml || grep -A 10 '\[workspace\]' Cargo.toml | head -20

echo ""
echo "=== Edition settings across all crates ==="
fd -e toml -t f Cargo.toml --exec grep -l "edition" {} \; | xargs -I {} sh -c 'echo "--- {} ---" && grep "edition" {}'

Repository: juspay/superposition

Length of output: 1940


The cac_toml/Cargo.toml correctly uses workspace inheritance, but the workspace has a critical edition mismatch issue.

The file correctly uses edition.workspace = true and rust-version.workspace = true. However, the workspace-level edition IS set to "2024" in the root Cargo.toml, and this creates a significant problem: 8 crates (including this one) will use edition 2024 via workspace inheritance, while 7+ other crates like cac_client and experimentation_client hardcode edition = "2021". This split causes real compatibility differences across the workspace (different prelude semantics, gen keyword reservation, etc.).

The workspace needs to either:

  1. Ensure all crates inherit from workspace (consistent 2024 edition), or
  2. Set workspace edition back to 2021 and explicitly configure edition 2024 only for crates that require it.

Comment on lines 3 to 5
version = { workspace = true }
edition = "2021"
rust-version = { workspace = true }
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Inconsistent edition configuration - should use workspace inheritance.

Line 4 hardcodes edition = "2021" while other crates in this PR use edition.workspace = true. This creates inconsistency:

  • rust-version correctly uses workspace inheritance
  • edition does not, unlike the other crates modified in this PR
Suggested fix
 [package]
 name = "superposition_types"
 version = { workspace = true }
-edition = "2021"
+edition = { workspace = true }
 rust-version = { workspace = true }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
version = { workspace = true }
edition = "2021"
rust-version = { workspace = true }
version = { workspace = true }
edition = { workspace = true }
rust-version = { workspace = true }
🤖 Prompt for AI Agents
In @crates/superposition_types/Cargo.toml around lines 3 - 5, The Cargo manifest
sets edition = "2021" explicitly; change it to inherit the workspace edition by
replacing the hardcoded edition with workspace inheritance (e.g., use
edition.workspace = true or edition = { workspace = true } to match other
crates), so the 'edition' key follows the same workspace-based configuration as
'rust-version'.

@Datron Datron force-pushed the fix-msrv branch 3 times, most recently from 0bb5204 to 7423bb1 Compare January 13, 2026 09:41
enum ResponseType {
UpdatePrecheck,
Response(ExperimentResponse),
Response(Box<ExperimentResponse>),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why is this change needed ?

Copy link
Collaborator

@Datron Datron Jan 13, 2026

Choose a reason for hiding this comment

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

This becomes a clippy failure with edition set, the enum variants have different sizes and therefore Box is needed for dynamic allocation

description = "CAC Client provides interfaces for applications to interact with the context-aware-config module in superposition. Note: this is deprecated, please use the provider"
version.workspace = true
edition = "2021"
rust-version.workspace = true
Copy link
Collaborator

Choose a reason for hiding this comment

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

For client also same version ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

resolved

"service": "io.superposition#Superposition",
"module": "superposition_sdk",
"moduleVersion": "0.1.0",
"minimumSupportedRustVersion": "1.82.0",
Copy link
Collaborator

Choose a reason for hiding this comment

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

are you sure this is correct ?
I ran cargo msrv find and I found it to be 1.80.1

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.

4 participants