As soon as you had one &&/|| in your chain of expressions we would lose
infix completions for Bool because we got confused by the autoclosure,
so strip it off.
rdar://32016622
Constructor call patterns already get a real priority, but because of
the way we do function call patterns we don't have enough information,
and previously we were setting it to "expression specific", which is
unnecessarily high, particularly since functions (unlike inits) have
other better ways to code-complete already.
rdar://31113161
When completing
Foo(<here>
We will now provide
bar: <#value#>
instead of
bar: <#value#>)
Inserting the rparen caused some problems in practice:
* the old behaviour optimized for typing Foo(<complete> instead of
Foo(<complete>), which can conflict with user behaviours or ...
* in editors with automatic brace-matching, we often conflicted with the
editor, leading to extraneous closing parens
And in general, it is much more predictable for tooling to either insert
matching ( and ) or to not insert either. While this change may not be
ideal For users of editors that do not do automatic brace-matching, I
believe it is still better overall to have to type a missing paren than
to have to delete an extraneous one.
rdar://31113161
The original hope was we could make these heuristics really good, but
since that is not currently in sight (and may never be), we want to be
able to turn them off. For now, just plumb through an internal flag to
control the behaviour. A future change will customize the behaviour in
SourceKit.
rdar://31113161
Code-completion of generic types expects to get a DeclContext for the
subscript, so make sure we recover well enough to produce a
SubscriptDecl.
rdar://35619175
'implicit' implies it was not written by the user. This was preventing printing '@available'
for interfaces of Swift code (e.g. from overlays).
rdar://35778715
Array, Set, Dictionary, and Optional all provide unconditional conformances
to Encodable & Decodable that dynamically check whether their type arguments
are Encodable/Decodable. Now that we have conditional conformances, make
these unconditional conformances properly conditional, removing all of
the Swift 4-era type-erasure hacks.
Fixes rdar://problem/34989162.
* [SR-4005] Allow heterogenous comparisons in elementsEqual
When a user is supplying a predicate to compare the type equivalence
isn’t required
* elementsEqualWithPredicate tests
Compares a string of a number with an integer value by using the
elementsEqualPredicate closure
* Update test expectations to use new sequence element types
* Update hardcoded test to reference sequence
Attach this attribute to VarDecls declared as IUO, and to function decls
that have a result type that is an IUO.
NFC at the moment. Eventually we'll use these to determine where to
implicitly unwrap optional values.
Partially reverts f4f8349 (from July!) which caused us to start
importing global blocks with unbridged parameters, breaking source
compatibility. I'm still investigating whether there's an actual hole
in the logic; see next few commits.
rdar://problem/34913634
Use the modern spelling for the nullability attributes in the test mock
headers. Currently, this was relying on the predefined macros from
clang to work. However, those are only available on Darwin targets.
This is needed to make the mock environments more portable.
Associated type redeclarations occasionally occur to push around
associated type witness inference. Suppress the warning about redeclarations
that add no requirements (i.e., have neither an inheritance nor a
where clause).
This is not really the right fix if we want to have physically
addressed lvalues support bridging in general, but doing so
requires adding a new LValue component type and doing a bunch
more refactoring, so just hack in a narrow fix for now since
it only seems to occur in one case.
Fixes <rdar://problem/34913892>.
... and UnicodeScalar, which is technically more correct than only
showing it for String. This also happens to workaround a bug where we
won't show "" for string.contains.
rdar://problem/34746368
As we do with "where" clauses, print the "inheritance" clauses of
protocols and associated type declarations using the requirement
signature of the protocol rather than the "inherited" list.
Right now the ClangImporter relies on Sema to synthesize typealiases
in some cases, which doesn't work if a Sema instance is not available,
for example when the ClangImporter is asked to import a declaration
while deserializing SIL during optimization.
Begin addressing this by synthesizing typealiases for the following
conformances:
- ExpressibleByArrayLiteral.ArrayLiteralElement while importing
OptionSets.
- RawRepresentable.RawValue while importing raw-valued enums.
- ObjectiveCBridgeable._ObjectiveCType while importing bridged
newtypes.
Until further changes land, this is mostly NFC, except for a change
in generated interface printing where the new typealiases are now
explicitly shown.
Note that non-bridged newtypes whose raw type is ObjectiveCBridgeable
still rely on associated type inference, because the ClangImporter
cannot safely "copy" the _ObjectiveCType typealias from the raw type
to the newtype, for various reasons mostly having to do with
circularity. Subsequent patches will address this, in a rather novel
fashion that will shock you.
Seen as @available attributes being printed with "_" in interface
generation, but fixing it in the importer means they can't leak into
anywhere else.
rdar://problem/30451293
This implementation required a compromise between parser
performance and AST structuring. On the one hand, Parse
must be fast in order to keep things in the IDE zippy, on
the other we must hit the disk to properly resolve 'canImport'
conditions and inject members of the active clause into the AST.
Additionally, a Parse-only pass may not provide platform-specific
information to the compiler invocation and so may mistakenly
activate or de-activate branches in the if-configuration decl.
The compromise is to perform condition evaluation only when
continuing on to semantic analysis. This keeps the parser quick
and avoids the unpacking that parse does for active conditions
while still retaining the ability to see through to an active
condition when we know we're moving on to semantic analysis anyways.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
This fixes various issues with getting no code-completion in top-level
code containing array/dictionary sugar, such as:
```
for x in [<HERE>] {}
for x in [1: 2, <HERE>] {}
```
And also removes the index variable from completions inside the sequence
(it was coming through as a local variable with <<error type>>).
rdar://problem/33884082
