When printing an associated type that is not provided (e.g. during
code-completion of overrides), we want to print the type even if there
are errors.
rdar://problem/30451236
Previously, we ignoring 'let', so you would get ridiculous completions:
let var foo: Int
override let func bar() {}
Now, will complete protocol requirements after 'let' the same way we do
for 'var'. For instance property overrides, we only show them if the
'override' keyword is specified. You can't actually override using a
'let', but if the keyword is present then the intention is clear and we
can let the user fix it afterwards when the compiler diagnoses it.
rdar://problem/31091172
Switch printing off of using Function's ExtInfo for autoclosure and
escaping, and onto the ParameterTypeFlags, which let us do precise and
accurate context-sensitive printing of these parameter type
attributes. This fixes a huge list of issues where we were printing
@escaping for things like optional ObjC completion handlers, among
many others. We now correctly print @escaping in more places, and
don't print it when it's not correct.
Also updates the dumper to be consistent and give a good view of the
AST as represented in memory. Tests updated, more involved testing
coming soon.
* If "required" or "convenience" is specified, emit only initializers
* If "final" or "open" is specified, don't emit initializers or typealias
* If "typealias" is specified, emit only associated type implementation
* Emit "override" or "required" modifier for initializers
* Emit access modifier for initializers
* Emit designated initializers even if "override" is specified
* Don't emit inheritance clause for associated type implentation
Flush out the ASTPrinter's ability to exclude and include specific
attributes to cover TypeAttrKinds and have code-completion use this to
print @escaping in override completions. Incidentally fix a case where
we weren't forwarding important options after type transformation, which
prevented printing @escaping in transformed parameter types.
rdar://problem/27772722
This flips the switch to have @noescape be the default semantics for
function types in argument positions, for everything except property
setters. Property setters are naturally escaping, so they keep their
escaping-by-default behavior.
Adds contentual printing, and updates the test cases.
There is some further (non-source-breaking) work to be done for
SE-0103:
- We need the withoutActuallyEscaping function
- Improve diagnostics and QoI to at least @noescape's standards
- Deprecate / drop @noescape, right now we allow it
- Update internal code completion printing to be contextual
- Add more tests to explore tricky corner cases
- Small regressions in fixits in attr/attr_availability.swift
If a declaration is marked deprecated (but not unavailable) we want to
mark it as "not recommended" so that users know this probably isn't what
you want. We already do something like this in Clang code completions of
deprecated ObjC declarations.
rdar://problem/26335424
Semantic analysis may match up a witness to a requirement with
renaming; when performing code completion, we still want to see the
requirement because it's possible that the user just hasn't written it
yet. Fixes the regression I caused earlier today.
We don't actually want to skip non-type contexts here, since we should
only be showing override completions in the type context itself. This
was pretty obscure to hit in practice, but I noticed it while fixing the
crasher.
This allows us to get override completions correct when
* There are multiple decls on one line
* The preceding attributes/keywords span multiple lines
Resolving a longstanding FIXME.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
This mostly works the same as for functions. It required a slight tweak
to how we handle 'var <complete>' to avoid consuming the code completion
token prematurely.
rdar://problem/21012767
Swift SVN r32844
When a developer auto-completes an override function,
we collect the keywords that have already been specified
by the developer, so that the code completion strings do
not duplicate them.
rdar://16738036
Swift SVN r26230
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787