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
"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
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
The new base class ApplyInstBase contains APIs that are common for ApplyInst and PartialApplyInst. It allows such optimization passes like generic specializer to treat both instructions in the same way whenever it is possible. Before this change, one had to duplicate and adjust a lot of implementation code in such passes, because ApplyInst and PartialApplyInst were not related to each other in any form.
The existing clients of both classes can continue using the usual APIs. No changes are required. Only new clients, which want to treat ApplyInst and PartialApplyInst in a uniform way, may do so. One of such new clients is the generic specializer, whose adjusted implementation will be submitted in the following commit.
Swift SVN r26581
We no longer need or use it since we can always refer to the same bit on
the applied function when deciding whether to inline during mandatory
inlining.
Resolves rdar://problem/19478366.
Swift SVN r26534
Rename 'assignment' attribute of infix operators to 'mutating'. Add
'has_assignment' attribute, which results in an implicit declaration of
the assignment version of the same operator. Parse "func =foo"
declaration and "foo.=bar" expression. Validate some basic properties of
in-place methods.
Not yet implemented: automatic generation of wrapper for =foo() if foo()
is implemented, or vice versa; likewise for operators.
Swift SVN r26508
Primarily, unique normal protocol conformances and reference them via
a conformance ID. This eliminates the use of trailing records for
normal protocol conformances and (more importantly) the cases were we
would write incomplete conformances. The latter could cause problems
if we ever ended up deserializing an incomplete conformance without
also deserializing a complete record for that same conformance.
Secondarily, simplify the way we write conformances. They are now
always trailing records, and we separate out the derived conformance
kinds (specialized/inherited) from either a reference to a normal
conformance in the current module file (via a normal conformance ID)
or via a cross-reference to a conformance in another module file
(currently always a normal conformance, but this need not always be
the case). As part of this, make each conformance record
self-sustaining, so we don't have to push information down to the
reading routines (e.g., the conforming type) to actually produce a
proper conformance. This simplifies deserialization logic further.
Swift SVN r26482
This lets us tag imported declarations with arbitrary synthesized
protocols. Use it to handle imported raw option sets as well as the
RawRepresentable conformances of enums that come in as structs.
Swift SVN r26298
This flag indicates that internal APIs within the module should be made
available to client code for testing purposes. Currently does nothing.
Not ready for developer consumption yet, ergo a hidden frontend-only flag.
Part of testability (rdar://problem/17732115)
Swift SVN r26292
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
The deallocating parameter convention is a new convention put on a
non-trivial parameter if the caller function guarantees to the callee
that the parameter has the deallocating bit set in its object header.
This means that retains and releases do not need to be emitted on these
parameters even though they are non-trivial. This helps to solve a bug
in +0 self and makes it trivial for the optimizer to perform
optimizations based on this property.
It is not emitted yet by SILGen and will only be put on the self
argument of Deallocator functions.
Swift SVN r26179
...so that the debugger has the best possible chance of being able to load
the app properly.
We don't do this for frameworks today because we don't want to leak this
information into the public module; once we have a distinction between
"the module that ships with the framework" and "the module that goes into
the debug info" we can do this for frameworks as well.
Part of rdar://problem/17670778
Swift SVN r25204
This will have an effect on inlining into thunks.
Currently this flag is set for witness thunks and thunks from function signature optimization.
No change in code generation, yet.
Swift SVN r24998
There were no clients and it leaks information about the developer's system.
After this commit, there should be no full paths present in framework modules.
(App modules may contain search paths for debugging reasons, as well as a
full or relative path to the bridging header.)
Swift SVN r24851
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
There's also a testing option, -serialize-debugging-options, to force this
extra info to be serialized even for library targets. In the long run we'll
probably write out this information for all targets, but strip it out of
the "public module" when a framework is built. (That way it ends up in the
debug info's copy of the module.)
Incidentally, this commit includes the ability to add search paths to the
Clang importer on the fly, which is most of rdar://problem/16347147.
Unfortunately there's no centralized way to add search paths to both Clang
/and/ Swift at the moment.
Part of rdar://problem/17670778
Swift SVN r24545
This isn't being used for much yet, but it will allow us to tell whether
something is an app target even at the module-merging stage, which is a
better way to tell if something is an app than whether it has a bridging
header.
We'll also need this if we ever take advantage of reusing "partial modules"
(serialized ASTs for other parts of the module that aren't affected by the
current source file) for compiling source files in incremental builds;
unfortunately that's unlikely given our dependency model.
Swift SVN r24531
Refuse to load a module if it was compiled for a different architecture or
OS, or if its minimum deployment target is newer than the current target.
Additionally, provide the target triple as part of pre-loading validation
for clients who care (like LLDB).
Part of rdar://problem/17670778
Swift SVN r24469
Changing the design of this to maintain more local context
information and changing the lookup API.
This reverts commit 4f2ff1819064dc61c20e31c7c308ae6b3e6615d0.
Swift SVN r24432
rdar://problem/18295292
Locally scoped type declarations were previously not serialized into the
module, which meant that the debugger couldn't reason about the
structure of instances of those types.
Introduce a new mangling for local types:
[file basename MD5][counter][identifier]
This allows the demangle node's data to be used directly for lookup
without having to backtrack in the debugger.
Local decls are now serialized into a LOCAL_TYPE_DECLS table in the
module, which acts as the backing hash table for looking up
[file basename MD5][counter][identifier] -> DeclID mappings.
New tests:
* swift-ide-test mode for testing the demangle/lookup/mangle lifecycle
of a module that contains local decls
* mangling
* module merging with local decls
Swift SVN r24426
