Similarly to how we've always handled parameter types, we
now recursively expand tuples in result types and separately
determine a result convention for each result.
The most important code-generation change here is that
indirect results are now returned separately from each
other and from any direct results. It is generally far
better, when receiving an indirect result, to receive it
as an independent result; the caller is much more likely
to be able to directly receive the result in the address
they want to initialize, rather than having to receive it
in temporary memory and then copy parts of it into the
target.
The most important conceptual change here that clients and
producers of SIL must be aware of is the new distinction
between a SILFunctionType's *parameters* and its *argument
list*. The former is just the formal parameters, derived
purely from the parameter types of the original function;
indirect results are no longer in this list. The latter
includes the indirect result arguments; as always, all
the indirect results strictly precede the parameters.
Apply instructions and entry block arguments follow the
argument list, not the parameter list.
A relatively minor change is that there can now be multiple
direct results, each with its own result convention.
This is a minor change because I've chosen to leave
return instructions as taking a single operand and
apply instructions as producing a single result; when
the type describes multiple results, they are implicitly
bound up in a tuple. It might make sense to split these
up and allow e.g. return instructions to take a list
of operands; however, it's not clear what to do on the
caller side, and this would be a major change that can
be separated out from this already over-large patch.
Unsurprisingly, the most invasive changes here are in
SILGen; this requires substantial reworking of both call
emission and reabstraction. It also proved important
to switch several SILGen operations over to work with
RValue instead of ManagedValue, since otherwise they
would be forced to spuriously "implode" buffers.
* Switch to calling `putchar_unlocked()` instead of `putchar()` for
actual printing. We're already locking stdout with `flockfile()`, so
there's no need for the redundant lock that `putchar()` uses.
* Add an explicit lock to the output stream in `dump()`. This means the
entire dump is printed with the lock held, which will prevent the
output of `dump()` from mixing with prints on other threads.
* Use `_debugPrint_unlocked()` instead of `debugPrint()` in
`_adHocPrint()`. The output stream is already locked while this
function is executing. Rename the function to `_adHocPrint_unlocked()`
to make this explicit.
* Use `targetStream.write()` and `_print_unlocked()` instead of
`print()` in `_dumpObject()`. This removes the redundant locking, and
also eliminates the creation of intermediate strings. Rename the
function to `_dumpObject_unlocked()` to make this explicit.
* Use `targetStream.write()`, `_print_unlocked()`, and
`_debugPrint_unlocked()` in `_dumpSuperclass()`. This removes the
redundant locking, and also eliminates the creation of intermediate
strings. Rename the function to `_dumpSuperclass_unlocked()` to make
this explicit.
* Use `_debugPrint_unlocked()` instead of `debugPrint()` in
`String.init(reflecting:)`. This shouldn't really make much of a
difference but it matches the usage of `_print_unlocked()` in
`String.init(_:)`.
The net result is that all printing is still covered under locks like
before, but stdout is never recursively locked. This should result in
slightly faster printing. In addition, `dump()` is now covered under a
single lock so it can't mix its output with prints from other threads.
This pull request broke the following tests on several build configurations
(eg --preset=buildbot,tools=RA,stdlib=DA)
1_stdlib/Reflection.swift
1_stdlib/ReflectionHashing.swift
1_stdlib/UnsafePointer.swift.gyb
This reverts commit c223a3bf06, reversing
changes made to 5c2bb09b09.
Changes:
- Reverted commit reverting original SR-88 commit
- Removed mirror children helper collections and related code
- Rewrote some tests to keep them working properly
- Wrote two more tests for the three pointer APIs to ensure no crashes if created using a value > Int64.max
This reverts commit 8917eb0e5a.
Jira: SR-88
Changes:
- Removed stdlib type conformances to _Reflectable
- Conformed stdlib types to CustomReflectable, CustomPlaygroundQuickLookable
- Rewrote dump() function to not use _reflect()
- CGRect, CGPoint, CGSize now conform to CustomDebugStringConvertible
- Rewrote unit tests for compatibility with new API
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.
We don't really need its peculiar behavior characteristics; its uses in the legacy mirror implementations can now be replaced by direct stringification of metatypes.
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976
Previously a mirror for an empty case would have one entry, consisting
of the case name and a value of ().
Now, the mirror's summary shows both the type and the case. If there is
no payload, the mirror will not have any children. The presence of a
child indicates there is an actual payload.
Also put a non-ASCII character in the reflection test to ensure the
runtime's primitives can round-trip UTF8.
Fixes <rdar://problem/20994093>.
Swift SVN r28874
This change attempts to introduce the functionality without being too
disruptive. After we branch, I want to consolidate some of the runtime
functions and implement this functionality for multi-payload enums
as well, which requires adding new runtime metadata.
Example:
(swift) enum Color { case Red, Green, Blue(Int) }
(swift) print(Color.Red)
REPL.Color.Red
(swift) print(Color.Blue(5))
REPL.Color.Blue(5)
Implements <rdar://problem/18334936>.
Swift SVN r28430
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
