Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
We were re-parsing each source file for each top-level diagnostic emitted,
which is... rather inefficient. Cache the parsed source files until
the PrintingDiagnosticConsumer goes away.
Merge with BasicBridging and ASTBridging
respectively. The changes here should be pretty
uncontroversial, I tried to keep it to just moving
code about.
* BridgedString for ASTGen -> C++ string returnings
* Null terminated C-strings for C++ -> ASTGen string arguments
* UnsafeMutableRawPointer for C++ -> ASTGen diagnostic engine arguments
For whatever reason, using standard headers in modules imported from
Swift code (i.e. depending on Darwin overlay) is no longer an issue.
rdar://115438609
Conflicts:
- `CMakeLists.txt` caused by the extra `-D` added in rebranch to
reduce the number of deprecation warnings.
- `lib/Frontend/PrintingDiagnosticConsumer.cpp` caused by the removal
of one of the `#if SWIFT_SWIFT_PARSER` on rebranch (probably should
have been done on main).
Use FetchContent to include swift-syntax directly in swift. This can be
thought of as an `add_subdirectory` for a directory outside the root.
The default build directory will be `_deps/swiftsyntax-subbuild/`, though
the modules and shared libraries will be built in `lib/swift/host` by
passing down `SWIFT_HOST_LIBRARIES_DEST_DIR` to avoid copying them as we
were doing previously.
We'll be using the new swift-syntax diagnostic formatter in the near
future, as it is nearly available on all host platforms. So, remove
the C++ formatter that did source-line annotation, falling back to the
"LLVM" style when swift-syntax is not compiled in.
The "grouped diagnostics" feature can handle multiple
warnings/errors/remarks in a single grouping, but doing so isn't very
ergonomic for users because the primary warning/error/remark can be
buried in the source file. As a first step toward improving this
situation, always break up groups at a new warning/error/remark.
We're going to move toward the new swift-syntax formatter. Use it for
the "swift" diagnostic style instead of the experimental formatter
written in C++.
There are some tests for the experimental formatter in C++ that test
precise formatting of diagnostics. I've disabled them in the same
places where the new swift-syntax formatter is enabled, for now. We
may choose to remove them entirely, because swift-syntax itself is
where the specific format is defined, and has those same kinds of
tests already.
Use the new "grouped diagnostics" feature of the swift-syntax
diagnostic rendering to emit printed diagnostics under the
swift-syntax diagnostic style. This emits macro expansion buffers as
text to the terminal, inset in a box where the macro was expanded, so
that there is more context for understanding how the macro was
expanded and what went wrong inside it.
Add frontend flag `-emit-macro-expansion-files diagnostics` to emit any
macro expansion buffers referenced by diagnostics into files in a
temporary directory. This makes debugging type-checking failures in
macro expansions far easier, because you can see them after the
compiler process has exited.
The SwiftDiagnostics module within swift-syntax has a diagnostic
pretty-printer that does a nice rendering of the source code with
diagnostics placed inside gaps between the code lines.
Introduce another `-diagnostic-style` argument, `swift-syntax`,
to bridge from the pretty-printed C++ diagnostics over to the
swift-syntax diagnostics engine.
This default formatting style remains the same "LLVM style". "Swift style"
is what was previously enabled via -enable-experimental-diagnostic-formatting
- Always use the line number in the actual source file when extracting excerpts and adding highlights/fix-its
- Always use the display name when printing excerpt titles
- Don't print surrounding lines when an annotated line is in a virtual file
This reverts commit f919e047834eddf8863723b9db1fcb8d344d2006.
- Bold diagnostic message text
- Change line numbers and file header to unbolded cyan color to emphazize code snippets/message text
- More compact printing of a single message with unknown location
- If a diagnostic includes excerpts from multiple files, horizontally align the line numbers
- Indent filenames with '=' so they appear to the right of line numbers
* [Diagnostics] Turn educational notes on-by-default
* [Diagnostics] Only include educational notes in printed output if -print-educational-notes is passed
* Make -print-educational-notes a driver option
* [Diagnostics] Issue a printed remark if educational notes are available, but disabled
* [docs] Update educational notes documentation and add a contributing guide
* [Diagnostics] Cleanup PrintingDiagnosticConsumer handling of edu notes
* Revert "[Diagnostics] Issue a printed remark if educational notes are available, but disabled"
For now, don't notify users if edu notes are available but disabled. This decision can be reevaluated later.
