Filter out any duplicate notes to help cut down on the noise for
request cycle diagnostics. Some of the note locations here still aren't
great, but this at least stops us from repeating them for each
intermediate request.
Tuple extensions are still an experimental feature, but we have a
number of crashers in the repo for them because we still use their
type-checker machinery even when disabled. Change the logic here such
that we reject them early in extension binding when the feature is
disabled. This will ensure we address the crashers before productizing.
Make sure we canonicalize the original type for an ErrorType to ensure
that diagnostic logic can coalesce ErrorTypes that have the same
canonical type.
If we failed to construct a rewrite system for a protocol, either because
the Knuth-Bendix algorithm failed or because of a request cycle while
resolving requirements, we would end up in a situation where the resulting
rewrite system didn't include all conformance requirements and associated
types, so name lookup would find declarations whose interface types are
not valid type parameters.
Fix this by propagating failure better and just doing nothing in
getReducedTypeParameter().
Fixes rdar://147277543.
@c @implementation relies on matching the original C declaration. The
lookup for the original C declaration was doing the wrong kind of
lookup, meaning that it could only find the C declaration if it came
through a bridging header, and not through a normal module import.
Using unqualified lookup here finds the name appropriately.
Clarify the diagnostics here as well to not talk about umbrella and
bridging headers.
Fixes rdar://161909754.
This patch relaxes the access check for members of imported inherited
nested enums. Without it, those members become impossible to inherit,
which largely defeats the purpose of importing them in the first place.
rdar://160803362
This removes erroneous references to `_OBJC_CLASS_$__xyz` symbols that Swift was emitting for certain usages of C/C++ foreign reference types. This was discovered when trying to iterate over a Swift array of foreign reference types using a Swift for-in loop.
`Builtin.canBeClass` was returning true for foreign reference types, which led to the optimizer specializing the generic `canBeClass<T>` function to unconditionally return true for foreign reference types. This meant that `_isClassOrObjCExistential` for a foreign reference type evaluated to true, which made the Swift stdlib take the code path that was intended for Objective-C classes in `ArrayBuffer.getElement`, which assumed that the `Element` type conforms to `AnyObject`. Foreign reference types do not actually conform to `AnyObject`.
rdar://161814644
This means we now either produce a bare ErrorType, or an ErrorType
with a generic parameter original type for a generic parameter hole.
We ought to further consolidate this logic by sinking the generic
parameter original type replacement into `simplifyType` itself, but
I'm leaving that for a future patch since it affects completion
results and I want to try keep this close to NFC.
The `_Concurrency` and `_StringProcessing` modules are implementation details of the standard library; to developers, their contents should behave as though they are declared directly within module `Swift`. This is the exact same behavior we expect of cross-import overlays, so treat these modules as though they are cross-import overlays with no bystanding module.
Because these modules don’t re-export the standard library, it’s also necessary to treat `Swift` as a separately imported overlay of itself; do so and make that actually work.
The intent for `@inline(always)` is to act as an optimization control.
The user can rely on inlining to happen or the compiler will emit an error
message.
Because function values can be dynamic (closures, protocol/class lookup)
this guarantee can only be upheld for direct function references.
In cases where the optimizer can resolve dynamic function values the
attribute shall be respected.
rdar://148608854
Now that we have a per-ASTContext StaticBuildConfiguration, reimplement
(almost) everything in CompilerBuildConfiguration to sit on top of it.
Only canImport requires the full ASTContext, so that gets its own
implementation, as does one other operation that can produce an error.
Aside from more code sharing, this provides additional validation that
the StaticBuildConfiguration we build is complete and accurate.
Thread the static build configuration (formed from language options) in
to the macro plugin handler, which will serialize it for use in the
macro implementation. test this with a simple macro that checks
whether a particular custom configuration (set via `-D`) is enabled or
not.
This required some re-layering, sinking the logic for building a
StaticBuildConfiguration from language options down into a new
swiftBasicSwift library, which sits on top of the C++ swiftBasic and
provides Swift functionality for it. That can be used by the C++
swiftAST to cache the StaticBuildConfiguration on the ASTContext,
making it available for other parts of ASTGen.
Introduce the ability to form a `StaticBuildConfiguration` from
language options. Add a frontend option `-print-static-build-config`
to then print that static build configuration as JSON in a manner that
can be decoded into a `StaticBuildConfiguration`.
Most of the change here is in sinking the bridged ASTContext queries
of language options into a new BridgedLangOptions. The printing of the
static build configuration only has a LangOptions (not an ASTContext),
so this refactoring is required for printing.
Now that ErrorType prints as `_`, we can use that instead of UnresolvedType
here since the original type is only really used for type printing and
debugging.
We don't need to print the `@c @implementation` functions in
swiftinterfaces as clients need only to see the original declaration in
the C header. Don't print `@objc @implementation` functions either, but
still print simple `@c` and `@objc` functions.
For non-generic cases we can simply recurse into the underlying type,
ensuring we don't crash with a null GenericSignature. For generic
cases, ensure we bind outer generic parameters to their archetypes,
and apply the substitutions to the original underlying type to ensure
we correctly handle cases where e.g an unbound generic is passed as
a generic argument to a generic typealias.
rdar://160135085