File: Assert.swift

package info (click to toggle)
swiftlang 6.1.3-1
  • links: PTS, VCS
  • area: main
  • in suites: forky
  • size: 2,791,532 kB
  • sloc: cpp: 9,901,743; ansic: 2,201,431; asm: 1,091,827; python: 308,252; objc: 82,166; f90: 80,126; lisp: 38,358; pascal: 25,559; sh: 20,429; ml: 5,058; perl: 4,745; makefile: 4,484; awk: 3,535; javascript: 3,018; xml: 918; fortran: 664; cs: 573; ruby: 396
file content (82 lines) | stat: -rw-r--r-- 3,158 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
//===----------------------------------------------------------------------===//
//
// 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 preferable 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 = #fileID,
  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 = #fileID,
  line: UInt = #line
) {
  #if SWIFTSYNTAX_ENABLE_ASSERTIONS
  fatalError(message(), file: file, line: line)
  #else
  Swift.assertionFailure(message(), file: file, line: line)
  #endif
}

// MARK: - Precondition

/// Override Swift’s `precondition` with slightly changed semantics.
/// In release builds, it also emits the error message upon failure, like `fatalError`.
/// It can also be disabled by setting the `SWIFTSYNTAX_DISABLE_PRECONDITION` conditional compilation flag.
/// Note that `SWIFTSYNTAX_DISABLE_PRECONDITION` does not disable `preconditionFailure`.
@_transparent
public func precondition(
  _ condition: @autoclosure () -> Bool,
  _ message: @autoclosure () -> String = String(),
  file: StaticString = #fileID,
  line: UInt = #line
) {
  #if !SWIFTSYNTAX_DISABLE_PRECONDITIONS
  if !_fastPath(condition()) {
    fatalError(message(), file: file, line: line)
  }
  #endif
}