Specifically, lldb resolves the breakpoint normally and then adjusts the
breakpoint address according to the value passed to -R. This is really useful
with -n (function name) and -M (method name) breakpoints across multiple-runs of
the debugger.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
This flag adds diagnostic names to the end of their messages, e.g. 'error: cannot convert value of type '[Any]' to specified type '[Int]' [cannot_convert_initializer_value]'. It's intended to be used for debugging purposes when working on the compiler.
These options do not make sense just in the type checker section since they can
also be used to diagnose why SIL passes emit diagnostics as well.
Since the prose was originally written, I also added an additional option to
assert on the first warning emitting. I added that to the documentation.
For details see the comment in split-cmdline
I put this under a new directory utils/dev-script because we have so much stuff in utils already.
Other, similar scripts can then be added in dev-scripts as well.
I ran into such an issue and realized I didn't know how to dump SIL from LLDB
and more importantly that it was not documented anywhere. Now it is documented
and I can avoid bugging Jim Ingham on this topic ever again.
Specifically, I tried to make it clearer that viewcfg does not rely on any type
information or declarations (i.e. it can dump raw textual CFGs). This also means
that it can be used in an editor to dump CFGs at your cursor?!
Thanks Erik for showing me this!
- Update the Pygments lexer we use for parsing Swift-like code.
- State more explicitly which highlighting should be used in which
code blocks.
- Disable highlighting altogether in certain cases (such as SIL.rst,
which has equal amounts grammar and SIL excerpts).
This should fix the warnings-as-error issues coming from Sphinx > 1.3.4.
Based on a patch by Jeremy Fergason!
https://bugs.swift.org/browse/SR-620
This change follows up on an idea from Michael (thanks!).
It enables debugging and profiling on SIL level, which is useful for compiler debugging.
There is a new frontend option -gsil which lets the compiler write a SIL file and generated debug info for it.
For details see docs/DebuggingTheCompiler.rst and the comments in SILDebugInfoGenerator.cpp.
'Ss' appears in manglings tens of thousands of times in the standard library and is also incredibly frequent in other modules. This alone is enough to shrink the standard library by 59KB.
Swift SVN r32409
It is useful if you have the SIL already in a file (instead of calling viewCFG() while running the compiler in lldb).
Especially useful for vim users: see the comment in the script on how to add commands to view the CFG from inside vim.
Swift SVN r30186
