This functionality doesn’t really change what we accept right now, because we eagerly import all of the methods of a class when we do *any* kind of lookup into the class. However, when we manage to stop doing that, this operation will become more important.
Swift SVN r23289
This teaches the driver's Compilation to not run jobs where the base input
is older than the main output (r23221) when we're tracking dependencies.
After a compile command finishes, anything that depended on the file that
just got compiled will get scheduled.
This has the nice side effect of trying to rebuild changed files first.
The tests here aren't really testing the dependency graph yet, because the
files don't include any dependencies. I'll be adding several more test
scenarios in the next few commits.
Part of rdar://problem/15353101
Swift SVN r23273
This will be used to test dependency analysis by substituting a different
executable to use as the frontend.
For debugging purposes only.
Swift SVN r23272
optimizer freezing releases in the epilogue of functions that match to
SILArguments. This allows us to treat all such SILArguments throughout the
entire function as having a post dominating release.
<rdar://problem/18923030>
Swift SVN r23253
Also, remove calls to isSwiftReservedName in
ClangImporter::Implementation::importName(), since 'true' and 'false'
are now keywords and rdar://problem/13187570 is no longer a problem.
rdar://problem/18797808
Swift SVN r23244
This adds an analysis to the compiler that identifies types that are may store
to memory on destruction.
It adds a compiler known protocol _DestructorSafeContainer that allows the
standard library to identify containers whose destructor's memory effects
depends strictly on the type parameters of the container.
Array<T> : _DestructorSafeContainer {} may not store to memory during
destruction if the bound T is a type that does not store to memory on
destruction.
This is needed to deduce that for example Array<Array<Int>> is does not store to
memory on destruction (e.g during a call to release).
rdar://18940376
Swift SVN r23242
These always fail, and it doesn't make sense to inline this check into the cast site, so provide additional runtime functions for metatype-to-objc-existential casts.
Swift SVN r23237
Unless DWARFmangling is set all methods still expect a CanonicalType.
Fixes <rdar://problem/17042576> [6A214t] Debug information has wrong type for dispatch queue
Swift SVN r23226
...and some basic unit tests for it.
The purpose of this class is to track dependencies between opaque nodes.
The dependency edges are (kind, string) pairs, where the "kind"
distinguishes different kinds of dependencies (currently "top-level names"
and "types that we do lookup on"). The step is to make use of it in
running compile commands.
The YAML-based file format is only for bring-up and testing purposes.
I intend to switch it to a bitcode-based format in the long run.
Part of rdar://problem/15353101
Swift SVN r23223
Previously we had three separate instances of iterating from TY_INVALID+1
to TY_LAST, completely breaking type safety. Now we have a nice little
wrapper that takes a closure, which should inline down to the same thing
anyway.
Also, eliminate TY_LAST and just use TY_INVALID as our sentinel.
Swift SVN r23222
The Swift compiler is always fed the entire list of files in a module.
If it's told to track dependencies, though, it should look to see if it
actually needs to recompile all of its inputs. The first step in this is
to see which files are actually dirty, which it does by comparing the mtime
of each source file with the mtime of its output object file. If a source
file is not dirty, it only needs to be rebuilt if it depends on something
in a dirty file.
Nothing actually uses this information yet, but we can print it with
-driver-print-bindings!
Swift SVN r23221
This just adds another possible output kind and forwards it to the frontend.
Note that in builds without an output map, this will just dump the dependencies
next to the output file, which is a temp file whose name is chosen randomly.
That's not so useful, but we can fix it later.
Part of rdar://problem/15353101
Swift SVN r23220
Given a function F, this utility class attempts to match up owned arguments with
releases in the epilogue of the function.
I am refactoring this from FunctionSigOpts so I can use it in the ARC optimizer.
<rdar://problem/18923030>
Swift SVN r23219
Include a mapping from Objective-C selectors to the @objc methods that
produce Objective-c methods with those selectors. Use this to lazily
populate the Objective-C method lookup tables in each class. This makes
@objc override checking work across Swift modules, which is part of
rdar://problem/18391046.
Note that we use a single, unified selector table, both because it is
simpler and because it makes global queries ("is there any method with
the given selector?") easier.
Swift SVN r23214
Objective-C method unintended override checking is one such case where
properly checking unintended overrides requires us to essentially look
at the whole module, because one translation unit may declare
something that produces an Objective-C method "setFoo:" in a
superclass while another translation unit declares something with a
distinct name that produces an Objective-C method "setFoo:". So, when
we don't have a primary file (e.g., when we're doing the merge-module
step), delay such checks until after all the source files for the
module have been type-checked. When there is a primary file, we
perform the checking that we can based on type checking that primary
file (and whatever got touched along the way), so we get a subset of
the proper diagnostics.
Swift SVN r23179
Diagnose cases where the use of @objc will produce Objective-C methods
that end up overriding an Objective-C method in a superclass, when
that override is not properly represented as an override in the Swift
type system. This can happen when the Objective-C methods are produced
by different kinds of entities. For example:
class Super {
@objc var property: Int
}
class Sub : Super {
@objc func setProperty(property: Int) { }
}
In Swift, Sub.setProperty and Super.property are completely
unrelated. However, both produce an Objective-C instance method with
the selector "setProperty:", so we end up with unexpected overriding
behavior. Diagnose this whenever it occurs, regardless of the kind of
@objc entity that produced the Objective-C methods: initializers,
deinitializers, methods, properties, or subscripts.
Implements the rest of the intended functionality of
rdar://problem/18391046, with the caveat that there are two remaining
classes of bugs:
1) Superclasses defined in a module (or imported from a Clang
module) aren't handled properly yet; we might not see those methods.
2) We won't properly detect all of these failures when the methods
are scattered across different source files in the same module.
Swift SVN r23170
Per Jordan, it's OK to assume that nothing will have more than 2 billion members
or protocols, so make this an llvm::Fixnum<31> instead of an llvm::Fixnum<63>.
Swift SVN r23167
@objc methods, initializers, deinitializers, properties, and
subscripts all produce Objective-C methods. Diagnose cases where two
such entities (which may be of different kinds) produce the same
Objective-C method in the same class.
As a special exception, one can have an Objective-C method in an
extension that conflicts with an Objective-C method in the original
class definition, so long as the original class definition is from a
different model. This reflects the reality in Objective-C that the
category definition wins over the original definition, and is used in
at least one overlay (SpriteKit).
This is the first part of rdar://problem/18391046; the second part
involves checking that overrides are sane.
Swift SVN r23147
...and rename Command to Job (previously the name of the base class).
We never generated job lists directly contained in other job lists, so
let's not even worry about this case. We may some day need to break Job
out into separate subclasses (Clang has Command and FallbackCommand in
addition to JobList), but we should be able to keep the list separate.
No intended functionality change.
Swift SVN r23144
Instead, if we can't schedule a command, record why it was blocked. When the
blocking command completes, we then try to reschedule everything that was
blocked on it.
This is also more robust for cross-job-list dependencies---things like the
link job depending on the merge-module job and both depending on compile jobs.
Swift SVN r23143
Before it was done with a big switch statement, which remained a switch until the final code.
Now it's done by getting an integer index for both enums and just doing an integer compare.
This results in a simple compare in the final code.
Note that the == function is only generated for enums without payload. Getting the integer
index of such enums is a cheap operation.
Swift SVN r23129
We'd like to kill this enum off eventually, since the runtime inevitably needs to be able to handle arbitrary checked casts in opaque contexts, and SILGen and IRGen can deal with picking more optimal runtime entry points for specific casts. Only the container bridging kinds are still depended on anymore, and even those ought to eventually be handlable by the runtime in 'x as T' situations. NFC yet.
Swift SVN r23127
When there's no init function, we can do relaxed loads and stores, because the metadata record will not change in the course of canonicalization. However, if there is initialization, we need to do a release-consume in order to ensure the initialization is visible to readers.
Swift SVN r23119
Also handles mangling, demangling, printing and parsing.
This is the first patch to use global getter for "let" globals.
rdar://16614767
Swift SVN r23106
We lazily realize classes when we access their metadata now, so there's no need to force the ObjC runtime to do this greedily anymore, except for classes that the runtime statically references. For those cases, add an @objc_non_lazy_realization class attribute that will put that class reference in the nlclslist section.
Swift SVN r23105
CmpXChg builtins now return (T, Bool) to match the LLVM return value.
Turn the tests back on and check extractvalue / inttoptr instructions.
<rdar://problem/17309776> Update modeling of cmpxchg builtin to handle weak-ness and separate success bit
Swift SVN r23104
This will help the ARC optimizer given future function sig optimization work and
is in general good since this has been a hole in our load store forwarding for a
while.
rdar://18831605
Swift SVN r23102
Per review from Dmitri and Greg. We can do relaxed loads (if we miss the store, we'll lock the global hashtable and find the metadata that way), but we need a seq_cst barrier when we store.
Swift SVN r23101
The race here was benign--we just end up writing the same uniqued value twice to the invasive cache. Relax the assertion that this used to trip.
Swift SVN r23098
Move the uniquing information for ForeignTypeMetadata behind the address point so we can share the layout between foreign classes and the existing layout for struct and enum metadata. Emit metadata records for imported structs and enums as foreign metadata candidates, and dynamically unique references to the metadata by calling swift_getForeignTypeMetadata.
Swift SVN r23081
As a stopgap till IRGen properly emits indirected class references, support direct class reference protocol conformance records. This should get us to the point we can replace the dlsym hack with the new implementation.
Swift SVN r23073
We were missing -_tryRetain, -_isDeallocating, -allowsWeakReference and -retainWeakReference implementations on SwiftObject, so forming an ObjC weak reference to a pure Swift object always failed and produced a nil reference. Fixes rdar://problem/18637774.
This can be reapplied now that we properly call objc_destructInstance on deallocation.
Swift SVN r23070
