Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WASM ABI 1.0] Change ColId from u32 to u16 #1597

Merged
merged 10 commits into from
Aug 19, 2024
Merged

[WASM ABI 1.0] Change ColId from u32 to u16 #1597

merged 10 commits into from
Aug 19, 2024

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Aug 16, 2024

Description of Changes

cc #1460

API and ABI breaking changes

The actual ABI signature doesn't change here as WASM represents u16 as u32, but the behavior does change.

Expected complexity level and risk

2

Testing

  • ColList tests were run through miri.

@Centril Centril changed the title WIP [WASM ABI 1.0] Change ColId from u32 to u16 Aug 16, 2024
@Centril Centril force-pushed the centril/colid-u16 branch from 55c7896 to 567fa08 Compare August 16, 2024 14:28
@Centril Centril force-pushed the centril/colid-u16 branch from f087d69 to 1b6212c Compare August 16, 2024 17:43
@Centril Centril mentioned this pull request Aug 16, 2024
Copy link
Contributor

@kazimuth kazimuth left a comment

Choose a reason for hiding this comment

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

All makes sense.

I guess I should change names in my other PR to ABI v10? Or maybe we should detach the RawModuleDef version from the WASM ABI version.

@@ -218,20 +218,36 @@ impl FromIterator<AlgebraicType> for Typespace {
}
}

/// A trait for types that can be represented as an `AlgebraicType`
/// A trait for Rust types that can be represented as an [`AlgebraicType`]
/// with an empty typing context.
Copy link
Contributor

@kazimuth kazimuth Aug 19, 2024

Choose a reason for hiding this comment

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

I think it's slightly stronger than this.
Because e.g. (x: (y: u8) | (z: u16)) satisfies this condition, but I believe should not be considered a "ground type". This is because AlgebraicType contexts is very flexible -- you can either directly include a SumType in a ProductType, or you can include it behind a Ref.

AlgebraicTypeUseForGenerate that we discussed in #1590 will resolve this since it will only allow Sum or Product types behind Ref. Once that's defined, we can say "can be represented as AlgebraicTypeUseForGenerate without any Refs." (man, that's a mouthful...)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Formally the type you mentioned is a ground type though. It has no free variables, which is the definition of a "ground term" / expression.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I did not know that was a standard term :) I thought it just meant "builtin".

@Centril
Copy link
Contributor Author

Centril commented Aug 19, 2024

Or maybe we should detach the RawModuleDef version from the WASM ABI version.

Yeah probably, for now, and in any case, I'd like to lower the ABI to spacetimedb_1 just before we launch mainnet.

@Centril Centril added this pull request to the merge queue Aug 19, 2024
Merged via the queue into master with commit 1ca9b1a Aug 19, 2024
8 checks passed
@Centril Centril deleted the centril/colid-u16 branch August 19, 2024 19:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants