Now that ASTGen should be able to generate most Swift code. Let's
remove "legacy parser" call-in, and remove the unhealthy cyclic
dependency between lib/Parse and ASTGen.
Allow any declaration to be marked with `@unsafe`, meaning that it
involves unsafe code. This also extends to C declarations marked with
the `swift_attr("unsafe")` attribute.
Under a separate experimental flag (`DisallowUnsafe`), diagnose any
attempt to use an `@unsafe` declaration or any unsafe language feature
(such as `unowned(unsafe)`, `@unchecked Sendable`). This begins to
define a "safe" mode in Swift that prohibits memory-unsafe constructs.
Previously we would only diagnose and recover for
invalid tokens following a `#if` body for the decl
and postfix expression case. Sink this logic into
`parseIfConfigRaw`, ensuring that we do this for
all `#if` cases. This requires propagating the
context we're parsing in to customize the
diagnostic.
The issue is that the shorthand if let syntax injects an implicit
expression: https://github.com/apple/swift/pull/40694/ in ParseStmt and
that the 'diagnoseUnhandledAsyncSite' explicitly avoids reporting errors
in implicit expressions.
This change is that we don't mark the implicit declref code emitted by
the `if let prop` as implicit anymore, and this way the reporting works
out as expected.
Added some tests covering this as well as properly erroring out for the
nonexistent syntax of shortand + awaiting which doesn't exist, and we
properly error on it.
Resolves rdar://126169564
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)
This should allow us to eventually simplify parsing of simple string literals in the new parse by not having to handle indentation of multiline string literals.
Previously, 'IntroducerLoc' and 'ThePattern' were only used for pattern
binidng cases. Create a new 'ConditionalPatternBindingInfo' type to
cover such cases, and make 'StmtConditionElement' a pure 'PointerUnion'
type.
This makes it clear which fields are used in which condition kind. Also,
we can expect overall size reduction of StmtCondition when the
majority of the conditions are simple boolean expressions.
Correctly determining the DeclContext needed for an
ExplicitCaughtTypeRequest is tricky for a number of callers, and
mistakes here can easily lead to redundant computation of the caught
type, redundant diagnostics, etc.
Instead, put a `DeclContext` into `DoCatchStmt`, because that's the
only catch node that needs a `DeclContext` but does not have one.
During the review of SE-0413, typed throws, the notion of a `do throws`
syntax for `do..catch` blocks came up. Implement that syntax and
semantics, as a way to explicitly specify the type of error that is
thrown from the `do` body in `do..catch` statement.
* 'ASTGenVisitor' has a reference to a legacy C++ Parser configured for
ASTGen.
* If 'ASTGenVisitor' encounters a AST node that hasn't been migrated,
call parse(Decl|Stmt|Expr|Type) to parse the position using the legacy
parser.
* The legacy parser calls ASTGen's
'swift_ASTGen_build(Decl|Stmt|Expr|Type)' for each ASTNode "parsing"
(unless the call is not directly from the ASTGen.)
rdar://117151886
'ParseDeclOptions' can be trivially calculated solely from the current
decl context. To reduce the number of the contextual parameters,
calculate it inside the function.
Parse typed throw specifiers as `throws(X)` in every place where there
are effects specified, and record the resulting thrown error type in
the AST except the type system. This includes:
* `FunctionTypeRepr`, for the parsed representation of types
* `AbstractFunctionDecl`, for various function-like declarations
* `ClosureExpr`, for closures
* `ArrowExpr`, for parsing of types within expression context
This also introduces some serialization logic for the thrown error
type of function-like declarations, along with an API to extract the
thrown interface type from one of those declarations, although right
now it will either be `Error` or empty.
These allow multi-statement `if`/`switch` expression
branches that can produce a value at the end by
saying `then <expr>`. This is gated behind
`-enable-experimental-feature ThenStatements`
pending evolution discussion.
We didn’t actually have any tests for this. Completions aren’t great here at the moment but since this is an underscored language feature it’s not that important at the moment.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
SE-390 concluded with choosing the keyword discard rather than forget for
the statement that disables the deinit of a noncopyable type. This commit
adds parsing support for `discard self` and adds a deprecation warning for
`_forget self`.
rdar://108859077
Instead of assuming that `if let <expr>` is meant
to be `if case <expr> = ...`, turn it into
`if let _ = <expr>`, which is consistent with
the fix-it we suggest.
This currently doesn't have much of an effect on
the diagnostics we produce, but will be important
once we start doing bidirectional inference for
ExprPatterns, as it avoids unhelpful diagnostics.
Cursor info only cares about the `doneParsing` callback and not about all the `complete` functions that are now defined in `CodeCompletionCallbacks`. To make the design clearer, split `IDEInspectionCallbacks`.
rdar://105120332
This replaces `synthesizeTildeEqualsOperatorApplication`,
and synthesizes the match expression and var
on-demand.
Additionally, it pushes the lookup logic into
pre-checking.
In my earlier commit that attempted to do this I wasn't aggressive enough. In
this commit, I was more aggressive in putting it behind a flag and as a result
we reject all of the patterns in the tests I added into tree.
