There are multiple ways in which the Clang importer can produce an
initializer, and we have existing name shadowing rules to decide on
the best. Extend those rules to cover the case where a
Clang-importer-synthesized initializer collides with a C function
imported as an initializer. There's technically no reason to do the
latter because the former already exists, but some frameworks
currently depend on this.
Prior to this, the constraint solver was preferring the synthesized
initializer already (which is the right thing to do), for the wrong
reasons.
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
