@@ -67,6 +67,25 @@ print the SIL *and* the LLVM IR, you have to run the compiler twice.
67
67
The output of all these dump options (except ``-dump-ast ``) can be redirected
68
68
with an additional ``-o <file> `` option.
69
69
70
+ Debugging Diagnostic Emission
71
+ -----------------------------
72
+
73
+ Asserting on first emitted Warning/Assert Diagnostic
74
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
75
+
76
+ When changing the type checker and various SIL passes, one can cause a series of
77
+ cascading diagnostics (errors/warnings) to be emitted. Since Swift does not by
78
+ default assert when emitting such diagnostics, it becomes difficult to know
79
+ where to stop in the debugger. Rather than trying to guess/check if one has an
80
+ asserts swift compiler, one can use the following options to cause the
81
+ diagnostic engine to assert on the first error/warning:
82
+
83
+ * -Xllvm -swift-diagnostics-assert-on-error=1
84
+ * -Xllvm -swift-diagnostics-assert-on-warning=1
85
+
86
+ These allow one to dump a stack trace of where the diagnostic is being emitted
87
+ (if run without a debugger) or drop into the debugger if a debugger is attached.
88
+
70
89
Debugging the Type Checker
71
90
--------------------------
72
91
@@ -131,16 +150,6 @@ typing ``:constraints debug on``::
131
150
*** Type ':help' for assistance. ***
132
151
(swift) :constraints debug on
133
152
134
- Asserting on First Error
135
- ~~~~~~~~~~~~~~~~~~~~~~~~
136
-
137
- When changing the typechecker, one can cause a series of cascading errors. Since
138
- Swift doesn't assert on such errors, one has to know more about the typechecker
139
- to know where to stop in the debugger. Rather than doing that, one can use the
140
- option ``-Xllvm -swift-diagnostics-assert-on-error=1 `` to cause the
141
- DiagnosticsEngine to assert upon the first error, providing the signal that the
142
- debugger needs to know that it should attach.
143
-
144
153
Debugging on SIL Level
145
154
----------------------
146
155
0 commit comments