We have a lot of "transform a range" types already:
llvm::mapped_iterator, swift::TransformRange and
swift::TransformIterator, and swift::ArrayRefView for static
transformations. This gets rid of one more layer without losing
any real functionality.
For some time now we have had the API ValueBase::getSingleUserOfType<T>() but we
never implemented getUsersOfType<T>() using transform/filter iterators.
Since there wasn't a specific API, several incarnations of this API have been
created for BeginBorrow, LoadBorrow, BeginAccess.
In this commit, I introduce the API and use it to excise the redundant code in
those above mentioned 3 instructions.
The reason not to do this is that some important range
adapters (e.x. llvm::iterator_range) do not have such a typedef. Rather than
changing upstream this commit just fixes the problem by inferring the iterator
type from the result of Range::begin().
TLDR: This makes OptionalTransformRange work with llvm::iterator_range.
NOTE:
1. To test this I changed UnaryOp_match to use this under the hood.
2. These types of m_##ID##Inst matchers now will only accept compound types and
I added a static assert to verify that this mistake doesn't happen. We
previously had matchers that would take an int or the like to match tuple
extract patterns. I converted those to use TupleExtractOperation that also
properly handles destructures.
...by coalescing duplicates and dropping conflicts. Both cases can
happen with "expected-error 2 {{...}}": we might get multiple fix-its
providing the same new message, or one message might have diverged
into two, giving us incompatible changes.
...so that we don't have to keep coming back to update it every major
release. And also so we can actually put methods on it instead of
using free functions.
No intended behavior change (yet).
These work like next_or_end or prev_or_begin, except that instead of forcing the
default value to be the compared against the value, you can specify the value
used upon going out of range.
i.e., instead of:
(x, y) -> (x == y) ? y : std::next(x)
We have:
(x, y, z) -> (x == y) ? z : std::next(x)
This is a strict generalization of next_or_end and prev_or_begin so I
re-implemented both routines in terms of the new routines, so no source needed
to be updated.
I put in a simple fixup pass (MarkUninitializedFixup) for staging purposes. I
don't expect it to be in tree long. I just did not feel comfortable fixing up in
1 commit all of the passes up to DI.
rdar://31521023
Separate formal lowered types from SIL types.
The SIL type of an argument will depend on the SIL module's conventions.
The module conventions are determined by the SIL stage and LangOpts.
Almost NFC, but specialized manglings are broken incidentally as a result of
fixes to the way passes handle book-keeping of aruments. The mangler is fixed in
the subsequent commit.
Otherwise, NFC is intended, but quite possible do to rewriting the logic in many
places.
The difference is that TransformArrayRef stores its function as an std::function
instead of using a template parameter. This is useful in situations where one
wants to define such a type in a header on forward declared pointers. If one had
to define the function to be used as a template parameter, one would have to
define the function or provide a forward declared version
This will allow for modules to be split from the command line using a script.
The one thing that is missing from this still is that it does not handle shared
functions in IMO a satisfactory way. Given that we are splitting a module, my
feeling that the correct way to do this is to create a public shim for the
shared function in the module that the shared function gets put in and let all
other users use that entry point.
But I need to think about this a bit more.
The behaviour of ilist has changed in LLVM. It is no longer permissible to
dereference the `end()` value. Add a check to ensure that we do not
accidentally dereference the iterator.
- Added missing ifdef guard in PointerIntEnum header
- Consistent naming convention for ifdef guards
- Consistent 'end namespace swift'
- Consistent single EOL at end of header files
Specifically:
1. set_union_for_each. This is like std::for_each, but it visits its inputs
(which are assumed to be sorted/uniqued sets) in set_union order.
2. is_uniqued_and_sorted.
I also fixed several nits from Jordan.
This is something that we have wanted for a long time and will enable us to
remove some hacks from the compiler (i.e. how we determine in the ARC optimizer
that we have "fatalError" like function) and also express new things like
"noarc".
Specifically:
1. Use std::enable_if to enforce that the passed in collection's iterator is a
random access iterator.
2. Add comment that explains that the container must have an erase method that
can remove a range of items specified by a random access iterator.
Swift SVN r25015
This helper function takes in a vector-like object and then performs:
std::sort(v.begin(), v.end());
v.erase(std::unique(v.begin(), v.end()), v.end());
Swift SVN r25003
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
We're going to want these various adaptors, and helpers built on top
of them, when we replace the array-based storage of members in nominal
types and extensions with something more sane.
Swift SVN r16569
Let ArchetypeType nested types and PotentialArchetypes be bound to concrete types in addition to archetypes. Constraints to outer context archetypes still suffer type-checker issues, but constraints to true concrete types should work now.
Swift SVN r14832
Note that the import kind is not checked yet; this is effectively our old
behavior for "import swift.print".
Infrastructure: move Module::forAllVisibleModules out-of-line, and add
makeStackLambda to STLExtras for using a non-escaping lambda with
std::function.
Swift SVN r6852
These still need to be serialized, because they are one-to-one with the
type's protocol list, but don't actually require any data. Found on
attempting to emit a module for the standard library.
Most of the churn here is moving Interleave.h to a more general STLExtras.h.
Swift SVN r6167
