Skip to content

Resolve conflicts with upstream main #3901

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 25 commits into from
Nov 29, 2021
Merged

Resolve conflicts with upstream main #3901

merged 25 commits into from
Nov 29, 2021

Conversation

MaxDesiatov
Copy link

No description provided.

beccadax and others added 25 commits November 19, 2021 11:34
This is not yet used by anything.
This change applies SwiftAttr attributes as soon as possible after creating an instance of a Decl, rather than waiting until the declaration is "finished". That makes sure the attributes can influence the declaration very early in its lifecycle, and in particular, before its conformance table is initialized.

Mostly NFC in this commit (other than affecting the order that attributes are printed in), but necessary for future changes in this PR.
...by using `__attribute__((swift_attr("@sendable")))`. `@_nonSendable` will "beat" `@Sendable`, while `@_nonSendable(_assumed)` will not.

This commit also checks if `SwiftAttr` supports `#pragma clang attribute` and, if it does, defines `__SWIFT_ATTR_SUPPORTS_SENDABLE_DECLS` in imported headers so they know they can apply these attributes in an auditing style.
Gives us a place to stuff synthesized declarations for, among other things, imported Clang decls.
An explicit swift_attr("@_nonSendable") will override it (except for ns_error_domain where the type is embedded in another type that's forced to be Sendable), but swift_attr("@_nonSendable(_assumed)") will not.
Move this into a helper function that lives in Sema, avoiding libswiftAST calling into libswiftSema.
This enables the new _StringProcessing module on Windows which was
accidentally excluded from the build in swiftlang#40240.
This allows the compiler to parse the Swift swiftinterface file of a recent SDK.
The negative test, which requires that the optimization is not done with an old swift runtime, must run on macos/x86_64.
Other platforms don't necessarily have old runtimes.

rdar://85519651
Unfortunately using the convenient "bootstrapping0-all", etc. custom targets does not work.
For some reason it does not cause a dependent file (like libswift's SIL.o) being rebuilt when a depenency (like swift-frontend from the previous bootstrapping stage) changes.
Instead we have to list al library- and executable-targets explicitly.
Otherwise dynamic metadata/conformance lookup does not work.
Use the include search path for the header search rather than
constructing the path using relative paths.  This is important for
getting the interop to work properly as well.
The toolchain has traditionally been buildable with clang, cl (MSVC),
and gcc.  `__has_feature` is a clang-specific directive, ensure that we
are portable to other compilers by providing a definition of the macro
incase it is not available (which also includes older clang releases).
SILOptimizer: avoid trawling through the directories for includes
…-one

SIL: support non-clang compilers again
utils: update windows builders to include string processing
…commit

[Re-merge] Support __available__((swift_attr("@sendable")))
tests: fix the immortal-arc-elimination.swift test
# Conflicts:
#	lib/ClangImporter/ClangImporter.cpp
@MaxDesiatov MaxDesiatov marked this pull request as ready for review November 29, 2021 16:10
@MaxDesiatov MaxDesiatov requested a review from a team November 29, 2021 16:10
@MaxDesiatov MaxDesiatov merged commit 5404469 into swiftwasm Nov 29, 2021
@MaxDesiatov MaxDesiatov deleted the maxd/main-merge branch November 29, 2021 17:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants