Fixes rdar://problem/14776565 (AnyObject lookup for Objective-C
properties with custom getters) and rdar://problem/17184411 (allowing
__attribute__((swift_name("foo"))) to work on anything).
What does that mean? We'll indeed parse the provided prefix header.
If you aren't using a bridging header, that's all you get -- nothing
extra is made visible. If you /are/ using a bridging header, the prefix
header is prepended to it...but none of the modular content it imports
is made visible. I cloned rdar://problem/22083824 to fix that.
The important thing is that we /won't/ try to import overlays before
we've even finished setting up all the module loaders, and therefore
won't crash.
rdar://problem/20893290
Swift SVN r30831
"unavoidable failure" path, along with Failure::DoesNotHaveNonMutatingMember and
just doing some basic disambiguation in CSDiags.
This provides some benefits:
- Allows us to plug in much more specific diagnostics for the existing "only has
mutating members" diagnostic, including producing notes for why the base expr
isn't mutable (see e.g. test/Sema/immutability.swift diffs).
- Corrects issues where we'd drop full decl name info for selector references.
- Wordsmiths diagnostics to not complain about "values of type Foo.Type" instead
complaining about "type Foo"
- Where before we would diagnose all failures with "has no member named", we now
distinguish between when there is no member, and when you can't use it. When you
can't use it, you get a vauge "cannot use it" diagnostic, but...
- This provides an infrastructure for diagnosing other kinds of problems (e.g.
trying to use a private member or a static member from an instance).
- Improves a number of cases where failed type member constraints would produce uglier
diagnostics than a different constraint failure would.
- Resolves a number of rdars, e.g. (and probably others):
<rdar://problem/20294245> QoI: Error message mentions value rather than key for subscript
Swift SVN r30715
get the same wording, fixing <rdar://problem/21964599> Different diagnostics for the same issue
While I'm in the area, remove some dead code.
Swift SVN r30713
This was supposed to prevent crashes, but it ended up /causing/ crashes
because we may hit a fatal Clang error /while/ importing Clang modules
and bridging headers.
I left the test on the logic that imports bridging headers because that
happens under more controlled circumstances. (Clang modules that have
Swift counterparts should never have bridging headers.)
rdar://problem/21689014
Swift SVN r30512
This is a hack to work around two issues:
- <iso646.h>, which defines macros for "and", "or", and "not" (among other
things) is an implicit submodule of Darwin.
- Macros even in explicit submodules are leaking out when the parent module
is imported <rdar://problem/14870036>.
There's no actual reason to require <iso646.h> in SDK header files -- it
should be a user-level choice whether or not to use those names. And
selectors with "and", "or", and "not" in them should not be mangled by this.
So, as a hack, we define the header guards that <iso646.h> uses ahead of
time, so that the file will be ignored. We do this for /both/ variants of
<iso646.h> on our system (Clang's and /usr/include's) just to be safe.
<rdar://problem/17110619>
Swift SVN r19822
