Xcode 26.4 - Testing - '@const' value should be initialized with a compile-time value

Development Swift Testing
1

Hello,

Today I downloaded Xcode 26.4 (coming from 26.3) and all my unit test files with Swift Testing are showing this error: @Const' value should be initialized with a compile-time value

Has anyone faced this before? I can’t find any resource in the web. I also tried with Claude but nothing is solving the issue for me.

@Suite(.serialized)

struct ConfigurationTests {
@Test

func testDependency() {

#expect(throws: Never.self) { Container.someContainer ~> Protocol.self } // Swinject container

}
}

2

Is @SuiteSuiteSuiteSuite actually a macro you're using or is it just a typo? :slightly_smiling_face: If the former, you may be running into #79447.

Otherwise, please open a GitHub issue against Swift Testing and attach a complete/verbose build log. Thanks!

3

I've seen this when I had other build issues in my @Test function. I don't recall if it was a particular type of error, but I think it's exacerbated by issues in the #expect itself, so try pulling that statement out and see if it compiles separately.

4

Not sure where that came from! I just updated the sample. It’s just the regular Swift Testing Suite macro.

5

Actually, I commented all the tests in the struct and only left this

@Suite(.serialized)

struct ConfigurationTests { }

and it stills shows the error

6

This might sound ridiculous, but did you attempt removing the blank line between @Suite and struct? I had this issue once, where the tests didn’t compile until I, in my case, added a blank line.

7

This seems to be an issue with the website when using block quotes. I have encountered this issue a few times already, and it seems to occur rather sporadically.

2 Likes
8

Thanks for answering! That space was caused by this webpage formatting, in code there was no extra line :)

9

There's a bug in the Swift 6.3 compiler that causes it to emit spurious errors about @const. You can generally ignore those when they come from Swift Testing, and the bug is fixed in the 6.4 toolchain (am hoping for a 6.3.x backport as well).

Somewhere else in the build log should be a different error that is the actual cause of the failure.

1 Like