fix(patcher): force core profile on the lines program

[proxsyi]

Summary

On macOS (OpenGL 4.1 Metal — core-profile only), enabling any shader pack that provides a gbuffers_line shader fails after 1.10.8:

net.irisshaders.iris.gl.shader.ShaderCompileException: lines: lines: ERROR: 0:1: '' : syntax error: #version

The patched lines program is emitted as #version 330 compatibility, which Apple's core-only driver rejects, so the entire pipeline is disabled. Regression between 1.10.8 (emitted #version 330) and 1.10.9.

Reproduced on: macOS 27.0, Apple M5, MC 26.1.1, Sodium 0.8.9, with both IterationV and stock Complementary Reimagined r5.8.1.

Root cause

TransformPatcher routes line shaders through VanillaCoreTransformer via the isLine branch regardless of their declared profile. The else branch (standard non-core shaders) explicitly sets versionStatement.profile = Profile.CORE at line 175, but the if branch (profile == CORE || version >= 150 && profile == null || isLine) does not.

When isLine is the sole reason for entering the branch and the incoming shader has #version 330 compatibility, the profile is never updated — so compatibility survives to the driver output.

Fix

One targeted guard, inserted after the version-number bump and before the transformer switch:

// lines shaders are forced through VanillaCoreTransformer regardless of
// their declared profile, so ensure the output profile is core
if (isLine && profile != Profile.CORE) {
    versionStatement.profile = Profile.CORE;
}

This ensures line shaders always emit a core profile, matching the intent of the VanillaCoreTransformer path.

Testing

• macOS 27.0, Apple M5, MC 26.1.1, Fabric API 0.151.0, Sodium 0.8.9
• Before: pipeline fails with lines: ERROR: 0:1: '' : syntax error: #version; shaders disabled on load
• After: patched lines.vsh emits #version 330 core; pipeline builds; shaders load in overworld and End
• Tested with IterationV and Complementary Reimagined r5.8.1

[fayer3]

this is technically a shaderpack issue, afaik gbuffers_line is meant be written in core, and not compatibility. since it is 1.17+ only

[proxsyi]

this is technically a shaderpack issue, afaik gbuffers_line is meant be written in core, and not compatibility. since it is 1.17+ only

Thanks for taking a look!

I actually agree line shaders should be core on 1.17+ — that's exactly why I think this belongs in the patcher and not the pack. A few things rule out a shaderpack-side fix:

1. It reproduces on a stock, unmodified pack. Complementary Reimagined r5.8.1 with zero edits hits the identical failure. If this were a per-pack authoring mistake, a mainstream pack like Complementary wouldn't trip it.

2. It's a regression, not longstanding behavior. Same pack, same hardware: works on 1.10.8 (lines emitted as #version 330), breaks on 1.10.9 (#version 330 compatibility). The only variable is the Iris jar.

3. The compatibility isn't inherited from the pack source. Even when gbuffers_line is declared #version 330 core, editing or removing that source doesn't change the output — Iris regenerates the line program and the compatibility profile is introduced during patching.

4. The patcher already normalizes this everywhere else. The else branch explicitly sets versionStatement.profile = Profile.CORE for non-core shaders. The isLine branch routes line shaders through VanillaCoreTransformer regardless of declared profile but never applies that same normalization, so compatibility leaks through for lines specifically. This patch just makes the isLine path consistent with what the patcher already does for every other program it rewrites.

Net: on core-only drivers (macOS GL 4.1), the patcher currently emits the lines program as compatibility, which Apple rejects and disables the whole pipeline.