instead of the pre-typechecked type and the referenced decl in the AST
so that we can suggests all overloads even if it happen to be
typechecked to a method. For example
struct MyType {
func foo() {}
func foo(_ int: Int) {}
func foo(name: String, value: String) {}
}
func test(val: MyType) {
value.foo(#^COMPLETE^#)
}
In this case, the call is typechecked to 'MyType.foo(_:)', but we want
to suggest all overloads.
rdar://problem/59285399
Centralize part of the routine that selects which resources to free. Then, add an additional condition for -dump-api-path.
Before, if this option were specified along with -emit-llvm or -c, the compiler would try to rebuild the torn-down ModuleDecl and crash trying to access the torn-down ASTContext.
The only non-trivial bit is making the DiagnosticEngine parameter to swift::performLLVM required. No callers were taking advantage of this parameter allowing NULL.
The lifetime of the UnifiedStatsReporter was not entirely clear from context. Stick it in the CompilerInstance instead so it can live as long as the compile job.
It is critical that its lifetime be extended beyond that of the ASTContext, as the context may be torn down by the time code generation happens, but additional statistics are recorded during LLVM codegen.
There are a few interesting things here:
1. All of this code is conditionalized implicitly on ossa by us checking for
load [take]. If we are in non-ossa, then we will have unqualified loads and this
code path will be skipped. I left in the old test that made sure we did not
support this in non-ossa code for this purpose.
2. We treat the load [take] like a destroy_addr. Thus the current method of
providing safety via using lifetime analysis to show all "destroys" form a
minimal post-dominating set for the copy_addr.
3. We do not allow for load [take] on sub-element initializations. The reason
why is that SILGen initializes temporaries completely in memory and generally
destroys addresses completely as well. Given that is the pattern we are looking
for, we just reduce the state space by banning this pattern.
4. If we have a copy_addr [init], then we not only change the load [take] to
have the original source address as an argument, but we also change the load
[take] to a load [copy] so we don't lose the +1. Additionally, we have to hoist
the load [copy] to the copy_addr [init] site to ensure that we do not insert a
use-after-free from the retain happening too late.
I am doing this to clean up some simple temp rvalue patterns in SIL before
semantic arc opts runs. This ensures that we are more likely to have a load
operation come from a more meaningful semantic entity (for instance a let field
of a guaranteed class) and thus allow us to convert a load [copy] to a
load_borrow.
I am also going to add support in subsequent commits for eliminating alloc_stack
that are stored into as well (another pattern I am seeing).
Instead of always opening argument type represented by a collection
without type variables (to support subtyping when element is a labeled tuple),
let's try original type first and if that fails use a slower path with
indirection which attempts `array upcast`. Doing it this way helps to
propagate contextual information faster which fixes a performance regression.
Resolves: rdar://problem/54580247
We have two similar code paths here that should probably be unified. For
now, make sure the more-specific one for pattern matching kicks in first.
Fixes rdar://problem/59838566.
This is something I noticed by inspection while working on
<https://bugs.swift.org/browse/SR-75>.
Inside a static method, 'self' is a metatype value, so
'self.instanceMethod' produces an unbound reference of type
(Self) -> (Args...) -> Results.
You might guess that 'super.instanceMethod' can similarly
be used to produce an unbound method reference that calls
the superclass method given any 'self' value, but unfortunately
it doesn't work.
Instead, 'super.instanceMethod' would produce the same
result as 'self.instanceMethod'. Maybe we can implement this
later, but for now, let's just diagnose the problem.
Note that partially-applied method references with 'super.'
-- namely, 'self.staticMethod' inside a static context, or
'self.instanceMethod' inside an instance context, continue
to work as before.
They have the type (Args...) -> Result; since the self value
has already been applied we don't hit the representational
issue.
Add the platform conditional and set up other basics for the toolchain.
The ConditionalCompilation tests are updated to match, since otherwise
they seem to trip when building on non-OpenBSD platforms. The
Driver/linker test is updated to ensure lld is passed on this platform.
Note that OpenBSD calls "x86_64" as "amd64", so we use that name for the
architecture instead of trying to alias one to the other, as this makes
things simpler.
I still need to investigate the failures.
To unblock CI I'm disabling the verification for now.
Failing to correctly remangle a symbol should work, but failing so will not cause any severe damage (miscompile, etc.) in most cases.
rdar://problem/59813007
rdar://problem/59496022
https://bugs.swift.org/browse/SR-12204
Otherwise, on the face of it we do not invalidate analyses as we should. That
being said, I do not think we actually could hit this in practice today since a
trivially dead instruction can only enter the worklist as a result of us
removing some sort of other instruction causing madeChange to be already true.
That being said, I would rather not rely on that in the face of future
change. Found via site reading code.
* Stage in #filePath
To give users of #file time to transition, we are first adding #filePath without changing #file’s behavior. This commit makes that change.
Fixes <rdar://problem/58586626>.
* Correct swiftinterface test line
