Skip to content

[pull] swiftwasm from main #2988

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 38 commits into from
Apr 16, 2021
Merged

[pull] swiftwasm from main #2988

merged 38 commits into from
Apr 16, 2021

Conversation

pull[bot]
Copy link

@pull pull bot commented Apr 16, 2021

See Commits and Changes for more details.


Created by pull[bot]

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

beccadax and others added 30 commits March 25, 2021 16:02
This commit fixes two weird bugs in -verify mode:

1. SourceLocs from the wrong SourceManager could be passed through a ForwardingDiagnosticConsumer into the DiagnosticVerifier.

2. -verify-additional-file did not error out correctly when the file couldn’t be opened.

No tests, as we only have basic tests for the diagnostic verifier.
Previously, when the standard library module interface was broken, Swift would try to rebuild it repeatedly during -compile-module-from-interface jobs because `ASTContext::getStdlibModule()` would try to load the standard library again each time it was called. This led to extremely slow compilations that repeatedly emitted the same errors.

To avoid this, we make ModuleInterfaceBuilder try to load the standard library right away and bail out if it can’t.

Fixes rdar://75669548.
Restrict filtering in `simplifyAppliedOverloadsImpl` to disable
overload set for operators only, because other calls e.g. regular
functions or subscripts could be filtered on labels and are less
overloaded.

Filtering non-operator calls could also lead to incorrect diagnostics
because first choice could have all sorts of different issues e.g.
incorrect labels and number of parameters.

Resolves: rdar://55369704
…can query

We must reset option occurences on each individual query because when an instance of the scanning tool is re-used in different contexts/different scans, we will be creating multiple compilation instances and re-parsing various (potentially-repeating) arguments.

Resolves rdar://75247030
Make sure it is properly treated as a SingleValueInstruction, and
don't blatantly read freed memory in the LowerHopToExecutor pass.
…pletion

The diagnosticc engine is keeping track of state which might modify parsing/typechecking behaviour. In the added test case the `fatalErrorOccurred` flag was during the first completion. The flag was still `true` for the second completion, causing parsing/typechecking to behave slightly differently. Because of this, the ExprRewriter failed when applying a constraint system solution, not properly cleaning up its `ExprStack`.

This PR tackles both issues:
1) Reset the `hadError` flags in the diagnostics engine
2) Clean up the `ExprRewriter`’s `ExprStack` when rewriting a target fails.

Either of these changes fixes the crash in the test case but I think both could manifest through different code paths in different scenarios.

Fixes rdar://76051976 [SR-14430]
…ArgParse

[Dependency Scanning] Reset LLVM option occurences for each libSwiftScan query
There's a basic prolog emission function, used by value and class constructors, etc, and then there's the full-blown one for functions and closures, which uses the basic version.
implicit calls to an async super.init are not allowed
types correctly hop to the right global-actor in their
prolog.
new phrasing in the error messages to match up with
other phrasing used in messages.
[Diagnostics] Filter operators if all their arguments are holes
[CodeCompletion] Reset diagnostics when reusing an ASTContext for completion
Preload standard library in ModuleInterfaceBuilder
…fix-32-bit

[Concurrency] Fix Dispatch linkage offset on 32-bit.
…ng the

enclosing-self subscript, infer availability from accessors on the subscript
declaration.
…6910)

This is meant to support scenarios in which we need to build as little as
LLVM as possible for performance reasons (e.g. when enabling LTO).

While LLVM CMake build system offers options in this sense,
in our investigation they turned out not to be suitable,
since either they are not granular enough (`LLVM_INCLUDE/BUILD` flags)
or they require active opt out for any new tool added
(`*_BUILD_*_TOOL` flags)

When using this mechanism, there is the possibility to specify different
targets to use for cross-compile hosts.

Supports rdar://32019390
…-by-default-take-2

Enable import of the _Concurrency module by default.
swift-ci and others added 4 commits April 15, 2021 14:27
…Gen/partial_apply_run_generic_method1.sil
The start and end lines were only used while constructing the comments,
so move the line tracking into that method instead of storing it in each
comment.
hborla and others added 4 commits April 15, 2021 19:52
…nostics

[ConstraintSystem] Fix a few diagnostic bugs for inferred property wrapper types.
[Gardening] Do not store start/end line in SingleRawComment
…ility

[Property Wrappers] Fix availability inference for enclosing self property wrappers.
…message

ModuleInterfaceBuilder: give a more specific error message in case of a compiler mismatch
@MaxDesiatov MaxDesiatov enabled auto-merge April 16, 2021 09:46
@MaxDesiatov MaxDesiatov merged commit 3db2940 into swiftwasm Apr 16, 2021
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.