Address an annoying source compatibility issue with the introduction
of Data.withUnsafeBytes, which is ambiguous with Swift NIO's
implementatio of the same function. Do so with a narrow hackish name
shadowing rule (the Swift NIO version shadows the Foundation version)
that we will eventually generalize to something sensible.
Fixes rdar://problem/46850346.
Narrow the recently-introduced shadowing rule for types so that it only
applies to non-member types. Member types lack a reasonable syntax for
specifying precisely which module to look into, and there are a few use
cases where the type checker will pick a type that would be shadowed by
the new rule.
Fixes a source-compatibility regression introduced by the shadowing rule.
Tweak the shadowing rules in two ways:
1) For unqualified type lookup, apply shadowing rules. Without this, we
would always get an ambiguity if there were two types with the same name,
so this should be a strict improvement.
2) Allow a name introduced in any other module to shadow a name in the
Swift standard library. This is (another) weak form of a more sensible,
generalized rule that would use the import graph to describe shadowing.
Together, these tweaks allow the Result type that was recently introduced in
the standard library to exist without breaking source compatibility for
Swift code that is already using a Result type. The user Result type will
shadow (hide) the Swift one. The latter can be spelled Swift.Result if it
is needed by such code.
Fixes rdar://problem/46767892.
GenericParamList::OuterParameters would mirror the nesting structure
of generic DeclContexts. This resulted in redundant code and caused
unnecessary complications for extensions and protocols, whose
GenericParamLists are constructed after parse time.
Instead, lets only use OuterParameters to link together the multiple
parameter lists of a single extension, or parameter lists in SIL
functions.
AST/LookupVisibleDecls.cpp has a dependency on swiftSema by having doGlobalExtensionLookup call into swift::isExtensionApplied,
and doGlobalExtensionLookup is ultimately used by the other global functions in that file.
Break the cycle by moving the file into the swiftSema library.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Associated type inference can synthesize type aliases with the same name
as a generic parameter. This is all fine since the underlying type of
the alias is the generic parameter type, however it might have been
synthesized in a constrained extension, resulting in bogus diagnostics
that depend on the order in which declarations are type checked, which
can vary between WMO and non-WMO, different batch mode settings, etc.
Instead, let's just check the generic parameter list first.
Fixes <rdar://problem/22587551>, <rdar://problem/44777661>.
These two declarations are now equivalent:
protocol P : SomeClass { ... }
protocol P where Self : SomeClass { ... }
There's a long, complicated story here:
- Swift 4.2 rejected classes in the inheritance clause of a
protocol, but it accepted the 'where' clause form, even
though it didn't always work and would sometimes crash
- Recently we got the inheritance clause form working, and
added a diagnostic to ban the 'where' clause form, because
we thought it would simplify name lookup to not have to
consider the 'where' clause
- However, we already had to support looking at the 'where'
clause from name lookup anyway, because you could write
extension P where Self : SomeClass { ... }
- It turns out that despite the crashes, protocols with
'Self' constraints were already common enough that it was
worth supporting the existing behavior, instead of banning
it
Fixes <rdar://problem/43028442>.
Previously you could pass in a vector of TypeDecls and it handled
module and AnyObject lookup for you. The AnyObject case was never
used and the module was was only needed in one place, so clean
things up to make them more direct here.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
When we're marking a declaration as @objc and recording it in the
class and source-file lookup tables (for @objc collision detection),
don't cause a cycle by querying `getObjCSelector()`. This is somewhat
of a hack: a better long-term approach would be to move the recording
much later, and request'ify the name computation. That'll be follow-up
work.
We weren’t getting anything out of the check for the extended nominal
declaration of an extension within unqualified name lookup except
some spurious cycles in the request-evaluator. Stop doing this.
Our walk over the requirement interface types meant that
computing the access level of an extension member depended
on type resolution and the GSB.
Fix this by adding a new request that simply collects all
TypeDecls referenced from a TypeRepr, and compute the
extension's maximum access level using that.
If we use Structural rather than Interface type resolution when
walking the extension's requirements, we don't have to build its
generic signature first.
