This refactors DWARFImporter to become a part of ClangImporter, since
it needs access to many of its implementation details anyway. The
DWARFImporterDelegate is just another mechanism for deserializing
Clang ASTs and once we have a Clang AST, the processing is effectively
the same.
When we transform each expression or statement in a function builder,
introduce a one-way constraint so that type information does not flow
backwards from the context into that statement or expression. This
more closely mimics the behavior of normal code, where type inference
is per-statement, flowing from top to bottom.
This also allows us to isolate different expressions and statements
within a closure that's passed into a function builder parameter,
reducing the search space and (hopefully) improving compile times for
large function builder closures.
For now, put this functionality behind the compiler flag
`-enable-function-builder-one-way-constraints` for testing purposes;
we still have both optimization and correctness work to do to turn
this on by default.
This change modifies spare bit masks so that they are arranged in
the byte order of the target platform. It also modifies and
consolidates the code that gathers and scatters bits into enum
values.
All enum-related validation tests are now passing on IBM Z (s390x)
which is a big-endian platform.
This flag adds diagnostic names to the end of their messages, e.g. 'error: cannot convert value of type '[Any]' to specified type '[Int]' [cannot_convert_initializer_value]'. It's intended to be used for debugging purposes when working on the compiler.
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.
The backwards-deployment install name trickery we're using doesn't
handle "patch" components in version numbers, so we still need to
provide an rpath even when deploying to macOS 10.14.4.
Fixes rdar://problem/53407949 | SR-11138. Previously, we'd only look at the outermost property wrapper to decide whether the wrapped property's getter and setter were `mutating` (or exist at all). In reality, this requires considering the semantics of the composed accesses of each wrapper layer's
`wrappedValue` property. Fixing this systematically addresses a number of issues:
- As SR-11138 reported, composing a nonmutating-get-set wrapper ought to produce a composed wrapper
that's nonmutating.
- We would previously allow a property wrapper with a mutating getter to be nested inside one with
only a getter, even though the resulting implementation was unsound (because there's no mutable
context for the inner wrapper to execute its get on.)
- Similarly, we would construct unsound setters in cases where the setter can't exist, such as when
the nested wrapper isn't settable but the outer wrapper is.
IDE functionality needs some internal type checking logics, e.g. checking
whether an extension is applicable to a concrete type. We used to directly
expose an header from sema called IDETypeChecking.h so that IDE functionalities
could invoke these APIs. The goal of the commit and following commits is to
expose evaluator requests instead of directly exposing function entry points from
sema so that we could later move IDETypeChecking.h to libIDE and implement these functions
by internally evaluating these requests.
This improves on the previous situation:
- The request ensures that the backing storage for lazy properties
and property wrappers gets synthesized first; previously it was
only somewhat guaranteed by callers.
- Instead of returning a range this just returns an ArrayRef,
which simplifies clients.
- Indexing into the ArrayRef is O(1), which addresses some FIXMEs
in the SIL optimizer.
Extend the "type check function body" request to also cover the case
where we have a specific ending source location. Fold all of this
functionality into a single request, so we consistently go through a
request to compute a type-checked function body.
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems into a
single overlay file system, and using that. To make this possible, we
always initialize the file manager with an overlay file system. In the
clang importer, we then create a new overlay file system, starting with
the one coming from clang, and adding overlays from swift on top.
The motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
This change fixes the ExponentialGrowthAppendingBinaryByteStream
tests on big endian machines.
Force ExponentialGrowthAppendingBinaryByteStreams to use little-
endian byte order. We always used little-endian byte order anyway
and it seems very unlikely we'll need the flexibility to make the
stream big-endian in the future. The benefit of this is that we
can use portable APIs while still allowing the compiler to remove
conditional byte swaps.
Also replace writeRaw with writeInteger and make it explicitly
little-endian to make the API cleaner and more portable.
When performing code-completion inside the body of a @functionBuilder
closure/function, set the flag to suppress diagnostics. This works
around a big performance problem in some complex bodies that do not
typecheck, which is typical during code-completion. A real-world example
with SwitfUI went from ~50 seconds to 0.5. We do not disable diagnostics
in general because the diagnostic paths provide falback types that are
useful to code-completion.
rdar://52356229
