forked from swiftlang/swift
-
Notifications
You must be signed in to change notification settings - Fork 30
Fix build issue after merging master #1025
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rdar://problem/58470999
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.
…epresents a closure parameter type
…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.
…pointer. Fixes rdar://problem/63184042
…t module from interface explicitly
…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
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.
…f7c626b14c287cd5d28013c
…817674 [ASTPrinter] Don't print inferred opaque result type witness
…5bffb3b1f8b6109efc91acd
…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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix build issue after merging
master
, which was caused bystatic-stdlib-args.lnk
handled differently upstream.