[p5.strands] A bug which allows GLSL wrapper functions to infer genType to be int

[lukeplowden]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• p5.strands
• WebGL
• DevOps, Build process, Unit testing
• Internationalization (i18n)
• Friendly Errors
• Other (specify if possible)

p5.js version

2.0

Steps to reproduce this

Steps:

Use a GLSL function such as mix(x, y, z) with a mix of floats and integer types.

Snippet:

Broken version of @davepagurek's original sketch which uncovered the issue

I wrote an explanation of the bug in the parent issue. Essentially, GLSL has built in functions for common operations, some of which have various overloads for different datatypes. In cases where a float or a vector of floats could be used, GLSL calls this genType in the documentation. There are also genIType, genBType, etc for vectors of types apart from float - see the spec here on page 146 for more details if curious.

Currently, here, p5.strands wrongly allows genType to be inferred as a type int, when only valid types should be float, vec2, vec3, vec4. This causes a misleading error message to print, but even if it didn't it would cause a GLSL error down the line.

If genType is deduced to be an integer, the FunctionCallNode will then later try to convert all of the arguments which aren't integers to be them, which is not good.

The fix should be to stop genType ever being inferred to be int. This is the only place where code needs to be updated.

[reshma045]

@lukeplowden I'd like to work on this issue. Can you assign it to me?

[lukeplowden]

Thanks! Let me know if you have any questions.

[reshma045]

Sure! Thank you