Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
This doesn't have a specific effect now, because all of these places
are likely to only see NameAliasType, but it is refactoring with the
intent of eliminating NameAliasType entirely.
* Implement #warning and #error
* Fix #warning/#error in switch statements
* Fix AST printing for #warning/#error
* Add to test case
* Add extra handling to ParseDeclPoundDiagnostic
* fix dumping
* Consume the right paren even in the failure case
* Diagnose extra tokens on the same line after a diagnostic directive
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
Update the code that prints types for constructor results to take
into account IUO types being removed from the type system.
NFC on master. Results in better fidelity with what we have today when
IUOs are removed from the type system in a future commit.
[ClangImporter] Make sure that headers from the bridging header are considered 'isBeforeInTranslationUnit' compared to headers imported from swift code
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
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
Except GenericEnvironment.h, because you can't meaningfully use a
GenericEnvironment without its signature. Lots less depends on
GenericSignature.h now. NFC
... 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
In one place we were calling hasError() and in another directly checking
for ErrorType; if we had a type containing an ErrorType as a structural
component, we would hit an assertion.
We have a hack where we use the ParsedDecl as the DeclContext,
to handle completion during function signature parsing, which
happens before the FuncDecl has been created.
While fixing this properly would require a bigger change to the
parser and AST, for now we just check if the ParsedDecl is a
child context of CurDeclContext, and only use it then.
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
"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.)
"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.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
When completing in an if/while/guard statement condition that expects a
boolean, add the code-completion type relation for Bool. We already had
this for repeat-while.
rdar://problem/26509084
Complete generic parameters and their members inside generic where
clauses on structs, classes, enums, extensions, typealiases, funcs,
subscripts and inits.
Still not handled correctly are associatedtypes.
rdar://problem/20582394
For normal completions it behaves the same as PostfixExprBeginning, but
it provides a hook for clients to provide a custom completion for this
position. For example, you might want to a x ..< y snippet in this
position.
rdar://problem/29910383
When using completion options that will allow the lone "." completion,
provide that result when in contexts that expect an enum type. Note:
this is a crappy approximationg for whether the type can have "implicit
member expression" syntax, since uninhabited enums should not support
it, and many non-enum types should. However, it is currently expensive
to compute the accurate answer and this approximation is good enough for
some clients.
rdar://problem/31260505
AnyFunctionType::Param carries around information about decomposed
parameters now. Information about default arguments must be computed
separately with swift::computeDefaultMap.
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
