We've been converging the implementations of educational notes and
diagnostic groups, where both provide category information in
diagnostics (e.g., `[#StrictMemorySafety]`) and corresponding
short-form documentation files. The diagnostic group model is more
useful in a few ways:
* It provides warnings-as-errors control for warnings in the group
* It is easier to associate a diagnostic with a group with
GROUPED_ERROR/GROUPED_WARNING than it is to have a separate diagnostic
ID -> mapping.
* It is easier to see our progress on diagnostic-group coverage
* It provides an easy name to use for diagnostic purposes.
Collapse the educational-notes infrastructure into diagnostic groups,
migrating all of the existing educational notes into new groups.
Simplify the code paths that dealt with multiple educational notes to
have a single, possibly-missing "category documentation URL", which is
how we're treating this.
This removes the implementation of the `swift-indent` tool, its
associated documentation, and utilities. This tool was never completed
and has much better alternatives with `swift-format` which is more
flexible and actually maintained.
This document describes how debug info works at the SIL level and how to
correctly update debug info in SIL optimization passes. This document is
inspired by its LLVM analog, "How to Update Debug Info: A Guide for LLVM Pass
Authors", which can be found at https://llvm.org/docs/HowToUpdateDebugInfo.html
It was originally designed for faster trasmission of syntax trees from
C++ to SwiftSyntax, but superceded by the CLibParseActions. There's no
deserializer for it anymore, so let's just remove it.
Swift now builds cleanly out of the box as of OpenBSD 6.8-beta.
While there are still more unit test tweaks to be made, document the
preparation and other quirk flags necessary to get a clean build on this
system.
This improves upon the existing documentation to provide a clearer end-to-end
workflow for new contributors and people who wish to build the toolchain
locally but do not intend to submit patches.
We also provide more directions for systematically utilizing our existing
documentation.
A specification for Swift's dynamic casting operations.
This specification tries to reflect the _intent_ of the current implementation, defining a consistent behavior that reflects as far as possible the behavior of the current implementation. Deviations from this specification will generally be treated as bugs in the current implementation.