* [InterfaceGen] Remove #ifs from default args
This patch removes all #if configs form the bodies of default arguments,
which can contain multiline closures, while preserving the bodies of the
clauses that are active.
This code is generalized and should "just work" for inlinable function
bodies, which will come in a later patch.
* Address review comments
* Fix and test CharSourceRange.overlaps
* Fix CharSourceRange::print to respect half-open ranges
This makes it easier to grep for and eventually remove the
remaining usages.
It also allows you to write FunctionType::get({}, ...) to call the
ArrayRef overload empty parameter list, instead of picking the Type
overload and calling it with an empty Type() value.
While I"m at it, in a few places instead of renaming just clean up
usages where it was completely mechanical to do so.
This patch removes the need for Request objects to provide a default
cycle-breaking value, instead opting to return llvm::Expected so clients
must handle a cycle failure explicitly.
Currently, all clients do the 'default' behavior, but this opens the
possibility for future requests to handle failures explicitly.
Rather than call through the LazyResolver (when available) to satisfy
queries that may require type checking, call into the evaluator
directly: it will make use of the type checker (via the lazy resolver)
when necessary. This change should allow us to use the
request-evaluator’s cache for state rather than mutable AST state,
as well as the ability to see requests that were evaluated after
type checking.
The bundling of the form of a request (e.g., the storage that makes up a request)
with the function that evaluates the request value requires us to perform
ad hoc indirection to address the AST —> Sema layering violation. For
example, ClassDecl::getSuperclass() calls through the LazyResolver (when
available) to form the appropriate request. This means that we cannot
use the the request-evaluator’s cache when LazyResolver is null, forcing
all cached state into the AST.
Provide the evaluator with a zone-based registration system, where each
request “zone” (e.g., the type checker’s requests) registers
callbacks to evaluate each kind of request within that zone. The
evaluator indirects through this table of function pointers, allowing
the request classes themselves to be available at a lower level (AST)
than the functions that perform the computation when the value isn’t
in the cache (e.g., Sema).
We are not taking advantage of the indirection yet; that’ll come in a
follow-up commit.
As a debugging aid, introduce a new frontend flag `-debug-cycles` that
will emit a debug dump whenever the request-evaluator encounters a cyclic
dependency, while otherwise allowing compilation to continue.
The type checker has *lots* cycles, and producing diagnostics for them
at this point in the development of the request-evaluator is not
productive because it breaks currently-working code. Disable cycle
diagnostics for now when using the request-evaluator in the type
checker. We'll enable it later as things improve, or as a separate
logging mode in the interim.
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
Simplify the definition of new request kinds by pulling the parameterization
of caching logic into SimpleRequest itself, so that the caching-related
parts of the contract cannot easily be forgotten.
Introduce another form of debugging dump for the evaluator, rendering the
complete dependency graph using GraphViz, including all dependencies and
values cached within the evaluator.
Perform online tracking of the (direct) dependencies of each request made
to the evaluator, and introduce debugging code to print these dependencies
as a tree (from a particular request).
Introduce a CRTP base class, SimpleRequest, which simplifies the task of
defining a new request kind by handling the storage of the values (in a
std::tuple), their hashing, equality, printing, etc. The values are passed
along to the subclass’s operator() so they’re mostly treated as (const)
parameters, making mutation of the request state impossible.
Extend AnyValue and AnyRequest with printing logic, so we can print any
request for debugging purposes, and
Simplify the static registration of types for use with TypeID by introducing
a more declarative approach. Each zone provides a .def file listing the
types and templates defined by that zone. The .def file is processed by
include/swift/Basic/DefineTypeIDZone.h with its zone number, which assigns
values to each of the types/templates and introduces the TypeID
specializations.
Turn the `activeRequests` stack into a `SetVector` and use it to detect
cycles. This approach works for uncached requests, and lets us simplify
the external-caching protocol quite a bit because we no longer record
“in-flight” states. Simplify the cache as well.
Thanks to Graydon for the suggestion.
Meant as a replacement for the barely-started iterative type checker,
introduce a simpler "evaluator" that can evaluate individual requests
(essentially, function objects with some additional API), caching
results as appropriate and detecting cycles.
It turns out that we need to have the diagnostic consumers set up
before we've actually opened the input files, which makes sense
because we might want to emit diagnostics about not being able to open
an input file. Switch to using file names instead, and mapping those
over to source ranges only once we actually need to handle a
diagnostic with a valid source location.
If a top-level diagnostic is in a particular source range, the
RangeSpecificDiagnosticConsumer will funnel it and any attached notes
to a particular "sub-consumer" designated for that range (intended to
be used with whole files). If it's not in a range designated for any
sub-consumer, the diagnostic is passed to all registered
sub-consumers.
This is intended to be used for batch mode, so that diagnostics that
are definitely associated with a particular file can be emitted in
that file's .dia output, while diagnostics that may be associated with
other files (such as those that come from Clang) will still get
presented to the user.
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
