Specifically:
1. I removed an extra defensive copy that we put in place some time ago that
isn't really warranted. We know that we have an @owned value, so can safely just
pass the value as a @guaranteed parameter. This also eliminates an ownership
error that would occur due to my not having updated this code for ownership in
tree.
2. I also ensured that if we are performing a loadable address bridging cast ->
value bridging cast that we store the loadable value back into memory after we
perform the cast. Otherwise, it appears to leak to the ownership verifier.
I also centralized the non-ownership tests for this into one place
(const_fold_objc_bridge.sil => constant_propagation_objc.sil).
Previously the module interface printing would scrape the
AvailableAttrs from the containing decl in order to print synthesized
extensions for conformances that wouldn't otherwise be printed...but
that missed the case where a containing lexical scope had the
availability attributes instead. Now it walks up the chain of parent
DeclContexts and collects the most specific AvailableAttr for each
platform.
This /still/ isn't formally correct because it doesn't merge
availability for one platform (if something inside is deprecated
unconditionally but outside has an "introduced" version), but it's
going to match the vast majority of code out there.
Pre-requisite for rdar://problem/50100142
This has been an unnecessary code path for a long time now and should be removed particularly because it triggers wasteful `stat` calls.
rdar://51523161
```
@#^COMPLETE^#
public func something() {}
```
In this case, we can't say the user is adding attribute to the func or
starting a new declaration. So if there're one or more blank lines after the
completion, suggest context free attribute list.
rdar://problem/50441643
...specifically, diagnosed in the parent DiagnosticEngine. This not
only provides a better user experience, but makes sure that the
compiler exits with a nonzero exit code even if the module goes
unused.
rdar://problem/50789839
NOTE: I used YAMLIO to simplify dumping this information which required me to
use llvm::outs() instead of std::cout like the rest of libReflection. We really
should remove std::cout from libReflection (iostream is a smell we try to avoid
generally). As a result, there is a little bit of finagling in the commit to
work around flushing issues with respect to use llvm::outs(), std::cout... but
it isn't too bad overall.
That is, if they appear inside a larger type, they may need to be
parenthesized. ASTPrinter is careful about this already, so this
doesn't actually change any existing behavior, but it makes the
default more conservative when no PrintOptions are in play.
There's no way to spell an opaque type in a cast, and that means
there's no way to force the conversion today (even if you know the
types are dynamically the same).
Part of rdar://problem/50346954
The reason why I am doing this is so that I can create an adaptor class
(templated on Runtime) for reading protocol info from ReflectionInfo without
having to make ReflectionInfo itself generic. If ReflectionInfo becomes generic
on Runtime, it will cause a cascading need to mark classes in Reflection as
generic as well.
From talking with JoeG, this is due to historically RelativeDirectPointer not
having been ripped out of the runtime when this was written. This works now, so
it makes sense to change it. In terms of my goals, I want to use this to make it
easier to dump the names of protocols.
When deserializing an opaque type xref inside an extension context, we were looking
incorrectly in the base module of the type being extended, rather than in the module
of the extension, where the opaque type would really be. Fixes rdar://problem/51775500.
This includes a small refactoring of OpaqueTypeDecl deserialization to break the inevitable
cycle between deserializing the namingDecl, and the namingDecl turning around and re-
deserializing its opaque return type. This is NFC but avoids some unnecessary work.
We don't need to serialize the protocol's superclass, we can compute it from the
generic signature. Previously, we would drop the superclass while
serializing because we didn't check the generic signature in
SuperclassTypeRequest, which would cause us to cache `NULL` when we
called `setSuperclass` for a protocol with a superclass constraint.
Fixes rdar://50526401
We could invent a meaning for this in the future (such as having it be sugar for an unnamed
associated type), but for now raise an error with a fixit. rdar://problem/50678247
Otherwise, there's no guarantee of binary compatibility, and whoever
turned on library evolution support shouldn't be lulled into a false
sense of security.
This is just a warning for now, but will be promoted to an error later
once clients have shaken out any places where they're doing this.
Note that the still-experimental '@_implementationOnly' opts out of
this check, because that enforces that the import doesn't make its way
into the current module's public source or binary interface.
rdar://50261171
When an @_implementationOnly import includes Objective-C categories
for existing types, it's useful to be able to override the members
provided in those categories without exposing them to clients of the
framework being built. Allow this as long as the overriding
declaration is marked as @_implementationOnly itself, with an
additional check that the type of the declaration does not change.
(Normally overrides are allowed to change in covariant ways.)
Part of rdar://50827914
