Skip to content

Add failing tests for working with arrays in BSN - #1

Closed
alice-i-cecile wants to merge 1 commit into
zincdev0:bsn-value-arrayfrom
alice-i-cecile:pr-25942-failing-tests
Closed

alice-i-cecile wants to merge 1 commit into
zincdev0:bsn-value-arrayfrom
alice-i-cecile:pr-25942-failing-tests

Conversation

@alice-i-cecile

Copy link
Copy Markdown

While reviewing bevyengine#25942, my pet LLM found a few failing edge cases. The first two are regressions of previously working functionality introduced by this PR; the last 4 are more optional, demonstrating related functionality that would be good to fix.

direct_array_field_with_entity_references in particular feels surprising that it does not work, but it is perhaps better to leave that until follow-up.

Fuzzing BSN seems increasingly useful 😅

mockersf pushed a commit to bevyengine/bevy that referenced this pull request Oct 8, 2026
This PR is adopted from #25942 by @zincdev0; they have an exam to attend
to, and @Shatur wanted this fix for 0.20. So I'm tackling this, with the
help of an LLM for detecting the edge cases in question, preparing some
minimal test cases, and drafting a tightly scoped fix for their fix.
Lots of review/design/learning involved here, and I've tried to make it
clear in the comment that this is not an ideal long-term solution.

The least bad incremental solution IMO, after reviewing the options, was
to simply scope @zincdev0's fix to the simple case where all elements of
the array are entity references. As discussed in
zincdev0#1, there are some other related
failures here (see #24231...), that hint at some deeper issues lurking.
Still, this is neither the time nor the place to do that sort of
refactor.

## Objective

Currently, entity references in bsn are limited to positions where
BsnValues are parsed.

This PR addresses that limitation for arrays in function arguments. The
entity reference limitations of bsn should probably not be addressed
individually, but this particular case is kind of a blocker for allowing
bevy_enhanced_input to use bsn.

## Solution

A new variant has been added to BsnFnArg for arrays, which allows any
amount of BsnValues in a list.

## Testing
A regression test (arrays_in_bsn) has been added to
crates/bevy_scene/src/lib.rs.

Alice: Another pair of regression tests have been added to ensure that
previously working functionality does not accidently break :P

---------

Co-authored-by: zincdev0 <zincdev@proton.me>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
phoenix20162016 pushed a commit to phoenix20162016/bevy that referenced this pull request Oct 9, 2026
This PR is adopted from bevyengine#25942 by @zincdev0; they have an exam to attend
to, and @Shatur wanted this fix for 0.20. So I'm tackling this, with the
help of an LLM for detecting the edge cases in question, preparing some
minimal test cases, and drafting a tightly scoped fix for their fix.
Lots of review/design/learning involved here, and I've tried to make it
clear in the comment that this is not an ideal long-term solution.

The least bad incremental solution IMO, after reviewing the options, was
to simply scope @zincdev0's fix to the simple case where all elements of
the array are entity references. As discussed in
zincdev0#1, there are some other related
failures here (see bevyengine#24231...), that hint at some deeper issues lurking.
Still, this is neither the time nor the place to do that sort of
refactor.

## Objective

Currently, entity references in bsn are limited to positions where
BsnValues are parsed.

This PR addresses that limitation for arrays in function arguments. The
entity reference limitations of bsn should probably not be addressed
individually, but this particular case is kind of a blocker for allowing
bevy_enhanced_input to use bsn.

## Solution

A new variant has been added to BsnFnArg for arrays, which allows any
amount of BsnValues in a list.

## Testing
A regression test (arrays_in_bsn) has been added to
crates/bevy_scene/src/lib.rs.

Alice: Another pair of regression tests have been added to ensure that
previously working functionality does not accidently break :P

---------

Co-authored-by: zincdev0 <zincdev@proton.me>
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
@zincdev0 zincdev0 closed this Oct 10, 2026
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