Placeholder types just like type variables are set up to return
a conformance ref which, in this case, would mean that we'd produce
an invalid diagnostic.
Such tuples should be treated specially because once pack expansion
is sufficiently resolved they'd get exploded and the resulting type
is what member lookup should use as a base.
Resolves: rdar://110721928
`same-shape` mismatch detection logic shouldn't expect that types are
always packs because they could be either invalid (i.e. Void) or pack
archetypes too.
Resolves: rdar://112090069
by creating a BoundGenericType for the keypath expr
with the keypath base and replacing the value with
the value typeVar that will be resolved when the value
typeVar is directly bound.
Ignore conversion score increases during code completion to make sure we don't filter solutions that might start receiving the best score based on a choice of the code completion token.
Generate a conjunction for each tap expression body as soon as it
gets a contextual type instead of separate post-factum type-checking
via `typeCheckTapBody`.
As described in the issue #62922, the compiler should not allow to discard @noDerivative attribute and keep @differentiable. The patch adds a diagnostic for this case.
Resolves#62922.
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.
