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.
* Include `DeclContext` of the node where possible
* Add 'default-with-decl-contexts' dump style that dumps the dect context
hierarchy in addition to the AST
* Support `-dump-parse` with `-dump-ast-format json`
When iterator consists of tuple of variable and iteration only mutates
the tuple partially, improve the warning message from "changing to 'let"
to "changing the pattern to '(..., case let, ...)"
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
Rather than walking into the inactive regions of IfConfigDecls looking for
references to a declaration before we diagnose it, go to the syntax
tree and look through inactive *and unparsed* regions for identifier
tokens that match. If we find one, suppress the diagnostic.
This reduces our dependency on IfConfigDecl in the AST, and also makes
the same suppression work with code in unparsed regions that had no
representation in IfConfigDecl.
In this PR i worked on replacing the word accessor in diagnostics with more user-facing terminologies like setter, getter, didSet Observer, and members based on the context of the message.
in some messages i didn't need to pass DescriptiveDeclKind instead i just changed the text copy itself.
i also updated tests, so you might find it easier to check my changes this way.
Please let me know if there's something i should've done in a better way, and request changes if needed. !
i can squash my commits after reviewing getting the PR Reviewed, just to make it easier to be checked commit by commit
Resolves#55887
Previously, missing return diagnostics for unreachable subscripts
differed from the treatment unreachable functions received, leading to
inconsistent diagnostic behavior. This change removes the responsibility
for handling the relevant diagnostics from the AST code, in favor of the
diagnostics implemented via the SIL optimizer. Additionally, where the
AST-generation code would previously have diagnosed a missing return for
an implicit empty getter, it will now admit as valid, deferring the
missing return diagnostics to the later SIL passes.
This looks like it was never properly implemented, since when we generate the
memberwise initializer for the struct in SILGen, it incorrectly tries to apply
the entire initializer expression to each variable binding in the pattern,
rather than destructuring the result and pattern-matching it to the variables.
Since it never worked it doesn't look like anyone is using this, so let's
put up an error saying it's unsupported until we can implement it properly.
Add `StructLetDestructuring` as an experimental feature flag so that tests around
the feature for things like module interface printing can still work.
This PR refactors the ASTDumper to make it more structured, less mistake-prone, and more amenable to future changes. For example:
```cpp
// Before:
void visitUnresolvedDotExpr(UnresolvedDotExpr *E) {
printCommon(E, "unresolved_dot_expr")
<< " field '" << E->getName() << "'";
PrintWithColorRAII(OS, ExprModifierColor)
<< " function_ref=" << getFunctionRefKindStr(E->getFunctionRefKind());
if (E->getBase()) {
OS << '\n';
printRec(E->getBase());
}
PrintWithColorRAII(OS, ParenthesisColor) << ')';
}
// After:
void visitUnresolvedDotExpr(UnresolvedDotExpr *E, StringRef label) {
printCommon(E, "unresolved_dot_expr", label);
printFieldQuoted(E->getName(), "field");
printField(E->getFunctionRefKind(), "function_ref", ExprModifierColor);
if (E->getBase()) {
printRec(E->getBase());
}
printFoot();
}
```
* Values are printed through calls to base class methods, rather than direct access to the underlying `raw_ostream`.
* These methods tend to reduce the chances of bugs like missing/extra spaces or newlines, too much/too little indentation, etc.
* More values are quoted, and unprintable/non-ASCII characters in quoted values are escaped before printing.
* Infrastructure to label child nodes now exists.
* Some weird breaks from the normal "style", like `PatternBindingDecl`'s original and processed initializers, have been brought into line.
* Some types that previously used ad-hoc dumping functions, like conformances and substitution maps, are now structured similarly to the dumper classes.
* I've fixed the odd dumping bug along the way. For example, distributed actors were only marked `actor`, not `distributed actor`.
This PR doesn't change the overall style of AST dumps; they're still pseudo-S-expressions. But the logic that implements this style is now isolated into a relatively small base class, making it feasible to introduce e.g. JSON dumping in the future.
Default initializable init properties shouldn't prevent default
init synthesis and such properties without anything to initialize
should be considered by it.
Fixes a bug were default initializer for an init accessor property
hasn't been synthesized even when the property is marked as default
initializable.
Resolves: rdar://113421273
Per the clarification during the review thread, all properties with
init accessors (including those that do not initialize any underlying
storage) are part of the memberwise initializer.
Initialization expressions are not allowed on computed properties
but if a property has `init` accessor it should be allowed because
it could be used by a memberwise initializer.
Skip stored properties that are initialized via init accessors and
emit parameters/initializations in field order which allows us to
cover more use-cases.
If some property is initializable by one than one init accessor
let's not sythesize a memberwise initializer in that case because
it's ambiguous what is the best init accessor to use.
If init accessor initialize the same properties, let's emit them
in sequence and emit `destroy_addr` in-between to make sure that
there is no double initialization.
