[pull] swiftwasm-host from master #14
Merged
Conversation
This file contains 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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
The PassManager should transform all functions in bottom up order. This is necessary because when optimizations like inlining looks at the callee function bodies to compute profitability, the callee functions should have already undergone optimizations to get better profitability estimates. The PassManager builds its function worklist based on bottom up order on initialization. However, newly created SILFunctions due to specialization etc, are simply appended to the function worklist. This can cause us to make bad inlining decisions due to inaccurate profitability estimates. This change now updates the function worklist such that, all the callees of the newly added SILFunction are proccessed before it by the PassManager. Fixes rdar://52202680
Fixes <rdar://problem/63188053>.
State explicitly that we want to eliminate all differences between `apple/master` and `llvm.org/master`. All new LLVM development should happen upstream.
… init
Diagnose an attempt to initialize raw representable type or convert to it
a value of some other type that matches its `RawValue` type.
```swift
enum E : Int {
case a, b, c
}
let _: E = 0
```
`0` has to be wrapped into `E(rawValue: 0)` and either defaulted via `??` or
force unwrapped to constitute a valid binding.
…table` Do the verification during constraint repair and provide fix itself with raw representative type and its raw value to be used for diagnostics.
Clang provides options to override that default value. These options are accessible via the -Xcc flag. Some Swift functions explicitly disable the frame pointer. The clang options will not override those.
…alization This makes logic in `ContextualFailure::tryRawRepresentableFixIts` partially obsolete.
…struction Since both raw representable and value types originated in constraint system they can have type variables which need to be resolved before types could be used in a diagnostic and fix-it.
Add additional clarification that submitting to `swift/master-next` continues to be allowed.
…ontruct raw representable Introduce `repairByExplicitRawRepresentativeUse` which is used for assignment, argument-to-parameter conversions and contextual mismatches. It checks whether `to` side is a raw representable type and tries to match `from` side to its `rawValue`.
…RawRepresentableFixIts`
…into `AbstractRawRepresentableFailure`
…instead of its raw value
Diagnose an attempt to pass raw representable type where its raw value
is expected instead.
```swift
enum E : Int {
case one = 1
}
let _: Int = E.one
```
`E.one` has to use `.rawValue` to match `Int` expected by pattern binding.
rdar://problem/58687608
from NamingPatternRequest.
to 'typeCheckAbstractFunctionBodyNodeAt()' because that only typecheck a statement at the position.
…e initializers. The Original Bug ---------------- In ffbfcfa, we fixed a bug around implicit value initializers but did not cherry-pick it to 5.3. While investigating a bug that turned out to be that same bug (no worries!), I noticed that there is additional code that is "unsafely" correct in this area and that while ffbfcfa is correct in the small, we can expand on the fix to prevent future bugs. The Larger Bug -------------- Here we are still open coding using ManagedValue/Cleanup APIs /without/ a top level function scope. The code is only correct since we never emit unconditional cleanups and always manually forward conditional cleanups. If we did not do either of these things, we would have another instance of this bug, namely a cleanup that is never actually emitted. So the code on master today is correct, albeit unsafe, and we already have coverage for this (namely the test case from ffbfcfa). That being said, in general when working with ManagedValue APIs (especially in utility functions) we assume that we have a scope already created for us by our caller. So by fixing this issue we are standardizing to safer SILGen invariants. Building on ffbfcfa ---------------------------------------------------- This commit builds on the shoulders of ffbfcfa by adding the function level scope mentioned in the previous section so that we are now "safely" correct. While looking at this I also realized that just using a normal scope when open coding here may be a bit bugprone for open coding situations like this since: 1. If one just creates a scope in open coding situations, the scope will fire at end of the c++ function /after/ one has probably emitted a return. 2. Once one has emitted the return, the insertion point will no longer be set implying =><=. To avoid this, I created a move only composition type on top of Scope called AssertingManualScope. This type just asserts in its destructor if the scope it contains has not been popped yet. While, one can pop it by ones self, I added an overload of createReturnInst on SILGenBuilder that also takes an AssertingManualScope and pops it at the appropriate time. So now when performing simple open coding tasks, we have the ability to in code tie together the function level scope to the actual creation of return inst, simulating the hand-off of lifetimes/resources from caller/callee that often happens in the epilog of functions. <rdar://problem/63189210>
Rather than trying to continue the compilation with an empty main module, let's bail out early if we expect an implicit stdlib import and fail to load in the stdlib.
This part of a series of patches to bring ASTPrinter and Swift Demangler to feature parity, which is needed by LLDB, which depends on using the strings produced by either interchangibly. <rdar://problem/63700540>
This part of a series of patches to bring ASTPrinter and Swift Demangler to feature parity, which is needed by LLDB, which depends on using the strings produced by either interchangibly. rdar://problem/63700540
This is analogous to ASTPrinter's FullyQualifiedTypesIfAmbiguous option. This part of a series of patches to bring ASTPrinter and Swift Demangler to feature parity, which is needed by LLDB, which depends on using the strings produced by either interchangibly. rdar://problem/63700540
This part of a series of patches to bring ASTPrinter and Swift Demangler to feature parity, which is needed by LLDB, which depends on using the strings produced by either interchangibly. rdar://problem/63700540
… getenv when possible. There are a few environment variables used to enable debugging options in the runtime, and we'll likely add more over time. These are implemented with scattered getenv() calls at the point of use. This is inefficient, as most/all OSes have to do a linear scan of the environment for each call. It's also not discoverable, since the only way to find these variables is to inspect the source. This commit places all of these variables in a central location. stdlib/public/runtime/EnvironmentVariables.def defines all of the debug variables including their name, type, default value, and a help string. On OSes which make an `environ` array available, the entire array is scanned in a single pass the first time any debug variable is requested. By quickly rejecting variables that do not start with `SWIFT_`, we optimize for the common case where no debug variables are set. We also have a fallback to repeated `getenv()` calls when a full scan is not possible. Setting `SWIFT_HELP=YES` will print out all available debug variables along with a brief description of what they do.
The host platform should be using `CMAKE_SYSTEM_NAME STREQUAL Darwin`. However, we currently drive the host side of the compilation against custom variables. This makes the migration simpler by ensuring that the entire file uses the same pattern. Since `is_darwin_based_sdk` is now used only in the standard library build, sink it to the standard library build.
`classMetadata` is only used in the ObjC path, resulting in a `-Wunused-variable` warning. Sink the variable into the ObjC path. Because the conversion of the metadata does not rely on the type metadata bits in the metadata, it is safe to delay the definition and bit adjustment to the point where it is used unifying the two ObjC paths.
…resLinkPthread [stdlib][cmake] OpenBSD target requires -lpthread.
SIL: Verify kinds of vtable entries.
…wiftlang#32133) * Add note that LLDB changes should be cherry-picked to `swift/master` * New Swift-dependent commits should go to `swift/master`, not `swift/master-next`. * Update naming scheme for release branches * Fix indentation
…wiftlang#32181) This reverts commit f7473a7.
…closure-cleanup [AST] Clean up handling of single-expression closures
…8390-inherit-availability [SymbolGraph] Inherit availability from parent contexts
ABI: qualify use of `StringRef` and `Optional` (NFC)
[NFC] AST: Optimize GenericSignatureImpl::getInnermostGenericParams
…03c93f1ba6ac111c52d1157 [semantic-arc-opts] Teach semantic-arc-opts how to handle structs with multiple non-trivial values.
[CSGen] Allow `is` patterns to infer type from enclosing context
runtime: silence -Wunused-variable warning (NFC)
…c54f4b3c46468e4706e7c80 [memory-lifetime] Teach the verifier that select_enum_addr doesn't write to memory.
…deScalarProperties Refactors internal func _applyMapping using _FixedArray16
…iables [Runtime] Unify debug variable parsing from the environment and avoid getenv when possible.
build: use the same pattern for detecting Darwin platforms
Inline the standard headers that they included and remove the extra include path.
Cache empty member list so that 'IterableDeclContext::loadAllMembers()' doesn't perform delayed member parsing. Fixes: rdar://problem/63921896
…declbraces-rdar63921896 [Parse] Avoid delayed member parsing for type decl with missing brace
runtime: remove `llvm/DataTypes.h`, `llvm-c/DataTypes.h`
…ype-of-opaque-type ASTDemangler: Add support for member types of opaque result types
…ssion-tests A couple of regression tests
Add a test to verify that C++ out-of-line operator functions are imported correctly. Includes fixes for armv7 and arm64. This is part of addressing SR-12748.
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.
See Commits and Changes for more details.
Created by
pull[bot]. Want to support this open source service? Please star it : )