Skip to content

[gc_fuzz]: Add non-null types - #14276

Open
khagankhan wants to merge 3 commits into
bytecodealliance:mainfrom
khagankhan:ctr
Open

[gc_fuzz]: Add non-null types#14276
khagankhan wants to merge 3 commits into
bytecodealliance:mainfrom
khagankhan:ctr

Conversation

@khagankhan

Copy link
Copy Markdown
Contributor

The gc_ops fuzzer never generated non-nullable reference fields. Fixup forced every reference field to nullable, so the generator only ever emitted (ref null $t) and structref. This change lets non-nullable fields survive, so the fuzzer now exercises (ref $t) and (ref struct) as well.

Two design choices:

  1. Briefly, inhabitable proves types buildable by fixpoint, so anything it never admits is uninhabitable. fix_uninhabitable takes one such type per pass and relaxes only the fields that cannot be satisfied to nullable, then re-runs the analysis until every type is admitted. A nullable field can always be filled with ref.null, so relaxing one gives the cycle a base case, which usually unblocks several other types at once and leaves well founded non-nullable references untouched.

  2. emit_new builds a real object for non-null, pushing a value per field and ending with struct.new. emit_ref_to decides build versus reuse. Types costing 8 instructions or less are built fresh at every use, and anything more expensive gets one shared object per loop iteration held in a local and read back with local.get + ref.as_non_null. Building cheap types fresh keeps many distinct objects on the heap instead of every reference aliasing one while the prototype stop a deep graph from expanding exponentially.

P.S. I realized certain functions are very big (like fixup now). The next PR will be clean-up about these.

+cc @fitzgen

@khagankhan
khagankhan requested a review from a team as a code owner September 4, 2026 02:40
@khagankhan
khagankhan requested review from alexcrichton and removed request for a team September 4, 2026 02:40
type_ids_to_index: &BTreeMap<TypeId, u32>,
) {
/// Returns `true` if this field type can be default-constructed.
pub fn is_defaultable(self) -> bool {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

reports whether a field type has a default value. Only non-nullable references do not.

}

/// Whether `field` can be given a value using only the types in `ok`.
fn field_satisfiable(&self, field: FieldType, ok: &BTreeMap<TypeId, u32>) -> bool {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

tells whether a field can be given a value using only a given set of buildable types. A non-nullable concrete reference needs its target in that set. A non-nullable need any non-array in that set.

}

/// Return the least-ranked inhabitable struct type, if any.
pub(crate) fn least_rank_inhabitable_struct(

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

this picks the buildable struct with the lowest round number. This is the struct built to fill a non-nullable (ref struct) field.


/// Compute the set of types that should be encoded as prototypes, i.e. those
/// that are referenced by other types.
pub(crate) fn prototype_types(

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This decides which types get shared prototype. It costs each type as one instruction per field plus one using each referent's own cost and hoists anything over the budget that something actually points at. So when a nonnull struct needed a new one is created till total # is < 8 after that they were reused. This also may be considered "the first step" to places paradigm.

@github-actions github-actions Bot added the fuzzing Issues related to our fuzzing infrastructure label Sep 4, 2026
@github-actions

github-actions Bot commented Sep 4, 2026

Copy link
Copy Markdown

Subscribe to Label Action

cc @fitzgen

Details This issue or pull request has been labeled: "fuzzing"

Thus the following users have been cc'd because of the following labels:

  • fitzgen: fuzzing

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

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

Labels

fuzzing Issues related to our fuzzing infrastructure

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant