First, fix a case of type checking an expression twice, which is against
the design of the type checker. We hit this because we can type check
the "context" in
let x = foo.#^COMPLETE^#
and then type check the "parsed expression", which is contained in the
context here.
Second, make the hack from rdar://20738314 more robust so that if we
*do* double typecheck for some reason we won't just choke on an
AutoClosureExpr. I filed rdar://21466394 to audit for other cases of
double typechecking and remove this hack.
Fixes rdar://21346928
Swift SVN r29527
Doc comments assume a prefix of /** and a suffix of */
but if a user accidentally types /**/, SourceKit can crash and
bring down Xcode with certain timings. Check both ends of doc
comments before dropping characters.
rdar://problem/21105409
Swift SVN r29035
This returns to the behaviour we had before ModuleDecl came about. It
fixes an assertion in SourceKit concerning the kinds of decls we will
visit in visitDeclReference. As the comments indicate, we need this
special case until Swift supports first class submodules.
Swift SVN r28934
- Start highlighting doc comments as Xcode "Documentation Comments".
- Start highlighting custom top-level fields as Xcode "Documentation
Comment Keywords".
This requires SourceKit r28827 to build and Xcode
rdar://problem/21034381 for proper highlighting.
Swift SVN r28828
Completions for calling functions will now show 'throws' in the
description text so that users can differentiate throwing and
non-throwing calls. We don't insert this into the source text, since
it's not part of the call syntax.
rdar://problem/20978869
Swift SVN r28791
declarations generated by the type-checker.
Unfortunately, it's not possible to directly check this
because the verifier is itself based on ASTWalker. But I'm
going to add an assertion to SILGen in a follow-up that
assumes that TypeCheckError has visited every ApplyExpr,
and since SILGen already walks most of the AST with its
own custom walker, that will check this well enough.
Swift SVN r28732
It's not okay to filter to only ErrorType results, since we may be
trying to chain to an error type result foo.bar.getError(). And the
existing logic had no way to handle results from other modules, so we
were missing key results like 'NSError'.
Eventually we'll want to bring back something like this that handles all
modules, but as a way to bump the priority of ErrorType results rather
than to filter out everything else.
rdar://problem/20985515
Swift SVN r28716
protocol P { typealias T; func foo() -> T }
func invalid(x: P) { x.#^COMPLETE^#
We were trying to access a null Type created because the associated type
doesn't make sense in the protocol type P (we can only use P as a
generic constraint, but it shouldn't crash code completion if we use it
incorrectly).
For rdar://problem/20305938
Swift SVN r28588
We were asserting (and doing the wrong thing) when trying to code
complete
nil #^HERE^#
The issue is that we tried to apply a solution to the expression that
contained free type variables (converted to generic parameters). This
trips us up when we expect the new type to conform to protocols. In code
completion we generally only need the type of the expression, so this
commit switches to getting that more explicitly. That said, this did
cause us to drop non-API parameter names in call patterns after an
opening '(' in some cases (covered by rdar://20962472).
Thanks to Doug for suggesting this solution!
rdar://problem/20891867
Swift SVN r28584
instead of being an expression.
To the user, this has a couple of behavior changes, stemming from its non-expression-likeness.
- #available cannot be parenthesized anymore
- #available is in its own clause, not used in a 'where' clause of if/let.
Also, the implementation in the compiler is simpler and fits the model better. This
fixes:
<rdar://problem/20904820> Following a "let" condition with #available is incorrectly rejected
Swift SVN r28521
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
Now that we don't have generic parameter lists at arbitrary positions
within the extended type of an extension declaration, simplify the
representation of the extended type down to a TypeLoc along with a
(compiler-synthesized) generic parameter list.
On the parsing side, just parse a type for the extended type, rather
than having a special grammar. We still reject anything that is not a
nominal type (of course), but it's simpler just to call it a type.
As a drive-by, fix the crasher when extending a type with module
qualification, rdar://problem/20900870.
Swift SVN r28469
When we miss the in-memory (libcache-based) code completion cache, we
can now chain to an on-disk code completion cache. This drastically
improves the time and peak memory usage it takes to do the first code
completion (ie. before the in-memory cache is warm) if we've done the
same lookup before.
The on-disk cache, like the in-memory cache is tied to the specific
compiled swift and clang module files (.swiftmodule and .pcm), and will
consider itself out of date if they are modified. Responsibility for
deleting completely dead/unreachable cache files falls to the client.
Most of this commit is adding a simple serialization and deserialization
for CodeCompletionResults and CodeCompletionStrings. The format is very
simple, using an array of fixed size CodeCompletionResults, with offsets
into two blobs: one for CodeCompletionString::Chunks, and one for
strings. Currently that gives us about 5.8 MB for all the results in
Cocoa, but it's very compressible if we decide we want to reduce it
(gzip'd it is ~1.2 MB for the same data).
Swift SVN r28369
This will let us implement caching in the client (e.g. SourceKit) at
some point and simplifies adding more levels of caching. Requires a
corresponding SourceKit change.
Swift SVN r28365
Instead of importing everything and filtering later (so all of clang modules get deserialized and associated Swift decls get created),
lazily import as Swift decls only the Clang decls that we need from a particular header.
This also fixes printing ObjC categories in the header as Swift extensions.
Swift SVN r28358
Make unqualified lookup always provide a declaration for the things it
finds, rather than providing either a module or a declaration. Unify
various code paths in our type checker now that module declarations
come in with the other declarations.
Swift SVN r28286
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Now get() and set() manage determining whether the results are stale,
and getResults() can just rely on that.
Also drive-by fix a data race where we were inserting our results sink
into the cache before it was finished being modified.
Swift SVN r28175
This translates clang arguments to swift ones, uses the bridging header
functionality to parse the provided file, and re-uses part of the module interface
printing implementation to print an interface for the header.
Part of rdar://19939192
Swift SVN r28062
Printing Doxygen isn't inside an XML tag, so we can't just print
code block content, which may have new lines without a doc comment
marker. Also, be more robust with indentation.
+ Tests.
rdar://problem/20703026
Swift SVN r27851
We want to be able to synthesize new results inside SourceKit. At this
point, the simplest way to do that is to expose the constructors for
CodeCompletionResult and a create() function for CodeCompletionString.
The expectation that any strings are stored properly inside a
CodeCompletionResultSink is documented.
Swift SVN r27822
- Pass EnableObjCAttrRequiresFoundation to CompilerInvocation in
swift-ide-test when printing comments.
- Use separate streams for printing HTML <h> tags
Swift SVN r27771
Replace ReST-flavored documentation comments with Markdown.
rdar://problem/20180412
In addition to full Markdown support, the following extensions are
supported. These appear as lists at the top level of the comment's
"document". All of these extensions are matched without regard to
case.
Parameter Outlines
------------------
- Parameters:
- x: ...
- y: ...
Separate Parameters
-------------------
- parameter x: ...
- parameter y: ...
- Note:
Parameter documentation may be broken up across the entire comment,
with a mix of parameter documentation kinds - they'll be consolidated
in the end.
Returns
-------
- returns: ...
The following extensions are also list items at the top level, which
will also appear in Xcode QuickHelp as first-class citizens:
- Attention: ...
- Author: ...
- Authors: ...
- Bug: ...
- Complexity: ...
- Copyright: ...
- Date: ...
- Experiment: ...
- Important: ...
- Invariant: ...
- Note: ...
- Postcondition: ...
- Precondition: ...
- Remark: ...
- Remarks: ...
- See: ...
- Since: ...
- Todo: ...
- Version: ...
- Warning: ...
These match most of the extra fields in Doxygen, plus a few more per request.
Other changes
-------------
- Remove use of rawHTML for all markup AST nodes except for those
not representable by the Xcode QuickHelp XSLT - <h>, <hr/>, and of
course inline/block HTML itself.
- Update the doc comment RNG schema to more accurately reflect Xcode
QuickHelp.
- Clean up cmark CMake configuration.
- Rename "FullComment" to "DocComment"
- Update the Swift Standard Documentation (in a follow-up commit)
- Update SourceKit for minor changes and link against cmark
(in a follow-up commit).
Swift SVN r27727
Change all uses of "do { ... } while <cond>" to use "repeat" instead.
Rename DoWhileStmt to RepeatWhileStmt. Add diagnostic suggesting change
of 'do' to 'repeat' if a condition is found afterwards.
<rdar://problem/20336424> rename do/while loops to repeat/while & introduce "repeat <count> {}" loops
Swift SVN r27650
Inference of type witnesses for associated types was previously
implemented as part of value witness matching in the constraint
solver. This led to a number of serious problems, including:
- Recursion problems with the solver hunting for a type witness,
which triggers more attemts to match value witnesses...
- Arbitrarily crummy attempts to break the recursion causing
type-check failures in fun places.
- Ordering dependencies abound: different results depending on which
value witnesses were satisfied first, failures because of the order
in which we attempted to infer type witnesses, etc.
This new implementation of type witness inference uses a separate pass
that occurs whenever we're looking for any type witness, and solves
all of the type witnesses within a given conformance
simultaneously. We still look at potential value witnesses to infer
type witnesses, but we match them structurally, without invoking the
constraint solver.
There are a few caveats to this implementation:
* We're not currently able to infer type witnesses from value
witnesses that are global operators, so some tricks involving global
operators (*cough* ~> *cough*) might require some manually-specified
type witnesses. Note that the standard library doesn't include any
such cases.
* Yes, it's another kind of solver. At simple one, fortunately.
On the other hand, this implementation should be a big step forward:
* It's far more predictable, order-invariant, and non-recursive.
* The diagnostics for failures to infer type witnesses have
improved.
Fixes rdar://problem/20598513.
Swift SVN r27616
