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
Add primitive type-checker rules for pointer arguments. An UnsafePointer argument accepts:
- an UnsafePointer value of matching element type, or of any type if the argument is UnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is UnsafePointer<Void>, or
- an inout Array parameter of matching element type, or of any type if the argument is UnsafePointer<Void>.
A ConstUnsafePointer argument accepts:
- an UnsafePointer, ConstUnsafePointer, or AutoreleasingUnsafePointer value of matching element type, or of any type if the argument is ConstUnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>, or
- an inout or non-inout Array parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>.
An AutoreleasingUnsafePointer argument accepts:
- an AutoreleasingUnsafePointer value of matching element type, or
- an inout parameter of matching element type.
This disrupts some error messages in unrelated tests, which is tracked by <rdar://problem/17380520>.
Swift SVN r19008
Allow class metatypes (including class-constrained existential metatypes) to be treated as subtypes of AnyObject, and single-@objc protocol metatypes to be treated as subtypes of the Protocol class from objc. No codegen support yet, so this is hidden behind a frontend flag for now.
Swift SVN r18810
I didn't want to rip this logic out wholesale. There is a possibility
the character lexing can be reborn/revisited later, and
disabling it in the parser was easy.
Swift SVN r18102
No options should be changed because of the absence of a flag. This is
necessary for clients like LLDB which may have an initial set of options
that differs from the usual set.
Part of <rdar://problem/16776705>
Swift SVN r17819
When importing an Objective-C init method or factory method into an
initializer, if the first camelCase word of the first argument name
starts with "with", drop the "with". This means that
-initWithRed:green:blue:alpha:
will get imported into Swift as
init(red:green:blue:alpha:)
as will
+colorWithRed:green:blue:alpha:
This is <rdar://problem/16795899>, hidden behind the
-implicit-objc-with flag.
Swift SVN r17271
