Skip to content

Conversation

MaxDesiatov
Copy link

Fix build issue after merging master, which was caused by static-stdlib-args.lnk handled differently upstream.

rintaro and others added 30 commits May 14, 2020 09:18
Since the closure is completely determined by the SILDeclRef,
we can centralize the emission logic in one place.
This mechanism is used for imported functions with bodies synthesized
by the ClangImporter, as well as on-demand accessors synthesized when
required for a protocol conformance (eg, a _read accessor, or a
_modify on a property whose opaque access pattern doesn't use a
_modify, such as an @objc dynamic property).

Previously this was intertwined with the 'delayed function' mechanism,
which is similar, but used for a different case -- implicit functions
inside the same translation unit.

Untangle these to allow further simplifications.
Enum element constructors are used when an enum element satisfies
a protocol requirement. Instead of emitting them as part of
emitGlobalFunctionRef(), let's sink it down to getFunction() where
we do all other on-demand function body emission.
…ror.

The static analyzer flags this as a nullptr dereference since FullApplySite::isa
can fail if given a non-ApplySite. Of course though, the SILInstruction is an
apply! We just created it! This commit helps the static analyzer by propagating
this type information by not downcasting our ApplyInst to SILInstruction and
then just use FullApplySite's ApplyInst constructor instead.
That helps when there is no context around a closure and parameters
used in the body are untyped.
…contextual couldn't be established

If closure is an argument to a call to a missing member or invalid
contextual member reference let's not diagnose problems related to
inability to infer parameter types because root issue is that context
for closure inference couldn't be established.
Holes couldn't be contracted instead solving of the constraint
has to be delayed until one of the sides is bound to a type,
otherwise there is a risk to loose contextual information.
…sure parameter(s)

Detect situation when it's impossible to determine types for
closure parameters used in the body from the context. E.g.
when a call closure is associated with refers to a missing
member.

```swift
struct S {
}

S.foo { a, b in } // `S` doesn't have static member `foo`

let _ = { v in } // not enough context to infer type of `v`

_ = .foo { v in } // base type for `.foo` couldn't be determined
```

Resolves: [SR-12815](https://bugs.swift.org/browse/SR-12815)
Resolves: rdar://problem/63230293
A malformed mangled name that ends in a truncated symbolic
reference could trigger a read beyond the end of the name.
This is because the code that grabs the next four bytes
bypasses the existing bounds checks.  Insert an explicit
bounds check to guard against this.
Some of the patterns in the new test header are special-cased by
ClangImporter (for example, the names of typedefs become names of
imported structs).

Nested structs have been historically imported in Swift according to C
rules, that is, structs lexically declared nested in other structs are
imported into the global namespace anyway. For the same reason, C
structs have been mangled in Swift names as if they are declared in the
global namespace. These rules are problematic when importing C++, see
https://bugs.swift.org/browse/SR-12803.
[ConstraintSystem] Detect and diagnose inability to infer type of closure parameter(s)
This adds a new copy of LLVMSupport into the runtime.  This is the final
step before changing the inline namespace for the runtime support.  This
will allow us to avoid the ODR violations from the header definitions of
LLVMSupport.

LLVMSupport forked at: 22492eead218ec91d349c8c50439880fbeacf2b7
Changes made to LLVMSupport from that revision:
  process.inc forward declares `_beginthreadex` due to compilation issues due to custom flag handling

API changes required that we alter the `Deallocate` routine to account
for the alignment.

This is a temporary state, meant to simplify the process.  We do not use
the entire LLVMSupport library and there is no value in keeping the
entire library.  Subsequent commits will prune the library to the needs
for the runtime.
This adds the `__swift::__runtime` inline namespace to the LLVMSupport
interfaces.  This avoids an ODR violation when LLVM and Swift are in the
same address space.  It also will aid in the process of pruning the
LLVMSupport library by ensuring that accidental leakage of the llvm
namespace does not allow us to remove symbols which we rely on.
Reduce LLVMSupport to the subset required for the runtime.  This reduces
the TCB and the overheads of the runtime.  The inline namespace's
preservation ensures that ODR violations do not occur.
Rather than invoke a bash script to generate the file, write the file
statically from CMake.  This allows us to cross-compile for platforms
which require the static library arguments on platforms which do not
have bash.
…8e463e234898c646c5e654a

[gardening] Propagate type info to silence static analyzer nullptr error.
I think this was just missed when I was enabling the ownership verifier. It
passes now without my doing anything.
performing a dynamic replacement

rdar://61936622
Opaque result type syntax is not usable except the declaration of
itself. In other places, users need to let them inferred. If they are
inferred associated type, they need to reffered by the name of the
associated type.

rdar://problem/59817674
Added tests for edge cases in importing and mangling C structs
compnerd and others added 21 commits May 15, 2020 12:53
runtime: ingest LLVMSupport into the runtime
…d-interface

ModuleInterface: reconstruct command-line arguments for building Swift module from interface explicitly
Simplify lazy function body emission in SILGen
…-arm64e

IRGen: "Simple" partial_apply still needs to re-sign the entry point pointer.
runtime: generate the link arguments in CMake
…Set.swift

Fix example snippets Set.swift
…on-space

Allow space after json key name. JSONEncoder has this (used by swift-driver)
…that are @objc.

This type of code can go down different code paths in SILGen/the optimizer. I
found a bug there that I am fixing now and so I decided to expand our code
coverage here.
…pe-elimination

[NFC] initAssociatedTypeWitness is now unused in non-ptrauth builds
…lude initializer expressions.

Catch any cleanups that get emitted while evaluating the initializer expression for a property.
Fixes rdar://problem/63187509.
…817674

[ASTPrinter] Don't print inferred opaque result type witness
…470999

[CodeCompletion] Add an already-fixed crashing test case
…e_result_type_parameter_dyn_repl

IRGen: Only replace opaque result types of function result types when performing a dynamic replacement
When adding a superclass constraint, we need to find any nested
types belonging to protocols that the superclass conforms to,
and introduce implicit same-type constraints between each nested
type and the corresponding type witness in the superclass's
conformance to that protocol.

Fixes <rdar://problem/39481178>, <https://bugs.swift.org/browse/SR-11232>.
…er-scope

SILGen: Extend scope for evaluation in memberwise initializers to include initializer expressions
…sted-type

GSB: Concretize nested types when adding a superclass constraint
@MaxDesiatov MaxDesiatov marked this pull request as ready for review May 16, 2020 20:15
@MaxDesiatov MaxDesiatov merged commit 1298bde into swiftwasm May 16, 2020
@MaxDesiatov MaxDesiatov deleted the maxd/master-merge branch May 16, 2020 20:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.