Keeping a reference to the function here is dangerous. We only
actually care about the name, so save ourselves a copy of that
instead.
This fixes a crash that seems to happen only when the coverage data is
very large.
Swift SVN r25433
two logically independent but related patches conflated together:
- Improve error recovery for malformed if/let conditions, particularly
when the user uses "," instead of &&. Add testcases for error recovery
requested by Jordan.
- Add a syntactic requirement that the pattern of an if/let condition be
a simple identifier or _. We allow slightly broader patterns here now,
but they will change in the future when refutable patterns are allowed.
It is best to be narrow and then open it up later so we can do a great
job of QoI then.
This includes the changes to the stdlib directory that I forgot to commit
with the patch the previous time.
Swift SVN r25408
- Improve error recovery for malformed if/let conditions, particularly
when the user uses "," instead of &&. Add testcases for error recovery
requested by Jordan.
- Add a syntactic requirement that the pattern of an if/let condition be
a simple identifier or _. We allow slightly broader patterns here now,
but they will change in the future when refutable patterns are allowed.
It is best to be narrow and then open it up later so we can do a great
job of QoI then.
Swift SVN r25371
In r22669, we expanded our parsing of T?? by using operator splitting. This works
great when the ?? is lexed as a postfix operator, but does the wrong thing when the ??
is lexed as an infix and there is whitespace around it. For that, we don't want to
process it as a type. This was reported in a number of places including on stack
overflow:
http://stackoverflow.com/questions/28430496/nil-coalescing-to-provide-default-values-in-swift-1-2
Swift SVN r25228
The previous commit enabled this; now it's just about removing the
restriction in the parser and tightening up code completion.
Using 'super' in a closure where 'self' is captured weak or unowned still
doesn't work; the reference to 'self' within the closure is treated as
strong regardless of how it's declared. Fixing this requires a cascade of
effort, so instead I just cloned rdar://problem/19755221.
rdar://problem/14883824
Swift SVN r25065
Before if you had a differing number of arguments from types, you would
get the error:
Expected sil type to have the right argument types.
Now we say:
Expected sil type to have the same number of arg names as arg types.
which is slightly clearer.
Swift SVN r25049
This will have an effect on inlining into thunks.
Currently this flag is set for witness thunks and thunks from function signature optimization.
No change in code generation, yet.
Swift SVN r24998
Before we would produce (with no fixit):
a.swift:1:13: error: attribute can only be applied to declarations, not types
let step : @autoclosure() -> ()
^
now we produce (with a fixit):
a.swift:1:13: error: 'autoclosure' attribute is now an attribute of the parameter declaration, not its type
let step : @autoclosure() -> ()
~^~~~~~~~~~~
@autoclosure
This also generates the same handles other declattributes incorrectly applied to types.
Swift SVN r24946
- Closures that are comprised of only a single return statement are now considered to be "single expression" closures. (rdar://problem/17550847)
- Unannotated single expression closures with non-void return types can now be used in void contexts. (rdar://problem/17228969)
- Situations where a multi-statement closure's type could not be inferred because of the lack of a return-type annotation are now properly diagnosed. (rdar://problem/17212107)
I also encountered a number of crashers along the way, which should now be fixed.
Swift SVN r24817
Brace statement created for wrapping IfConfig inside TopLevelCodeDecl does not have
closing brace, so we should use the previous token’s location as right brace location.
Swift SVN r24797
Since ParserResult<T> required to have an AST node if there is no error and Parser::parseLineDirective()
does not return any node after successful parsing, we should not try to construct DeclResult.
Swift SVN r24755
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
a vararg subpattern of a TuplePattern should be a TypedPattern
Check for a vararg subpattern to be a typed pattern seemed to be missing in closure arguments parsing.
Swift SVN r24733
Attributes @__objc_bridged, @__raw_doc_comment and @__accessibility are not supposed to be
coming from input file and actually crash parseNewDeclAttribute(…) when they are.
Swift SVN r24697
Previously, adding observing accessors to a variable caused it to require
an explicit type /and/ an initializer. Now you just need one or the other;
the type of the accessors is drawn from the type of the VarDecl, whether
inferred or explicitly written.
rdar://problem/18148072
Swift SVN r24664
Allows same-type constraints that map down to tuple types. This is a
minimal fix that allows the code in rdar://problem/18120419 to
type-check. However, the actual code in that radar triggers a SILGen
assertion (Archetype to be substituted must be valid in function), and
we're not recursively matching concrete types the way we should be, so
this is a baby step.
Among other things, this allows one to provide a same-type con
Swift SVN r24535
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
1. Eliminate unused variable warnings.
2. Change field names to match capitalization of the rest of the field names in the file.
3. Change method names to match rest of the file.
4. Change get,set method for a field to match the field type.
Swift SVN r24501
Changing the design of this to maintain more local context
information and changing the lookup API.
This reverts commit 4f2ff1819064dc61c20e31c7c308ae6b3e6615d0.
Swift SVN r24432
rdar://problem/18295292
Locally scoped type declarations were previously not serialized into the
module, which meant that the debugger couldn't reason about the
structure of instances of those types.
Introduce a new mangling for local types:
[file basename MD5][counter][identifier]
This allows the demangle node's data to be used directly for lookup
without having to backtrack in the debugger.
Local decls are now serialized into a LOCAL_TYPE_DECLS table in the
module, which acts as the backing hash table for looking up
[file basename MD5][counter][identifier] -> DeclID mappings.
New tests:
* swift-ide-test mode for testing the demangle/lookup/mangle lifecycle
of a module that contains local decls
* mangling
* module merging with local decls
Swift SVN r24426
a non-native owner. This is required by Slice, which
will use an ObjC immutable array object as the owner
as long as all the elements are contiguous.
As part of this, I decided it was best to encode the
native requirement in the accessor names. This makes
some of these accessors really long; we can revisit this
if we productize this feature.
Note that pinning addressors still require a native
owner, since pinning as a feature is specific to swift
refcounting.
Swift SVN r24420
Change all the existing addressors to the unsafe variant.
Update the addressor mangling to include the variant.
The addressor and mutable-addressor may be any of the
variants, independent of the choice for the other.
SILGen and code synthesis for the new variants is still
untested.
Swift SVN r24387
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
if-let statements (also while and var, of course) that include multiple bindings
and where clauses.
SILGen support still remains, it currently just asserts on the new constructs.
Swift SVN r24239
wrapping up rdar://16323038. Pieces still remaining are a Clang attribute+
importer support for it, plus adoption in the stdlib (tracked by other radars).
Swift SVN r24223
