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-0382 allows macro parameters to have default arguments. Enable these
default arguments, with the normal type checking rules. One
significant quirk to this implementation is that the actual default
argument values don't make it to the macro implementation. This is a
previously-unconsidered design problem we'll need to address.
Tracked by rdar://104043987.
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.
And adjust contextual parameter modifier parsing in general to be more
properly contextual, so we don't have to reserve `__shared` or `__owned`,
or their successor spellings, as argument labels anymore.
And do a first pass of auditing existing uses of the parameter specifiers to
make sure that we look at the ValueOwnership mapping in most cases instead of
individual modifiers.
This lets us consolidate code paths that mostly run in parallel over the
existing InOutTypeRepr/SharedTypeRepr/OwnedTypeRepr family of types. This
patch by itself is NFC but makes it easier to introduce new spellings,
particularly the newly-official `borrowing` and `consuming` modifiers
that were approved in SE-0377.
Per the current proposal, these are to be specified
explicitly, as they form an important part of the API.
Bonus: This commit includes a fix to make
`CompileTimeConstTypeRepr` a proper `isa<>` subtype of
`SpecifierTypeRepr`, since we forgot to add it to
that type's `classof` function.
resolves rdar://105480354
The "local context" was only used to prevent parsing of closures in a
non-local context, and also string interpolations because they are
similar-ish to closures. However, this isn't something a parser should
decide, so remove this special-case semantic check from the parser and
eliminate the notion of "local context" entirely.
The lexer will be responsible for knowing whether we have a code completion token, everything else will also work for other IDE inspection features.
The changes start to really make sense once I rename CodeCompletion -> IDEInspection in a lot of places.
Typing `func foo() await {` is something that folks do from time-to-time.
The old error message was unintuitive and suggested adding a semicolon
between the parenthesis and the await, then proceeded to complain about
the opening brace. This wasn't very clear about what the error actually
was.
Pulling this in line with `try`, `throw`, and `throws`, this patch
suggests replacing `await` with `async` when in the function effect
position, and provides a nice fix-it.
Previously, when we reached the maximum nesting level, we changed the current token’s kind to an EOF token. A lot of places in the parser are not set up to expect this token change. The intended workaround was to check whether pushing a structure marker failed (which would change the token kind) and bail out parsing if this happened. This was fragile and caused assertion failures in assert builds.
Instead of changing the current token’s kind, and failing to push the structure marker, let the lexer know that it should cut off lexing, essentially making the input buffer stop at the current position. The parser will continue to consume its current token (`Parser.Tok`) and the next token that’s already lexed in the lexer (`Lexer.NextToken`) before reaching the emulated EOF token. Thus two more tokens are parsed than before, but that shouldn’t make much of a difference.
Split up the expr list parsing members such that
there are separate entry points for tuple and
argument list parsing, and start using the argument
list parsing member for call and subscripts.
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
We weren’t setting the code completion token status correctly when parsing patterns with code completion tokens.
Because of this, in the added test case, the `searchSubject` gets added as a member of `Foo` twice - once in the first pass and once in the second pass, causing an assertion failure.
Fixes rdar://80575116 [SR-14687]
With the introduction of `isolated` as
a type modifier for actor types, the
parsing of a parameter regressed such
that `isolated` was no longer accepted
as an ordinary argument label. This patch
fixes that and adds a little lookahead
utility to clean-up the code that
disambiguates the uses of `isolated`
as either a label or a type modifier.
Resolves rdar://80300022
- Allow named opaque types in typed patterns and subscripts
- Fix inheritance clause printing for `GenericParamList`
- clang-format changes from previous commit on this branch
In order to put constraints on opaque types in function returns, we want to
support naming them like 'func f() -> <T> T { }'. This commit parses that
syntax into the new `OpaqueReturnParameteriedTypeRepr`. This is hidden behind
the new flag --enable-experimental-opaque-return-types.