I want to reserve Feature::MoveOnly only for move-only types and other
things that are part of SE-390. Other prototyped features like
noimplicitcopy and some older names for consume were left behind
as guarded by this Feature. That's really not the right way to do it,
as people will expect that the feature is enabled all the time, which
would put those unofficial features into on-by-default. So this change
introduces two new Features to guard those unofficial features.
The MSVC 2019 14.29 toolset seems to not properly handle the member variable reference in this case. Workaround this by explicitly using the `this` identifier to indicate that we would like to access the member variable. This is repaired in newer toolsets, however, the CI is currently using the older toolset.
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
Allow freestanding macros to be used at top-level.
- Parse top-level `#…` as `MacroExpansionDecl` when we are not in scripting mode.
- Add macro expansion decls to the source lookup cache with name-driven lazy expansion. Not supporting arbitrary name yet.
- Experimental support for script mode and brace-level declaration macro expansions: When type-checking a `MacroExpansionExpr`, assign it a substitute `MacroExpansionDecl` if the macro reference resolves to a declaration macro. This doesn’t work quite fully yet and will be enabled in a future fix.
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.
This fixes an issue if the range ends with a string literal that contains the IDE inspection target. In that case the end of the range will point to the start of the string literal but the IDE inspection target is inside the string literal and thus after the range’s end.
Extend handling of incomplete multi-line string literals during input in
REPL to also cover raw multi-line strings.
Fixes#52840 and apple/llvm-project#4628
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
Introduce discriminators into freestanding macro expansion expressions
and declarations. Compute these discriminators alongside closure and
local-declaration discriminators, checking them in the AST verifier.
pack expansion type reprs.
Classic variadic parameters still use the postfix ellipsis syntax, and
pack expansion types now use a prefix 'repeat' keyword.
Always parse macro expansions, regardless of language mode, and
eliminate the fallback path for very, very, very old object literals
like `#Color`. Instead, check for the feature flag for macro
declaration and at macro expansion time, since this is a semantic
restriction.
While here, refactor things so the vast majority of the macro-handling
logic still applies even if the Swift Swift parser is disabled. Only
attempts to expand the macro will fail. This allows us to enable the
macro-diagnostics test everywhere.
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 parser no longer sets local discriminators, and this function is
currently only responsible for adding local type declarations to the
source file. Rename it and remove most of the former callers so it
does just that.
Rather than set closure discriminators in both the parser (for explicit
closures) and then later as part of contextualizing closures (for
autoclosures), do so via a request that sets all of the discriminators
for a given context.
These were keywords prior to Swift 2, and have only been kept around as
keywords to provide a custom error message to rewrite to `#file` et
al. It's incorrect to keep them as keywords, and that error should be
implemented differently if we care about it.
These were replaced by `#file`, `#line`, etc. with SE-0028, prior to
Swift 3. We don't need this custom error message any more, and they
shouldn't be keywords. Stop treating them as keywords in the lexer.
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.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Introduce `MacroExpansionExpr` and `MacroExpansionDecl` and plumb it through. Parse them in roughly the same way we parse `ObjectLiteralExpr`.
The syntax is gated under `-enable-experimental-feature Macros`.
Fixes rdar://100872195 ( error: 'move' can only be applied to lvalues
error: Can not use feature when experimental move only is disabled!)
Identifiers with a single underscore are not reserved for use by the
language implementation. It is perfectly valid for a library to define
its own '_move'.
The contextual _move keyword should only be parse when it is followed by an lvalue, so should *not* conflict with user-defined '_move' functions.
https://github.com/apple/swift-evolution/blob/main/proposals/0366-move-function.md#source-compatibility
