Fuzzer crashes (2)

[aleksisch]

Grammar-based fuzzer findings, continuing from #3892. Built from 5c734c4d6 with -DDAS_NO_ASSERTIONS=0 — CMakeCommon.txt defines DAS_NO_ASSERTIONS for Release, MinSizeRel and RelWithDebInfo, so a stock Release build never reaches these.

1. Oversized type as a function return type is not diagnosed, asserts in getStride

[export]
def f => <- tuple<int[2000000000]>(uninitialized)

[export]
def main { }

$ daslang t.das
assertion failed: stride <= 0x7fffffff, src/ast/ast_typedecl.cpp:3506
stride too big 8000000000

The same type as a local is diagnosed properly — var t = tuple<int[2000000000]>(uninitialized) gives error[30508] — so the check exists but does not cover a function return type. Related to #3892 (comment 8), which reaches getSizeOf at ast_typedecl.cpp:3486 through default<T>: same missing check, different entry point and different assertion.

2. Two chained vector conversions on Point3 emit an ambiguous cvt_pass

require UnitTest

[export]
def main {
    var v = getSamplePoint3() |> uint3 |> int3
}

$ daslang -aot t.das t.cpp
t.cpp:79:30: error: call to 'cvt_pass' is ambiguous
   79 |     int3 __v_rename_at_5_0 = cvt_pass(cvt_uint3(das_alias<Point3>::from(getSamplePoint3())));
      |                              ^~~~~~~~
include/daScript/simulate/aot.h:4506:25: note: candidate function
 4506 |     __forceinline vec4f cvt_pass ( int2 i )  { return i; }

Two conversions are required — a single |> uint3 compiles. int3(1,2,3) in place of getSamplePoint3() compiles, so the das_alias<Point3> wrapper is what makes the overload set ambiguous.

[aleksisch]

Three more, all from a build with -DDAS_NO_ASSERTIONS=0 on 5c734c4d6.

3. JIT panics on unreachable code after return

The interpreter runs this fine; with jit_enabled it fails to simulate.

options optimize = false

[export]
def main {
    return
    return
}

error[31206]: macro caused exception during simulate
modules/dasLLVM/daslib/llvm_jit_run.das:434:12
    panic("Internal jit error. Failed to get IR of '{fun.name} implementation' {maybe_mod}.\n")

Both factors are required: unreachable code after a return, and options optimize = false so the dead return survives to codegen. Either alone is fine.

Reproduced through a JIT-enabled embedding (statically linked LLVM). I could not check daslang -jit because that path wants a dynamic LLVM.dll my build does not produce, so the CLI route is unverified.

4. Fixed-array canonical form violated

module v
require UnitTest
struct a{}
[export]
def a=>new{3>array struct<typedecl(typeinfo is_numeric_comparable<v>(OpCode.op_mov_c_a))>((a=4,a:=1),(v=2%[])),[]>(3?7:6)}[p]options _
def n{unsafe{}}

$ daslang t.das
assertion failed: !firstType || (!firstType->ref && !firstType->constant && !firstType->temporary), src/ast/ast_typedecl.cpp:1880

The comment on that line says ref/const/temporary should live on the outermost fixed-array node only.

5. Generic alias resolution reaches an unreachable branch

require UnitTest
struct v {}

[export]
def v0r0(r : l() <- UNIT_TEST_CONSTANT, v) => 0 is t[0]

def n {
    ({ (v0r0(){} is b) })
}

$ daslang t.das
assertion failed: 0, src/ast/ast_infer_type_function.cpp:1911
we should not be here. function matched arguments!

Both of the last two are reduced with afl-tmin and then a character-level delta debugger targeting the assertion line: 407 -> 194 and 416 -> 107 bytes. They stay dense. Every attempt to rewrite them into idiomatic form hit a syntax or type error before reaching the assertion, so the exact token sequence matters — in #4, [p]options _ in particular has to stay on that line, since putting [p] on its own line makes it an annotation for options and the assertion no longer fires.