As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
Initialising with a base64 encoded string was using Base64EncodingOptions rather than Base64DecodingOptions - this means strings with unknown characters cannot be decoded properly as the .ignoreUnknownCharacters option is unavailable
Due to a modeling error in the type checker's folding of type
references into type expressions, code such as "strideof(Int)" would
be accepted without the required ".self". Commit
4a60b6cbf4 fixes the modeling issue but
left the historical accepts-invalid; now, diagnose these cases with a
warning + Fix-It to ease the transition.
Fixes SR-899.
Previously, the only version of the functions that accepted values was the one that implicitly wraps them into Optionals. This generated a confusing error message when the assert failed. Having a separate overload that accepts non-optional types ensures that the correct description is printed when the assert fails.
semantically unambiguous.
We didn't actually intend to change how programmers normally
constructed these types, but the change to the object literal
syntax accidentally caused these initializers to have very
natural-seeming signatures. These initializers also created
possible ambiguities with the actual initializers. Renaming
them to refer to their function as literal initializers is the
right thing to do.
Unfortunately, this provided to be somewhat annoying, as the
code was written to assume that the argument tuple following
e.g. #colorLiteral could be directly passed to the initializer.
We solve this by hacking on both ends of the constraint system:
during generation we form a conversion constraint to the
original, idealized parameter type, and during application we
rewrite the argument tuple type to use the actual labels.
This nicely limits the additional complexity to just the
parts dealing with object literals.
Note that we can't just implicitly rewrite the tuple expression
because that would break invariants tying the labels to physical
source ranges. We also don't want to just change the literal
syntax again and break compatibility with existing uses.
rdar://26148507
Implements almost all of SE-0067. There are a few outstanding features; this implementation does not have:
- formRemainder(dividingBy:)
- formSquareRoot()
- addProduct(_:,_:)
which require additions to the Builtin module. I can probably figure out how to do these, but I haven't had a chance to do so yet. Also missing are the generic initializers and comparisons whose implementation depends on having new Integer protocols.
The last remaining feature of SE-0067 is that while the basic operators +,-,*,/, etc are moved onto the FloatingPoint protocol, they are still required on the concrete types in order to disambiguate overloads. Fixing this seems to require either modifying the overload resolution rules or removing these operators from some other protocols. Or it might just require that someone smarter than me looks at the problem.
Passes the existing tests locally (with the included changes). I'm working on additional tests for the new features.
This is a purely mechanical change replacing the attributes with the reserved
spelling. Compilers are to not error when they encounter a reserved spelling
for an attribute which they do not support.
There are a couple of features that are not yet implemented, because they require additions to the Builtin module. Specifically, this implementation does not have:
- formRemainder(dividingBy:)
- formSquareRoot()
- addProduct(_:,_:)
Also missing are the generic initializers and comparisons whose implementation depends on having new Integer protocols.
The last remaining feature of SE-0067 is that while the basic operators +,-,*,/, etc are moved onto the FloatingPoint protocol, they are still required on the concrete types in order to disambiguate overloads. Fixing this seems to require either modifying the overload resolution rules or removing these operators from some other protocols. Or it might just require that someone smarter than me looks at the problem.
Passes all the existing tests (with the included changes). I'm working on additional tests for the new features.
* [stdlib] SE-0061: Add Generic Result and Error Handling to autoreleasepool()
Added `rethrows` and generic return type to ObjectiveC.autoreleasepool.
Added tests of these new capabilities.
Fixes SR-1394 and SR-842
* Updated for code style review.
The general rule here is that something needs to be SWIFT_CC(swift)
if it's just declared in Swift code using _silgen_name, as opposed to
importing something via a header.
Of course, SWIFT_CC(swift) expands to nothing by default for now, and
I haven't made an effort yet to add the indirect-result / context
parameter ABI attributes. This is just a best-effort first pass.
I also took the opportunity to shift a few files to just implement
their shims header and to demote a few things to be private stdlib
interfaces.
This is a squash of the following commits:
* [SE-0054] Import function pointer arg, return types, typedefs as optional
IUOs are only allowed on function decl arguments and return types, so
don't import typedefs or function pointer args or return types as IUO.
* [SE-0054] Only allow IUOs in function arg and result type.
When validating a TypeRepr, raise a diagnostic if an IUO is found
anywhere other thn the top level or as a function parameter or return
tpye.
* [SE-0054] Disable inference of IUOs by default
When considering a constraint of the form '$T1 is convertible to T!',
generate potential bindings 'T' and 'T?' for $T1, but not 'T!'. This
prevents variables without explicit type information from ending up with
IUO type. It also prevents implicit instantiation of functions and types
with IUO type arguments.
* [SE-0054] Remove the -disable-infer-iuos flag.
* Add nonnull annotations to ObjectiveCTests.h in benchmark suite.
The defaults we were generating for Collection and
BidirectionalCollection didn't make any sense, because if you could do
that strideable arithmetic then you essentially had random access.
Instead we constrain the defaults to apply to RandomAccessCollection
where the Indices are a CountableRange.
