Bump slang to dd16a7947e0586d0541477f1b4b60eda7c986e35

[jpienaar]

We encountered some failures that were addressed since 9.0 tag, given no API changes seemed like good to bump to new version.

[fabianschuiki]

Sounds good to me! Thanks for establishing a precedence to pull in up-to-date Slang versions similar to how we bump LLVM 💯

[jpienaar]

@fabianschuiki with this change though I get the following diff which I'm not sure if acceptable/bug introduced

From

module GenerateConstructs;
  genvar i;
  parameter p = 2;
  
  generate
    // CHECK: [[TMP:%.+]] = moore.constant 0
    // CHECK: dbg.variable "i", [[TMP]]
    // CHECK: [[TMP:%.+]] = moore.constant 0
    // CHECK: %g1 = moore.variable [[TMP]]
    // CHECK: [[TMP:%.+]] = moore.constant 1
    // CHECK: dbg.variable "i", [[TMP]]
    // CHECK: [[TMP:%.+]] = moore.constant 1
    // CHECK: moore.variable name "g1" [[TMP]]
    for (i = 0; i < 2; i = i + 1) begin
      integer g1 = i;
    end

I can just update the test but unsure if expected.

[fabianschuiki]

That diff looks okay. It seems like Slang now calls unnamed generate blocks genblk, which feels like a reasonable thing to do.

[jpienaar]

Seems the cmake fetch fails if one uses a hash that's not near tip (https://gitlab.kitware.com/cmake/cmake/-/issues/23379), given its opt in, would making it non-shallow be fine?

[fabianschuiki]

I'm definitely fine with doing a non-shallow fetch. Maybe keep the shallow option as a comment for whenever we switch to a specific version tag?

[fabianschuiki]

LGTM once CI is happy 👍 Thanks for keeping us up-to-date with Slang bug fixes!