This doesn't have a specific effect now, because all of these places
are likely to only see NameAliasType, but it is refactoring with the
intent of eliminating NameAliasType entirely.
Introduce a new Type node, BoundNameAliasType, which describes a
reference to a typealias that requires substitutions to produce the
underlying type. This new type node is used both for references to
generic typealiases and for references to (non-generic) typealiases
that occur within generic contexts, e.g., Array<Int>.Element.
At present, the new type node is mainly useful in preserving type
sugar for diagnostics purposes, as well as being reflected in other
tools (indexing, code completion, etc.). The intent is to completely
replace NameAliasType in the future.
This enables one to easily drop down into the debugger in such cases. This is
enabled by the option swift-diagnostics-assert-on-error and can only happen in
an asserts build.
rdar://34222540
This allows reporting successful and unsuccessful optimizations similar to
clang/llvm.
This first patch adds support for the
options -Rpass=<pass-name-regex> -Rpass-missed=<pass-name-regex>. These allow
reporting successful/unsuccessful optimization on the compiler output for passes
specified by the regex. I've also added one missed and one passed remark type
to the inliner to test the infrastructure.
Clang also has the option of collecting these records in an external YAML data
file. This will be added in a later patch.
A few notes:
* The goal is to use this facility for both user-lever "performance" warnings
and expert-level performance analysis. There will probably be a flag in the
future differentiating the verbosity.
* The intent is match clang/llvm as much as it makes sense. On the other hand I
did make some changes. Unlike in llvm, the emitter is not a pass which
simplifies things. Also the remark class hierarchy is greatly simplified since
we don't derive from DiagnosticInfo. We also don't derive from Diagnostic to
support the streaming API for arbitrary named-value pairs.
* Currently function names are printed mangled which should be fixed.
Previously we had more ad hoc logic that tried to decide if it was
worth desugaring a type based on its structure. Now we instead look
for a typealias that might actually benefit from desugaring, and if
we don't find one we won't show the 'aka' note.
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
This was causing us to emit diagnostics talking about τ_m_n, which is
not helpful.
Now that generic function types print sanely, print them in a few
places where we were previously printing PolymorphicFunctionTypes.
When replace something with a punctuator, we often prefer adding spaces around it.
For instance,
func foo(): bar {}
// fix it
func foo() -> bar {}
In this case we want to add a space before '->', but not after that.
With this change, we can simply `fixItReplace(ColonLoc, " -> ")`.
`fixItReplace()` automatically adjust the spaces around it.
Exposes the global warning suppression and treatment as errors
functionality to the Swift driver. Introduces the flags
"-suppress-warnings" and "-warnings-as-errors". Test case include.
Diagnostic categories are entirely unused and arguably useless as
implemented, as they merely denote the sub-component of the
compiler.
As far as categorizing warnings are concerned, I'm abandoning the
effort for now, as the utility is marginal and Swift and the Swift
compiler are probalby not ready for these to be nailed down. For the
sake of cleanliness, the CATEGORY field is also stripped from
WARNINGS.
If there's a need for automatic identifying of compiler sub-components
for diagnstics in the future, there are better ways to do this.
NFC
Restores StoredDiagnosticInfo, which is useful to help distinguish
when the user explicitly modifies the behavior of a diagnostic vs
we're just picking up the default kind.
Adds some clarifying comments, and lays out the suppression workflow,
whereby different types of suppression (per-diagnostic, per-category,
etc) have different precedence levels.
New API on DiagnosticEngine to disable the reporting of warnings. No
tests currently, as this is not exposed upwards to any test-able
level, but tests will come when this is exposed e.g. through command
line arguments.
Refactor DiagnosticEngine to separate out diagnostic state
tracking. This allows gives us a base from which to add further
refinements, e.g. warning suppression.
This is necessary for some other work I'm doing, which really wants
paramdecls to have reasonable declcontexts. It is also a small step
towards generic subscripts.
This way they can be used from other projects, like LLDB. The downside
is we now have to make sure the header is included consistently in all
the places we care about, but I think in practice that won't be a problem,
especially not with tests.
rdar://problem/22240127
Swift SVN r31173
