Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Add a special case for `TypeExpr` due to i.e. context specialization,
in such cases there is nothing for the solver to "open" so we need
to form opened type map manually.
Resolves: rdar://111059036
UnresolvedSpecializeExpr.
The eager generic argument matching code in CSGen for unresolved
specializations was incorrect because it didn't account for parameter
packs. Fortunately, a constraint to delay explicit generic argument
matching already exists for macros. Use it here.
Only properties that are listed in 'initializes' and 'accesses'
attributes could be referenced within init accessor. Detect any
and all invalid member references in the solver.
Instead of diagnosing in CSApply, let's create a
fix and diagnose in the solver instead.
Additionally, make sure we assign ErrorTypes to
any VarDecls bound by the invalid pattern, which
fixes a crash.
rdar://110638279
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
There's still plenty of more work to do here for
pattern diagnostics, including introducing a
bunch of new locator elements, and handling things
like argument list mismatches. This at least lets
us fall back to a generic mismatch diagnostic.
Order them such that if they were changed to
conversions, they would be sound. This shouldn't
make a difference, but unfortunately it turns out
pattern equality is not symmetric. As such, tweak
the pattern equality logic to account for the
reversed types. This allows us to remove a special
case from function matching.
The TypedPattern and IsPattern constraints were
incorrectly written, with conversions propagating
out of the patterns, when really conversions
ought to propagate into patterns. In any case, it
seems like we really want equality here. Fix the
constraints to use equality, and have the cast
constraint operate on the external pattern type
instead of the subpattern type.
Don't attempt to wrap `Any` into a single-element tuple to match
against a tuple with pack expansions, this conversion would be
handled by existential promotion if it's allowed, otherwise it
would produce an error.
Resolves: rdar://109160060
SE-390 concluded with choosing the keyword discard rather than forget for
the statement that disables the deinit of a noncopyable type. This commit
adds parsing support for `discard self` and adds a deprecation warning for
`_forget self`.
rdar://108859077
Failure of an argument to AnyHashable parameter to conform to Hashable
protocol should be detected in `simplifyConformsToConstraint` and fixed
there.
Doing so requires impact assessment adjustment because regular conformance
requirements have default impact of 1, this is going to have argument
impact of 2 not avoid clashing with other failures.
If we don't split up the tuple into individual constraints,
we end up spending more time querying whether a tuple is
Copyable in `lookupConformance`, because it will naively
check the types of all elements of the tuple recursively
with `lookupConformance`.
This is inefficient because if we know some of the elements
of the tuple are fixed types, we don't need to keep checking
those again. For example, if we have `($T, Int, $U)`, and
then try a binding for `$T`, we might ask again if the whole
tuple conforms. Leading to `lookupConformance` to check
whether `Int` (and all other elements of the tuple) conforms
to Copyable, when we either already know that, or can't
answer it yet because it's still a type variable.
By splitting up a Copyable constraint on a tuple into
invidivual constraints on each of its type elements,
we can avoid this redundant work by `lookupConformance`.
While today we could short-cut this even further to say
that _all_ tuples are Copyable, since we emit an error if
a noncopyable type appears in one, that won't be true in
the near future. This is the nicer solution we'll want to
keep around long-term.
After discussing this with Pavel, we don't think there's a
good way to add a regression test for this, because the
performance issue primarily comes up in specific example
programs that aren't amenable to scale tests.
resolves rdar://107536402
