This operator++ is a post-increment operator but it was implemented with pre-increment behavior.
This bug was exposed by the changes in llvm r294339 and caused the master-next branch to stop
building.
This essentially undoes the implementation in 51da51dfc0, which
implicitly did a substitution of the Self type in a protocol's
requirement signature by threading around the replacement PA. This is
brittle because every part of the code needs to take and pass around the
argument. By preemptively substituting, the whole requirement is in the
right form from the time it enters `addRequirement`.
The infrastructure here also allows simplifying some code.
Extensive cross-language tooling support needs to bridge decl names between two different languages more freely. This SourceKit request is designed to translate Objc names to Swift names and vice versa. Working similarly to cursor-info requisition, the name translation request requires a Swift reference to a Swift/Clang decl, and the preferred name to translate from, and language kind that the given name belongs to. If the translation succeeds, SourceKit service responds with the corresponding name than belongs to the other kind of language.
Newly introduced keys:
“key.namekind": “source.lang.name.kind.objc” | "source.lang.name.kind.swift"
“key.basename”: “name"
“key.argnames”: [“name"]
“key.selectorpieces”: [“name[:]"]
This commit only implements translation from Objc to Swift.
Instead of a global demangleSymbolAsNode, which returns a reference-counted NodePointer, there is now a Context class which owns the nodes.
So now demangleSymbolAsNode is a member of Context and the returned NodePointer is alive as long as the Context is alive.
This is still a NFC: the new ABI still maps to the old functions.
The purpose of this change is to let lldb adapt to the new API and then we can switch to the new implementation.
It is now possible to check for any apply if it can be devirtualized without actually performing the deirtualization. This could be used e.g. by inlining heuristics.
Remove the pre-expansion of all of the archetypes in a generic
environment; they can be constructed lazily from interface types.
Note that this only concerns the construction of the archetypes
themselves. The archetype builder is still pre-expanding all
*potential* archetypes.
"Fixes" rdar://problem/30351514, in the sense that the eager code and
the assertion that was getting tripped up are being eliminated
completely.
Rather than serializing the complete structure of all archetypes
(which is completely redundant), serialize a reference to their owning
generic environment as well as their interface type. The archetype
itself will be reconsituted by mapping the interface type into that
generic environment.
This just moves a bunch of queries that used information on SILFunction to
determine this property to just call a helper on SILFunctionType itself.
Centralized logic is good.
rdar://29791263
If the nested type itself has generic constraints, we would
hit an assertion in requirement inference. Refactor some code
so that we can make the assertion more accurate.
Fixes <rdar://problem/30353095>.
There is already precedence for doing this via DominanceInfo. The reason I am
doing this is that I need the ownership verifier to be able to be run in Raw SIL
before no return folding has run. This means I need to be able to ignore
unreachable code resulting from SILGen not inserting unreachables after no
return functions.
The reason why SILGen does this is to preserve the source information of the
unreachable code so that we can emit nice errors about unreachable code.
rdar://29791263
This caused a crasher when running the ownership verifier. I don't have a test
case right now, since it happened several weeks ago.
The bug can not happen again since I eliminated the nullptr default argument.
rdar://29791263
Previously, these were only diagnosed in some situations, but the
compiler is becoming more flexible about when things get fed into
different places, and so can crop up elsewhere.
The correct/canonical ConcreteType and ConcreteTypeSource are both
stored in the Representative, but previously only the getter for the
former was tranversing the chain.
