Skip to content

[pull] swiftwasm from swift/main #1094

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 10,000 commits into from
Feb 3, 2021
Merged

[pull] swiftwasm from swift/main #1094

merged 10,000 commits into from
Feb 3, 2021

Conversation

pull[bot]
Copy link

@pull pull bot commented Feb 2, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

git apple-llvm automerger and others added 30 commits January 7, 2021 09:03
…tion attribute id changes

When introducing support for @llvm.experimental.noalias.scope.decl, this tests started failing because it checks
(for no good reason) for a function attribute id of '#8' which now becomes '#9'

Reviewed By: pratlucas

Differential Revision: https://reviews.llvm.org/D94233
fix typo under include and lib directories

Reviewed By: antiagainst

Differential Revision: https://reviews.llvm.org/D94220
Remove continuation line in code snippet to prevent GCC warning about
multiline comments (-Wcomment) when building a project using libclang
with GCC.

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D92409
As shown by bug 48540, GCC vector types would cause a crash when the
declaration hada ParenType. This was because the walking of the
declaration would try to expand the 'inner' type, but there was no
ability to get it from the vector type.  This patch adds that element
type access to the vector type loc objects.

Differential Revision: https://reviews.llvm.org/D93483
…m-LLDBMemoryReader-readString-rebranch

[lldb] Optimize target read from LLDBMemoryReader::readString
(cherry picked from commit 0627fa3)
LLDBTypeInfoProvider only requires a TypeSystemSwift.

(cherry picked from commit e27eeeb)
This does the exact same amount of locking as the previous version,
it's just slightly more efficient to use ForEach().

(cherry picked from commit 88c0bf6)
and SwiftLanguageRuntimeImpl::ModulesDidLoad()

SetupABIBit() iterates of the Target's images and thus needs to
acquire that ModuleList's lock. We need to acquire this before
locking m_add_module_mutex, since ModulesDidLoad can also be
called from a place where that lock is already held:
+   lldb_private::DynamicLoaderDarwin::AddModulesUsingImageInfos()
+     lldb_private::ModuleList::AppendIfNeeded()
+       lldb_private::Target::NotifyModuleAdded()
+         lldb_private::Target::ModulesDidLoad()

rdar://72858062
(cherry picked from commit 6a79a97)
There is only one lock per target (not per lldb::Module) so that comment was incorrect.

rdar://67587895
(cherry picked from commit 6f69f18)
…s-only-when-verbose-rebranch

[lldb] Log MemoryReader messages only when verbose
 - Remove unused plists that were referenced (but unused) by Xcode.
 - Move all debugserver plists unders tools/debugserver/resources.
 - Add the ability to distinguish between com.apple.security.cs.debugger
   and com.apple.private.cs.debugger.

rdar://66082043

Differential revision: https://reviews.llvm.org/D94320

(cherry picked from commit 2723551)
git apple-llvm automerger and others added 27 commits January 28, 2021 20:15
This type is used as an aggregate, i.e. it has no member functions.
Starting with C++20 types with deleted default constructors are not
aggregate types anymore which means that aggregate initialization will
not work for this class anymore. This leads to a compile error in
clang::AnalyzerOptions::getDiagOpts() for example.

Also set the boolean flags to false by default to avoid undefined
behavior. Previously this was prevented by deleting the default
constructor, now we explicitly initialize them.

Differential Revision: https://reviews.llvm.org/D92221

(cherry picked from commit e16959c)
NamedDecl::getName() was being called on a constructor.
(cherry picked from commit c435567)
Replace cast_or_null<> with cast<> as we immediately dereference the pointer afterward so we're not expecting a null pointer.

(cherry picked from commit 879c12d)
…cs".

Currently only used by MoveChecker but ideally all checkers
should have reusable categories.

(cherry picked from commit 3e206a5)
Drop redundant "found", specify what exactly is wrong with side effects
in assert conditions.

Differential Revision: https://reviews.llvm.org/D95515

(cherry picked from commit ec81289)
NSAssert and NSCAssert are Objective-C Foundation's standard assert macros.

Differential Revision: https://reviews.llvm.org/D95519

(cherry picked from commit b92a39a)
This is a drive-by fix of something that's obviously wrong, but I
don't have a testcase for it yet.
[lldb/test] Xfail TestSwiftBenchmarkOnone.1.test
This patch fixes updating MemorySSA if the header contains memory
defs that do not clobber a duplicated instruction. We need to find the
first defining access outside the loop body and use that as defining
access of the duplicated instruction.

This fixes a crash caused by bee4868.
If we determine that the invariant path through the loop has no effects,
we can directly branch to the exit block, instead to unswitching first.

Besides avoiding some extra work (unswitching first, then deleting the
loop again) this allows to be more aggressive than regular unswitching
with respect to cost-modeling. This approach should always be be
desirable.

This is similar in spirit to D93734, just that it uses the previously
added checks for loop-unswitching.

I tried to add the required no-op checks from scratch, as we only check
a subset of the loop. There is potential to unify the checks with
LoopDeletion, at the cost of adding a predicate whether a block should
be considered.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D95468
Attempt to fix some compiler warnings on some bots after
b8c81fa.
Swift's new concurrency features are going to require guaranteed tail calls so
that they don't consume excessive amounts of stack space. This would normally
mean "tailcc", but there are also Swift-specific ABI desires that don't
naturally go along with "tailcc" so this adds another calling convention that's
the combination of "swiftcc" and "tailcc".

Support is added for AArch64 and X86 for now.
IR/AArch64/X86: add "swifttailcc" calling convention.
GlobalISel: check type size before getZExtValue()ing it.
@pull pull bot added ⤵️ Upstream Tracking merge-conflict Resolve conflicts manually labels Feb 2, 2021
@kateinoigakukun kateinoigakukun merged commit 043dc5c into swiftwasm Feb 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.