Enable assertions in CI even if we are building in release builds

Package.swift

@@ -12,13 +12,14 @@ if ProcessInfo.processInfo.environment["SWIFT_BUILD_SCRIPT_ENVIRONMENT"] != nil
     .appendingPathComponent("utils")
     .appendingPathComponent("group.json")
   swiftSyntaxSwiftSettings = [
+    .define("SWIFTSYNTAX_ENABLE_ASSERTIONS"),
     .unsafeFlags([
       "-Xfrontend", "-group-info-path",
       "-Xfrontend", groupFile.path,
       // Enforcing exclusivity increases compile time of release builds by 2 minutes.
       // Disable it when we're in a controlled CI environment.
       "-enforce-exclusivity=unchecked",
-    ])
+    ]),
   ]
 } else {
   swiftSyntaxSwiftSettings = []

Sources/SwiftSyntax/Assert.swift

@@ -0,0 +1,53 @@
+//===----------------------------------------------------------------------===//
+//
+// This source file is part of the Swift.org open source project
+//
+// Copyright (c) 2014 - 2022 Apple Inc. and the Swift project authors
+// Licensed under Apache License v2.0 with Runtime Library Exception
+//
+// See https://swift.org/LICENSE.txt for license information
+// See https://swift.org/CONTRIBUTORS.txt for the list of Swift project authors
+//
+//===----------------------------------------------------------------------===//
+
+/// How to choose `assert` vs. `precondition`:
+///  - Wherever possible, it is preferrable to emit a diagnostic instead of
+///    using `precondition`. This way the parser won't crash if the condition is
+///    violated.
+///  - If you think the diagnostic added above should never be emitted, it is
+///    fine to also emit an `assertionFailure` in debug builds to make it easier
+///    to debug the unexpected diagnostic.
+///  - If in doubt always use `precondition`
+///  - `assert` should only be used if checking the assertion has a non-trivial
+///    cost and provides little benefit in terms of safety in release builds.
+
+// MARK: - Assert
+
+/// An assertion that is active in DEBUG builds, just like `Swift.assert` and
+/// additionally if assertions are explicitly requested by setting the
+/// `SWIFTSYNTAX_ENABLE_ASSERTIONS` conditional compilation flag.
+/// Use this instead of `precondition` in places where the assertion has a
+/// non-trivial cost but provides little value in release builds.
+@_transparent
+public func assert(_ condition: @autoclosure () -> Bool, _ message: @autoclosure () -> String = String(), file: StaticString = #file, line: UInt = #line) {
+  #if SWIFTSYNTAX_ENABLE_ASSERTIONS
+  if !_fastPath(condition()) {
+    fatalError(message(), file: file, line: line)
+  }
+  #else
+  Swift.assert(condition(), message(), file: file, line: line)
+  #endif
+}
+
+/// An assertion that is active in DEBUG builds, just like
+/// `Swift.assertionFailure` and additionally if assertions are explicitly
+/// requested by setting the `SWIFTSYNTAX_ENABLE_ASSERTIONS` conditional
+/// compilation flag.
+@_transparent
+public func assertionFailure(_ message: @autoclosure () -> String = String(), file: StaticString = #file, line: UInt = #line) {
+  #if SWIFTSYNTAX_ENABLE_ASSERTIONS
+  fatalError(message(), file: file, line: line)
+  #else
+  Swift.assertionFailure(message(), file: file, line: line)
+  #endif
+}

Sources/SwiftSyntax/CMakeLists.txt

@@ -8,6 +8,7 @@
 
 add_swift_host_library(SwiftSyntax
   AbsolutePosition.swift
+  Assert.swift
   BumpPtrAllocator.swift
   CommonAncestor.swift
   IncrementalParseTransition.swift

utils/group.json

@@ -55,6 +55,7 @@
     "TokenDiagnostic.swift",
   ],
   "Internal": [
+    "Assert.swift",
     "SyntaxArena.swift",
     "SyntaxVerifier.swift",
     "BumpPtrAllocator.swift",