In particular, this is problematic when libraries are loaded dynamically, and
may have newer deployment targets than the main executable.
Swift SVN r26786
...which allows "@testable import" to work with modules not compiled for
testing. This isn't generally safe, but should be fine for clients like
SourceKit which just need to have the API available and might not be able
to properly rebuild the original target for testing.
We may revisit this in the future.
Swift SVN r26629
This flag enables checking of availability (deprecation, explicit unavailability,
and potential unavailability) in synthesized functions. The flag will go away once this
checking is fully staged in.
Swift SVN r26624
This warning is temporarily going being a flag so that, once it is safe to place generic parameters on extensions of generic types, we can opt-in to update our code when it is convenient.
Swift SVN r26416
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
This is at the expense of blockquotes, which we don't actually need at
the moment. All blockquotes get interpreted as preformatted code.
Swift SVN r25459
Since a function pointer doesn't carry any context, we can only form a C function pointer from a static reference to a global function or a context-free local function or closure. (Or maybe a static function applied to its metatype, but that's not handled here yet.) As a placeholder for a to-be-bikeshedded surface syntax, let the existing @cc(cdecl) attribute appear in source text when the -enable-c-function-pointers frontend flag is passed.
Swift SVN r25308
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
Whenever we add a requirement, we now know
(1) Why we added the requirement, e.g., whether it was explicitly written, inferred from a signature, or introduced by an outer scope.
(2) Where in the source code that requirement originated.
Also add a debugging flag for dumping the archetype builder information, so we can write tests against it.
This is effectively NFC, but it's infrastructure to help a number of requirements-related tasks.
Swift SVN r22638
This patch adds the ability (-enable-experimental-unavailable-as-optional) to
treat potentially unavailable declarations as if they had optional types. For
the moment, this is only implemented for global variables.
The high-level approach is to (1) record the potential unavailability of a
declaration reference in the overload choice during constraint generation; (2)
treat the declaration as if it had an optional type during overload resolution
(this is similar to how optional protocol members are treated); and (3) add an
implicit conversion (UnavailableToOptionalExpr) during constraint application
to represent the run-time availability check and optional injection.
This patch does not implement SILGen for UnavailableToOptionalExpr.
Swift SVN r22245
for testing purposes.
When enabled, if the typechecker tries to typecheck a decl or unresolved identifier with the provided
prefix, then an llvm fatal_error will get triggered.
This approach has the advantage that it is very easy to write tests for unnecessary typechecking for a wide range of functionality,
for the compiler or SourceKit, for code-completion, indexing, etc.
Swift SVN r22003
...thus supporting "private var x: Int" in two different source files in the
same module.
This marks the completion of the bulk of the work for rdar://problem/17632175.
Remaining work is to make sure debugging does the right thing when processing
expressions in a particular source context.
Swift SVN r21851
Also, use 'Playground' to control the behavior of ignored expressions
(which are not an error because they are displayed in the playground log).
This is preparation for LLDB no longer passing 'DebuggerSupport' for a
playground <rdar://problem/18090611>. 'DebuggerSupport' now only applies
to REPL-like contexts and enables identifiers beginning with $, special
rules for parsing top-level code, ignored expressions (like playgrounds),
and the @LLDBDebuggerSupport attribute.
Besides ignored expressions, 'Playground' enables the playground transformation
and provides an entry point for debugger initialization.
Note that this is a bit insincere---many of the options controlled by both
'Playground' and 'DebuggerSupport' really only apply to the main source file
or main module. If/when we add back support for source file imports, we'll
need to revisit all of LangOptions and see which of them should /really/
apply to /everything/ in the ASTContext.
Swift SVN r21384
This is enabled by default because SILGen can crash when @objc is used without importing Foundation, but
it gets disabled when compiling the Swift stdlib.
Addresses rdar://17931250.
Related test case on the SourceKit side.
Swift SVN r21319
While we work out the remaining performance improvements in the type checker, we can improve the user experience for some "runaway solver" bugs by setting a limit on the amount of temporary memory allocated for type variables when solving over a single expression.
Exponential behavior usually manifests itself while recursively attempting bindings over opened type variables in an expression. Each one of these bindings may result in one or more fresh type variables being created. On average, memory consumption by type variables is fairly light, but in some exponential cases it can quickly grow to many hundreds of megabytes or even gigabytes. (This memory is managed by a distinct arena in the AST context, so it's easy to track.) This problem is the source of many of the "freezing" compiler and SourceKit bugs we've been seeing.
These changes set a limit on the amount of memory that can be allocated for type variables while solving for a single expression. If the memory threshold is exceeded, we can surface a type error and suggest that the user decompose the expression into distinct, less-complex sub-expressions.
I've set the current threshold to 15MB which, experimentally, avoids false positives but doesn't let things carry on so long that the user feels compelled to kill the process before they can see an error message. (As a point of comparison, the largest allocation of type variable data while solving for a single expression in the standard library is 592,472 bytes.) I've also added a new hidden front-end flag, "solver-memory-threshold", that will allow users to set their own limit, in bytes.
Swift SVN r20986
Without this, clients that don't use a CompilerInstance (like LLDB) won't
have target configuration options available.
Also, move minimum OS checking into the driver. This makes sure the check
happens early (and only once), and in general fits the philosophy of
allowing the frontend to use configurations that might be banned for users.
<rdar://problem/17688913>
Swift SVN r20701
When -enable-optional-lvalues is active, type-check '?' operations like '!' operations, using an OptionalObject constraint to match the optional subexpression type to the non-optional result type of equivalent lvalue-ness.
Swift SVN r20610
This causes a regression in error reporting where there are potential fixes: <rdar://problem/17741575> Other than that, everything works.
Swift SVN r20230
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
There is some follow-up work remaining:
- test/stdlib/UnicodeTrie test kills the type checker without manual type annotations. <rdar://problem/17539704>
- test/Sema/availability test raises a type error on 'a: String == nil', which we want, but probably not as a side effect of string-to-pointer conversions. I'll fix this next.
Swift SVN r19477
Allow a String value to be implicitly converted to ConstUnsafePointer<{UInt8,Int8,Void}> by string-to-pointer conversion, when enabled by a staging flag.
Swift SVN r19366
This applies to both qualified and unqualified lookups, and is controlled
by the -enable-access-control and -disable-access-control flags. I've
included both so that -disable-access-control can be put into specific tests
that will eventually need to bypass access control (e.g. stdlib unit tests).
The default is still -disable-access-control.
Swift SVN r19146
