Add a new convention to describe what happens with
nonzero_result on a type that isn't imported as Bool.
This isn't really a safe convention to implement, but
calls are fine.
Implements <rdar://21715350>.
Swift SVN r29953
Compiler output at least up to serialization should be deterministic at this point,
at least when not taking SIL into account. This /should/ mean that changing a
function body should not affect the final built swiftmodule, which means downstream
targets don't need to be rebuilt. Leaving the previous swiftmodule output in place
signals that.
A while back I put in a push to get all the non-determinism out of type checking,
importing, and serialization itself; it looks like we've finally made it. Let's keep
it that way!
rdar://problem/20539158 and others
Swift SVN r29923
Represents a heap allocation containing a value of type T, which we'll be able to use to represent the payloads of indirect enum cases, and also improve codegen of current boxes, which generates non-uniqued box metadata on every allocation, which is dumb. No codegen changes or IRGen support yet; that will come later.
This time, fix a paste-o that caused SILBlockStorageTypes to get replaced with SILBoxTypes during type substitution. Oops.
Swift SVN r29489
Represents a heap allocation containing a value of type T, which we'll be able to use to represent the payloads of indirect enum cases, and also improve codegen of current boxes, which generates non-uniqued box metadata on every allocation, which is dumb. No codegen changes or IRGen support yet; that will come later.
Swift SVN r29474
That's how everything behaved anyway. Might as well make it explicit and
stop special-casing it.
I've left in compatibility for modules built with older compilers so that
people using the OS toolchains aren't immediately unable to debug their apps.
As soon as we change the module format in a more significant way, I can take
this out.
Groundwork for rdar://problem/21254367; see next commit.
Swift SVN r29437
initializer has been type-checked, rather than a bit for the entire
PatternBindingDecl.
<rdar://problem/21057425> Crash while compiling attached test-app.
Swift SVN r29049
Based on Dave’s hack, this allows one to define a “default implementation” as, e.g.,
protocol P {
func foo()
}
extension P {
final func foo() { … }
}
Swift SVN r28949
This is more complex than it could be if ExtensionDecl and NominalTypeDecl
had a common ancestor in the Decl hierarchy, however this is not possible
right now because TypeDecl inherits from ValueDecl.
Fixes <rdar://problem/20981254>.
Swift SVN r28941
Unfortunately, we still have non-determinism coming from elsewhere, so we
can't start trying to test this yet.
Motivated by rdar://problem/20539158
Swift SVN r28576
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
Now that we don't have generic parameter lists at arbitrary positions
within the extended type of an extension declaration, simplify the
representation of the extended type down to a TypeLoc along with a
(compiler-synthesized) generic parameter list.
On the parsing side, just parse a type for the extended type, rather
than having a special grammar. We still reject anything that is not a
nominal type (of course), but it's simpler just to call it a type.
As a drive-by, fix the crasher when extending a type with module
qualification, rdar://problem/20900870.
Swift SVN r28469
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
When reading the generic parameters of a constrained protocol
extension, cross-refencing an associated type would perform name
lookup into the protocol extension itself, causing fatal recursion
during deserialization. Fixed by avoiding additional deserialization
when looking for an associated type. Fixes rdar://problem/20812303.
Swift SVN r28228
Rather than swizzle the superclass of these bridging classes at +load time, have the compiler set their ObjC runtime base classes, using a "@_swift_native_objc_runtime_base" attribute that tells the compiler to use a different implicit base class from SwiftObject. This lets the runtime shed its last lingering +loads, and should overall be more robust, since it doesn't rely on static initialization order or deprecated ObjC runtime calls.
Swift SVN r28219
Otherwise, when a file contains a local enum, the decl for its synthesized
== ends up disappearing, and we get a dangling XREF.
rdar://problem/20429123
Swift SVN r28131
preserve the original method name.
This heuristic is based on the Objective-C selector and therefore
doesn't really handle factory methods that would conflict with
initializers, but we can hope that those simply don't come up in
the wild.
It's not clear that this is the best thing to do --- it tends to
promote the non-throwing API over what's probably a newer, throwing
API --- but it's significantly easier, and it unblocks code without
creating deployment problems.
Swift SVN r28066
@warn_unused_result can be attached to function declarations to
produce a warning if the function is called but its result is not
used. It has two optional parameters that can be placed in
parentheses:
message="some message": a message to include with the warning.
mutable_variant="somedecl": the name of the mutable variant of the
method that should be suggested when the subject method is called on
a mutable value.
The specific use we're implementing this for now is for the mutating
and in-place operations. For example:
@warn_unused_result(mutable_variant="sortInPlace") func sort() -> [Generator.Element] { ... }
mutating func sortInPlace() { ... }
Translate Clang's __attribute__((warn_unused_result)) into
@warn_unused_result.
Implements rdar://problem/18165189.
Swift SVN r28019
Printing a module as Objective-C turns out to be a fantastic way to
verify the (de-)serialization of foreign error conventions, so
collapse the parsing-driving Objective-C printing test of throwing
methods into the general test for methods.
Swift SVN r27880
Printing a module as Objective-C turns out to be a fantastic way to
verify the (de-)serialization of foreign error conventions, so
collapse the parsing-driving Objective-C printing test of throwing
methods into the general test for methods.
Swift SVN r27870
Extensions cannot be uniquely cross-referenced, so cross-references to
extensions are serialized with the extended nominal type name and the
module in which the extension resides. This is not sufficient when
cross-referencing the generic type parameters of a constrained
protocol extension, because we don't know whether to get the
archetypes of the nominal type or some extension thereof. Serialize
the canonical generic signature so that we can pick an extension with
the same generic signature; it doesn't matter which we pick, so long
as we're consistent.
Fixes rdar://problem/20680169. Triggering this involves some
interesting interactions between the optimizer and standard library;
the standard library updates in the radar will test this.
Swift SVN r27825
the printed interface.
Previously we printed the typechecked and uniqued requirements and the result was non-sensical.
Long-term the requirements will be preserved in a better form but for now print the requirements
and serialize them.
rdar://19963093
Swift SVN r27680
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27355
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27339
This is an internal-only affordance for the numerics team to be able to work on SIMD-compatible types. For now, it can only increase alignment of fixed-layout structs and enums; dynamic layout, classes, and other obvious extensions are left to another day when we can design a proper layout control design.
Swift SVN r27323
Currently untestable (due to SILGen's inability to handle throwing
@objc methods), but testing will become trivial once that's in place.
Swift SVN r27294
Currently untestable (due to SILGen's inability to handle throwing
@objc methods), but testing will become trivial once that's in place.
Swift SVN r27290
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
This is the new and improved version of
__attribute__((annotate("swift1_unavailable"))), with the "improved" being
specifically that the 'availability' attribute supports a message.
This requires a corresponding Clang commit.
Swift side of rdar://problem/18768673.
Swift SVN r27053
"Autoclosure" is uninteresting to SIL. "noescape" isn't currently used by SIL and we shouldn't have it until it has a meaningful effect on SIL. "throws" should be adequately represented by a SIL function type having an error result.
Swift SVN r27023
The set of attributes that make sense at the AST level is increasingly divergent from those at the SIL level, so it doesn't really make sense for these to be the same. It'll also help prevent us from accidental unwanted propagation of attributes from the AST to SIL, which has caused bugs in the past. For staging purposes, start off with SILFunctionType's versions exactly the same as the FunctionType versions, which necessitates some ugly glue code but minimizes the potential disruption.
Swift SVN r27022
Another step toward using the conformance lookup table for
everything. This uncovered a tricky little bug in the conformance
lookup table's filtering logic (when asking for only those
conformances explicitly specified within a particular context) that
would end up dropping non-explicit conformances from the table (rather
than just the result).
Ween a few tests off of -enable-source-import, because they'll break
otherwise.
Swift SVN r27021
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
to represent them, and just dropped them on the ground. Now we parse them,
persist them in the AST, and "resolve" them from the expr grammar, but still
drop them on the ground. This is progress towards fixing: rdar://20135489
Swift SVN r26828
Flatten several nested loops that tried to take care of this into a single
outer loop-until-really-done loop.
No test case; this is a preventative measure, not a response to an actual bug.
Swift SVN r26823
...rather than re-emitting the conformance in the current file, and then
trying to cross-reference the decl context that owns the conformance, which
may be an extension.
rdar://problem/20383044
Swift SVN r26822
This patch introduces a new kind of pattern for matching bool literals, i.e. true and false. Essentially, it is very similar to a pattern for matching enum elements, but simpler. Most of the code is just a boiler plate code copy/pasted from the code for enum element patterns. The only different thing is the emitBoolDispatch function, which emits a SIL code for matching bools.
With this patch, we don't get any false non-exhaustive switch diagnostics for switches on bools anymore. And we have a lot of radars complaining about it. For example rdar://16514545 and rdar://20130240.
Note, that this patch fixes the non-exhaustive switch diagnostics without changing the internal representation of bools. Implementing bool as an enum would have the same effect when it comes to these diagnostics and we would get this diagnostics fix for free, i.e. without any code committed here. But implementing bools-as-enums is an ongoing work and I'm investigating its performance implications. If we become confident that bool-as-enum does not have a negative impact on performance and decide to merge it, then we can revert this patch as it would not be necessary anymore. But if we decide to skip the enum-as-bool approach to its performance issues, then we would have at least fixed the false non-exhaustive diagnostics for bools by means of this patch.
Swift SVN r26650
