profile
viewpoint
Nathan Hawes nathawes @apple Cupertino, CA

llvm/llvm-project 6355

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org.

nathawes/swift 1

The Swift Programming Language

nathawes/sourcekit-lsp 0

Language Server Protocol implementation for Swift and C-based languages

nathawes/swift-integration-tests 0

Automated tests for validating the generated Swift snapshots behave correctly

nathawes/swift-lldb 0

This is the version of LLDB that supports the Swift programming language & REPL.

nathawes/swift-package-manager 0

The Package Manager for the Swift Programming Language

nathawes/swift-source-compat-suite 0

The infrastructure and project index comprising the Swift source compatibility suite.

push eventnathawes/swift

Nathan Hawes

commit sha 15f5222bbdf357f3c23c12bd07434b64f4d2500a

[CodeCompletion][Sema] Allow missing args when solving if the completion location indicates the user may intend to write them later. func foo(a: Int, b: Int) {} func foo(a: String) {} // Int and String should both be valid, despite the missing argument for the // first overload since the second arg may just have not been written yet. foo(a: <complete here> func bar(a: (Int) -> ()) {} func bar(a: (String, Int) -> ()) {} // $0 being of type String should be valid, rather than just Int, since $1 may // just have not been written yet. bar { $0.<complete here> }

view details

push time in 6 days

pull request commentapple/swift

[Index] Don't report extensions with nothing to index

Looks great - thanks!

xymus

comment created time in 6 days

Pull request review commentapple/swift

[CodeCompletion][Sema] Allow missing args when solving if the completion location indicates the user may intend to write them later.

 class AllowClosureParamDestructuring final : public ConstraintFix {                                                 ConstraintLocator *locator); }; +struct SynthesizedArg {+  unsigned paramIdx;+  AnyFunctionType::Param param;+};+

This is no longer necessary (in my original changes it also tracked the index to insert the missing arg at) but I left it in for the slight readability improvement over a std::pair (e.g. paramIdx vs first)

nathawes

comment created time in 8 days

PullRequestReviewEvent

push eventnathawes/swift

Nathan Hawes

commit sha cd6f200fefa7342261da6181ec8c8ee71baba7bc

[CodeCompletion][Sema] Allow missing args when solving if the completion location indicates the user may intend to write them later. func foo(a: Int, b: Int) {} func foo(a: String) {} // Int and String should both be valid, despite the missing argument for the // first overload since the second arg may just have not been written yet. foo(a: <complete here> func bar(a: (Int) -> ()) {} func bar(a: (String, Int) -> ()) {} // $0 being of type String should be valid, rather than just Int, since $1 may // just have not been written yet. bar { $0.<complete here> }

view details

push time in 8 days

pull request commentapple/swift

[Index] Don't report extensions with nothing to index

I think we may still need to still index "empty" extensions in user source code so global rename invoked on the type being extended will still be able to find and update the type names in the extensions themselves. IndexASTWalker has IsModuleFile and isSystemModule members you can use to refine the check, depending on whether it's an issue deserializing just system modules or user modules too.

The previously failing test was actually using the old indexing API (in sourcekitd) that we don't really use anymore. To add a test for the above change it'd be better to take a look at test/Index/index_swift_only_system_module.swift. You basically want to copy it up to the end of the "Test-1" section and put an empty extension in your equivalent of some-module.swift (which becomes a system module) and one in %s (user code) and change the c-index-test invocation to do -print-record rather than -print-unit. Take a look at test/Index/Store/record-sourcefile.swift for an example of matching against the -print-record output.

Thanks for fixing this, and if you have any questions or want to look through it together feel free to Slack/video chat with me on Monday!

xymus

comment created time in 8 days

push eventnathawes/swift

Nathan Hawes

commit sha b8a4af2264418a5b3d53d0307f37dd090018392f

[CodeCompletion][Sema] Allow missing args when solving if the completion location indicates the user may intend to write them later. func foo(a: Int, b: Int) {} func foo(a: String) {} // Int and String should both be valid, despite the missing argument for the // first overload since the second arg may just have not been written yet. foo(a: <complete here> func bar(a: (Int) -> ()) {} func bar(a: (String, Int) -> ()) {} // $0 being of type String should be valid, rather than just Int, since $1 may // just have not been written yet. bar { $0.<complete here> }

view details

push time in 8 days

Pull request review commentapple/swift

[CodeCompletion][Sema] Allow missing args when solving if the completion location indicates the user may intend to write them later.

 static bool fixMissingArguments(ConstraintSystem &cs, ASTNode anchor,         cs.createTypeVariable(argLoc, TVO_CanBindToNoEscape)));   } -  SmallVector<std::pair<unsigned, AnyFunctionType::Param>, 4> synthesizedArgs;+  SmallVector<SynthesizedArg, 4> synthesizedArgs;   synthesizedArgs.reserve(numMissing);   for (unsigned i = args.size() - numMissing, n = args.size(); i != n; ++i) {-    synthesizedArgs.push_back(std::make_pair(i, args[i]));+    synthesizedArgs.push_back(SynthesizedArg{i, None, args[i]});   } -  auto *fix = AddMissingArguments::create(cs, synthesizedArgs,-                                          cs.getConstraintLocator(locator));+  bool shouldFix = true; -  if (cs.recordFix(fix))-    return true;+  // Treat missing anonymous arguments as valid in closures containing the+  // code completion location, since they may have just not been written yet.+  if (cs.isForCodeCompletion()) {+    if (auto *closure = getAsExpr<ClosureExpr>(anchor)) {+      SourceManager &SM = closure->getASTContext().SourceMgr;+      SourceRange range = closure->getSourceRange();+      if (range.isValid() && SM.rangeContainsCodeCompletionLoc(range)) {+        shouldFix = !closure->hasAnonymousClosureVars() &&+          (!args.empty() || closure->getInLoc().isValid());

Would missing the single argument tuple handling below (need to expand a few lines) be a problem?

nathawes

comment created time in 8 days

PullRequestReviewEvent

PR opened apple/swift

Reviewers
[CodeCompletion][Sema] Allow missing args when solving if the completion location indicates the user may intend to write them later.

Int and String members should both be prioritized for the completion below despite the missing argument for the first overload since the second argument may just have not been written yet:

func foo(a: Int, b: Int) {}
func foo(a: String) {}

foo(a: someBase.<complete here>

Similarly, members of type String should be prioritized for the completion below (rather than just Int) since the user may intend to use $1 later in the expression.

func bar(a: (Int) -> ()) {}
func bar(a: (String, Int) -> ()) {}

bar { $0.<complete here> }
+328 -50

1 comment

9 changed files

pr created time in 8 days

push eventnathawes/swift

Nathan Hawes

commit sha 36f89a014cf05730156fe1924faa7dd4ad683178

[CodeCompletion][Sema] Allow missing args when solving if the completion location indicates the user may intend to write them later. func foo(a: Int, b: Int) {} func foo(a: String) {} // Int and String should both be valid, despite the missing argument for the // first overload since the second arg may just have not been written yet. foo(a: <complete here> func bar(a: (Int) -> ()) {} func bar(a: (String, Int) -> ()) {} // $0 being of type String should be valid, rather than just Int, since $1 may // just have not been written yet. bar { $0.<complete here> }

view details

push time in 8 days

push eventnathawes/swift

Nathan Hawes

commit sha be7a1941305feaffed9e9b1a84bdb7d7cad351e1

[CodeCompletion][Sema] Allow missing args when solving if the completion location indicates the user may intend to write them later. func foo(a: Int, b: Int) {} func foo(a: String) {} // Int and String should both be valid, despite the missing argument for the // first overload since the second arg may just have not been written yet. foo(a: <complete here> func bar(a: (Int) -> ()) {} func bar(a: (String, Int) -> ()) {} // $0 being of type String should be valid, rather than just Int, since $1 may // just have not been written yet. bar { $0.<complete here> }

view details

push time in 8 days

delete branch nathawes/swift

delete branch : reuse-completion-context-finder-for-fallback-completion

delete time in 11 days

push eventapple/swift

Nathan Hawes

commit sha 90418612f400b3e2c58c4f42c635b55840ffeed8

[CodeCompletion] Reuse CompletionContextFinder for fallback completion when no typeCheckExpression call is made ...and adjust the fallback context it choses now that ErrorExprs no longer cause constraint generation to fail. Also fix some issues with the fallback logic in typeCheckForCodeCompletion: 1) For completion expressions in multi-statement closures, we were assuming a separate typeCheckExpression call would be made when the outer expression produced a single solution that had a resolved type for the closure. If the solution contained other fixes unrelated to the closure however, it wasn't applied and a separate call for the body was never made. 2) typeCheckForCodeComplation sometimes falls back to regular expression type checking but didn't update the passed-in target's expression after santizing and prechecking it, which may have modified it and its sub-expressions. This triggered assertion failures in certain cases due to the mix of the stale top-level expression pointer being used with updated subexpressions.

view details

Nathan Hawes

commit sha abd460817cfad6e6acc274752daadefa34747a39

Merge pull request #34287 from nathawes/reuse-completion-context-finder-for-fallback-completion [CodeCompletion] Reuse CompletionContextFinder for fallback completion when no typeCheckExpression call is made

view details

push time in 11 days

PR merged apple/swift

[CodeCompletion] Reuse CompletionContextFinder for fallback completion when no typeCheckExpression call is made

Also adjust the fallback context it choses now that ErrorExprs no longer cause constraint generation to fail, and provide the correct DeclContext of the fallback as well, rather than using the DeclContext of the original expression.

This PR also fixes some issues with the fallback logic in typeCheckForCodeCompletion:

  1. For completion expressions in multi-statement closures, we were assuming a separate typeCheckExpression call would be made when the outer expression produced a single solution that had a resolved type for the closure. If the solution contained other fixes unrelated to the closure however, it wasn't applied and a separate call for the body was never made.

  2. typeCheckForCodeCompletion sometimes falls through to normal expression type checking but didn't update the passed-in target's expression after sanitizing and prechecking it, which may have modified it and/or its sub-expressions. This triggered assertion failures in certain cases due to a stale top-level expression pointer being used with updated subexpressions.

+222 -166

1 comment

2 changed files

nathawes

pr closed time in 11 days

PR opened apple/swift

Reviewers
[CodeCompletion] Reuse CompletionContextFinder for fallback completion when no typeCheckExpression call is made

...and adjust the fallback context it choses now that ErrorExprs no longer cause constraint generation to fail.

Also fix some issues with the fallback logic in typeCheckForCodeCompletion:

  1. For completion expressions in multi-statement closures, we were assuming a separate typeCheckExpression call would be made when the outer expression produced a single solution that had a resolved type for the closure. If the solution contained other fixes unrelated to the closure however, it wasn't applied and a separate call for the body was never made.

  2. typeCheckForCodeCompletion sometimes falls back to regular expression type checking but didn't update the passed-in target's expression after sanitizing and prechecking it, which may have modified it and/or its sub-expressions. This triggered assertion failures in certain cases due to a stale top-level expression pointer being used with updated subexpressions.

+222 -166

0 comment

2 changed files

pr created time in 12 days

push eventnathawes/swift

Nathan Hawes

commit sha 90418612f400b3e2c58c4f42c635b55840ffeed8

[CodeCompletion] Reuse CompletionContextFinder for fallback completion when no typeCheckExpression call is made ...and adjust the fallback context it choses now that ErrorExprs no longer cause constraint generation to fail. Also fix some issues with the fallback logic in typeCheckForCodeCompletion: 1) For completion expressions in multi-statement closures, we were assuming a separate typeCheckExpression call would be made when the outer expression produced a single solution that had a resolved type for the closure. If the solution contained other fixes unrelated to the closure however, it wasn't applied and a separate call for the body was never made. 2) typeCheckForCodeComplation sometimes falls back to regular expression type checking but didn't update the passed-in target's expression after santizing and prechecking it, which may have modified it and its sub-expressions. This triggered assertion failures in certain cases due to the mix of the stale top-level expression pointer being used with updated subexpressions.

view details

push time in 12 days

push eventnathawes/swift

Nathan Hawes

commit sha 482f4c259cafaab6fb463fb0b9f9cad45d7f8336

[CodeCompletion] Reuse CompletionContextFinder for fallback completion when no typeCheckExpression call is made ...and adjust the fallback context it choses now that ErrorExprs no longer cause constraint generation to fail. Also fix some issues with the fallback logic in typeCheckForCodeCompletion: 1) For completion expressions in multi-statement closures, we were assuming a separate typeCheckExpression call would be made when the outer expression produced a single solution that had a resolved type for the closure. If the solution contained other fixes unrelated to the closure however, it wasn't applied and a separate call for the body was never made. 2) typeCheckForCodeComplation sometimes falls back to regular expression type checking but didn't update the passed-in target's expression after santizing and prechecking it, which may have modified it and its sub-expressions. This triggered assertion failures in certain cases due to the mix of the stale top-level expression pointer being used with updated subexpressions.

view details

push time in 12 days

push eventapple/swift

Nathan Hawes

commit sha a91cede79b812b041da5d7efb6c63ebebe6d3aea

[Parse][CodeCompletion] Don't special case code completion when forming single-expression closures/function bodies (NFC) Code completion used to avoid forming single expression closures/function bodies when the single expression contained the code completion expression because a contextual type mismatch could result in types not being applied to the AST, giving no completions. Completions that have been migrated to the new solver-based completion mechanism don't need this behavior, however. Rather than trying to guess whether the type of completion we're going to end up performing is one of the ones that haven't been migrated to the solver yet when parsing, instead just always form single-expression closures/function bodies (like we do for regular compilation) and undo the transformation if and when we know we're going to perform a completion kind we haven't migrated yet. Once all completion kinds are migrated, the undo-ing code can be removed.

view details

Nathan Hawes

commit sha cf34fa5cb518598b4db85834ea7d06826f002ad2

Merge pull request #34253 from nathawes/nfc-always-form-single-expression-return-and-undo-if-needed [Parse][CodeCompletion] Don't special case code completion when forming single-expression closures/function bodies (NFC)

view details

push time in 15 days

delete branch nathawes/swift

delete branch : nfc-always-form-single-expression-return-and-undo-if-needed

delete time in 15 days

PR merged apple/swift

[Parse][CodeCompletion] Don't special case code completion when forming single-expression closures/function bodies (NFC)

Code completion used to avoid forming single expression closures/function bodies when the single expression contained the code completion expression because a contextual type mismatch could result in types not being applied to the AST, giving no completions.

Completions that have been migrated to the new solver-based completion mechanism don't need this behavior, however. Rather than trying to guess whether the type of completion we're going to end up performing is one of the ones that haven't been migrated to the solver yet when parsing, instead just always form single-expression closures/function bodies (like we do for regular compilation) and undo the transformation if and when we know we're going to perform a completion kind we haven't migrated yet.

Once all completion kinds are migrated, the undo-ing code can be removed.

+41 -71

2 comments

5 changed files

nathawes

pr closed time in 15 days

push eventnathawes/swift

Nathan Hawes

commit sha a91cede79b812b041da5d7efb6c63ebebe6d3aea

[Parse][CodeCompletion] Don't special case code completion when forming single-expression closures/function bodies (NFC) Code completion used to avoid forming single expression closures/function bodies when the single expression contained the code completion expression because a contextual type mismatch could result in types not being applied to the AST, giving no completions. Completions that have been migrated to the new solver-based completion mechanism don't need this behavior, however. Rather than trying to guess whether the type of completion we're going to end up performing is one of the ones that haven't been migrated to the solver yet when parsing, instead just always form single-expression closures/function bodies (like we do for regular compilation) and undo the transformation if and when we know we're going to perform a completion kind we haven't migrated yet. Once all completion kinds are migrated, the undo-ing code can be removed.

view details

push time in 15 days

push eventnathawes/swift

Nathan Hawes

commit sha acdcac44ed7d9b288fdb7028bf16f4a06167ca3e

[Parse][CodeCompletion] Don't special case code completion when forming single-expression closures/function bodies (NFC) Code completion used to avoid forming single expression closures/function bodies when the single expression contained the code completion expression because a contextual type mismatch could result in types not being applied to the AST, giving no completions. Completions that have been migrated to the new solver-based completion mechanism don't need this behavior, however. Rather than trying to guess whether the type of completion we're going to end up performing is one of the ones that haven't been migrated to the solver yet when parsing, instead just always form single-expression closures/function bodies (like we do for regular compilation) and undo the transformation if and when we know we're going to perform a completion kind we haven't migrated yet. Once all completion kinds are migrated, the undo-ing code can be removed.

view details

push time in 15 days

PullRequestReviewEvent

Pull request review commentapple/swift

[Parse][CodeCompletion] Don't special case code completion when forming single-expression closures/function bodies (NFC)

 bool CodeCompletionCallbacksImpl::trySolverCompletion() {   } } +// FIXME: Remove this once all expression position completions are migrated+// to work via TypeCheckCompletionCallback.+static void undoSingleExpressionReturn(DeclContext *DC) {+  auto updateBody = [](BraceStmt *BS, ASTContext &Ctx) -> bool {+    if (Ctx.CompletionCallback)+      return false;++    SourceManager &SM = Ctx.SourceMgr;+    ASTNode FirstElem = BS->getFirstElement();+    auto *RS = dyn_cast_or_null<ReturnStmt>(FirstElem.dyn_cast<Stmt*>());++    if (!RS || !RS->isImplicit())+      return false;++    SourceRange Range = RS->getSourceRange();+    if (Range.isInvalid())+      return false;++    if (!SM.rangeContainsCodeCompletionLoc(Range))+      return false;

This was just me attempting to matching the Status.hasCompletion() check in the old logic, but you're right - we already know that's true here. I'll remove it.

nathawes

comment created time in 15 days

delete branch nathawes/swift

delete branch : handle-error-exprs-when-generating-constraints-for-completion

delete time in 15 days

push eventapple/swift

Nathan Hawes

commit sha be231208f36e91d9b20d8bc52fb8d5012ce1277b

[CodeCompletion][CSGen] Treat ErrorExprs as holes when generating constraints for code completion This lets us still provide member completions when the base expression contains parse errors or unresolved decls e.g. returnsAString(undefined).<complete here>

view details

Nathan Hawes

commit sha 98614d1737e3d39729c46747316cb52d5cddf92a

Merge pull request #34238 from nathawes/handle-error-exprs-when-generating-constraints-for-completion [CodeCompletion][CSGen] Treat ErrorExprs as holes when generating constraints for code completion

view details

push time in 15 days

PR merged apple/swift

[CodeCompletion][CSGen] Treat ErrorExprs as holes when generating constraints for code completion

This lets us still provide member completions when the base expression contains parse errors or unresolved decls e.g. returnsAString(undefined).<complete here>

+31 -9

4 comments

8 changed files

nathawes

pr closed time in 15 days

PR opened apple/swift

Reviewers
[Parse][CodeCompletion] Don't special case code completion when forming single-expression closures/function bodies (NFC)

Code completion used to avoid forming single expression closures/function bodies when the single expression contained the code completion expression because a contextual type mismatch could result in types not being applied to the AST, giving no completions.

Completions that have been migrated to the new solver-based completion mechanism don't need this behavior, however. Rather than trying to guess whether the type of completion we're going to end up performing is one of the ones that haven't been migrated to the solver yet when parsing, instead just always form single-expression closures/function bodies (like we do for regular compilation) and undo the transformation if and when we know we're going to perform a completion kind we haven't migrated yet.

Once all completion kinds are migrated, the undo-ing code can be removed.

+47 -71

0 comment

5 changed files

pr created time in 15 days

pull request commentapple/swift

[CodeCompletion][CSGen] Treat ErrorExprs as holes when generating constraints for code completion

@swift-ci please smoke test Linux

nathawes

comment created time in 16 days

Pull request review commentapple/swift

[CodeCompletion][CSGen] Treat ErrorExprs as holes when generating constraints for code completion

 namespace {     ConstraintSystem &getConstraintSystem() const { return CS; }      virtual Type visitErrorExpr(ErrorExpr *E) {-      // FIXME: Can we do anything with error expressions at this point?-      return nullptr;+      if (!CS.isForCodeCompletion())+        return nullptr;++      // For code completion, treat error expressions that don't contain+      // the completion location itself as holes.+      SourceRange range = E->getSourceRange();+      if (range.isInvalid() ||

I think we'll still need the fallback regardless because of multi-statement closure bodies being checked in a separate call to typeCheckExpression than the outer expression containing them. If the completion is in a multi-statement closure body and the outer typeCheckExpression call produces a solution, we wait for the second typeCheckExpression call for the closure body expressions to determine the base and context types for completion. If the outer typeCheckExpression call fails to produce a solution there is no second call for the expressions in the multi-statement closure body it contained so we have to do a fallback typecheck on the expression containing the completion within the body (and we won't know the closure's type unless it was explicitly written since the outer type check failed).

@xedin If we walk into the original expression would the error expression's original expression still solve in isolation from its surrounding context? I.e in x = foo(someVar.someMember.).<here> the argument to foo is an error expression because of the trailing . before the ) with no following member. if we walk the someVar.someMember part during constraint generation would we end up trying to match someMember's type against the parameter type of any foo overloads?

nathawes

comment created time in 16 days

PullRequestReviewEvent

push eventnathawes/swift

Nathan Hawes

commit sha be231208f36e91d9b20d8bc52fb8d5012ce1277b

[CodeCompletion][CSGen] Treat ErrorExprs as holes when generating constraints for code completion This lets us still provide member completions when the base expression contains parse errors or unresolved decls e.g. returnsAString(undefined).<complete here>

view details

push time in 16 days

PR opened apple/swift

Reviewers
[CodeCompletion][CSGen] Treat ErrorExprs as holes when generating constraints for code completion

This lets us still provide member completions when the base expression contains parse errors or unresolved decls e.g. returnsAString(undefined).<complete here>

+27 -9

0 comment

8 changed files

pr created time in 16 days

delete branch nathawes/swift-source-compat-suite

delete branch : update-xfails-2020-10-05

delete time in 17 days

pull request commentapple/swift-source-compat-suite

[run_sk_stress_test] update stress-tester xfails for master -> main rename and new issues

Looks like the source compat suite build is busted at the moment: https://ci.swift.org/view/Source%20Compatibility/job/swift-main-source-compat-suite/5503/console

@shahmishal could we force-merge this? The stress tester xfails aren't covered by CI testing anyway.

nathawes

comment created time in 17 days

create barnchnathawes/swift-source-compat-suite

branch : update-xfails-2020-10-05

created branch time in 18 days

PullRequestReviewEvent

pull request commentapple/swift

Update for rG89c1e35f3c50

@swift-ci please smoke test

gmittert

comment created time in 25 days

pull request commentapple/swift

Update for rG296d8832a3b5

Oh, I think this is the same as my fix here: https://github.com/apple/swift/pull/34062

gmittert

comment created time in 25 days

delete branch nathawes/swift

delete branch : fix-upstream-breakage-on-next

delete time in 25 days

push eventapple/swift

Nathan Hawes

commit sha 40b6798d351f84eac89a558395f3fbdd2430df3f

Update usages of 'SwiftNewtypeAttr' for the new spelling 'SwiftNewTypeAttr'

view details

Nathan Hawes

commit sha ad5b3152c01cf6e5eddebcdf21f467306d0cf222

Merge pull request #34062 from nathawes/fix-upstream-breakage-on-next [next] Update for swiftNewTypeAttr capitalization change.

view details

push time in 25 days

PR merged apple/swift

[next] Update for swiftNewTypeAttr capitalization change.

https://ci.swift.org/job/oss-swift-incremental-RA-osx-next/8064/console

/Volumes/swift-ci/jenkins/workspace/oss-swift-incremental-RA-osx-next/swift/lib/AST/Decl.cpp:8022:48: error: no member named 'SwiftNewtypeAttr' in namespace 'clang'
10:33:53   if (!clangNode || !clangNode->hasAttr<clang::SwiftNewtypeAttr>())
10:33:53                                         ~~~~~~~^
10:33:53 /Volumes/swift-ci/jenkins/workspace/oss-swift-incremental-RA-osx-next/swift/lib/AST/Decl.cpp:8022:65: error: expected unqualified-id
10:33:53   if (!clangNode || !clangNode->hasAttr<clang::SwiftNewtypeAttr>())
10:33:53                                                                 ^
10:33:53 2 errors generated.
+13 -13

6 comments

7 changed files

nathawes

pr closed time in 25 days

PullRequestReviewEvent

pull request commentapple/swift

Fix SR-13490: Fix LT operator and add tests for ImportPath

@swift-ci test and merge

Interfere

comment created time in 25 days

PullRequestReviewEvent

pull request commentapple/swift

[next] Update for swiftNewTypeAttr capitalization change.

@swift-ci please smoke test

nathawes

comment created time in a month

push eventnathawes/swift

Nathan Hawes

commit sha 40b6798d351f84eac89a558395f3fbdd2430df3f

Update usages of 'SwiftNewtypeAttr' for the new spelling 'SwiftNewTypeAttr'

view details

push time in a month

push eventnathawes/swift

Joe Groff

commit sha 023066c1966c63ab3b7a4baee31ac24d29b7de36

SILGen: Relax assertion that incorrectly tripped on lowered opaque capture types. When lowering the SILConstantInfo for a closure implementation type with captures, we are more conservative about substituting opaque types in the capture, since the underlying types may only be available in the local context. This means the SILConstantInfo type may not in fact be exactly what you get from `SILFunction::getFunctionTypeInContext` referencing the implementation function from its originating context, since those opaque types will be substituted in the local context. Fixes SR-13480 | rdar://problem/68159831.

view details

Pavel Yaskevich

commit sha 8c6098a3de956ca058d55a0d4875b29e3ce38498

[CSFix] Add a fix to detect when type of couldn't be inferred

view details

Kuba Mracek

commit sha a20118b54deebb2aa768294b19ef25de62339b23

When building modules on secondary threads via RunSafelyOnThread, request 8 MB of stack

view details

Doug Gregor

commit sha 6fe5245899d6613e0d7e35a1ee539d8a84114678

Fix grammatical error in a new comment

view details

Doug Gregor

commit sha f07c7d15feb4444c603e404f8e10274f275a7104

[Type checker] Eliminate a use-after-free due to C++ temporaries. Found by Brent using ASan, thank you!

view details

Egor Zhdan

commit sha 70a6d2c7c524c1c9576ba1f0d31f53dfa0191b4a

WinSDK: extract version into a separate submodule Currently winver.h gets included into `WinSDK.WinSock2`, however its usages might not be related to sockets, and it requires linking against `Version.Lib`

view details

Slava Pestov

commit sha 29ce77209ce349a4c22740101c0d9e4e3b4ae15d

AST: Convert ConstructorDecl::getDelegatingOrChainedInitKind() into a request This method had a messy contract: - Setting the diags parameter to nullptr inhibited caching - The initExpr out parameter could only used if no result had yet been cached Let's instead use the request evaluator here.

view details

Slava Pestov

commit sha 6b98f8f3b5b9c786912d59f7775996292801c88e

ASTScope: Add a new lookupSingleLocalDecl() entry point This is used in a few places that used to expect parsed but not yet type-checked code to contain DeclRefExprs that reference local bindings. Instead, we can call lookupSingleLocalDecl() with an UnresolvedDeclRefExpr instead.

view details

Slava Pestov

commit sha dcafd585c133319189291b06e213165b6d28b49b

Sema: Use ASTScope::lookupSingleLocalDecl() in MissingOptionalUnwrapFailure

view details

Slava Pestov

commit sha 8ec878bb43cb69570cbec8fd4a60326018c55690

Sema: Use ASTScope::lookupSingleLocalDecl() in CSGen's CollectVarRefs pass When parse-time lookup is disabled, we have to resolve UnresolvedDeclRefExprs inside the closure body, since there's no guarantee that preCheckExpression() has run yet.

view details

Slava Pestov

commit sha ddc0cbd2d4ea1182428c0a88b88a5db2cd1ca3e6

Sema: Use ASTScope::lookupSingleLocalDecl() in BodyInitKindRequest

view details

Slava Pestov

commit sha 6a82f242ac540174111fb346e5d0c47946fd9d53

Sema: Don't trigger ImplInfoRequest from TypeChecker::buildRefExpr() It's too early to do that here, because we may be building a reference to a ParamDecl that is not yet known to be inout, because the constraint solver has not run yet. Instead, always compute the access semantics in CSApply.

view details

Pavel Yaskevich

commit sha 1fb69a7d43f4c3aa58d88309d54537bce61f3d56

[Diagnostics] Diagnose cases when it's impossible to infer type for `nil` Detect and diagnose situations when it's invalid to use `nil` literal without more context e.g. `_ = nil`, `nil as? Int`, or `_ = nil!`.

view details

Pavel Yaskevich

commit sha 7d6a11021030731e4e617bb5a8a995d20dc65087

[CSSimplify] Allow `optional object` constraint to look through holes If right-hand side (optional type) has been determined to be a hole, let's establish that optional object of a hole is a hole and continue searching for a solution.

view details

Pavel Yaskevich

commit sha 1b5ce2b88f6c1adde6a30cb7b0b15955628a7fde

[CSBindings] Start recording `SpecifyContextualTypeForNil` fix when `nil` is bound to a hole

view details

Pavel Yaskevich

commit sha e30bdacd5792737cb1e31a9ba884b1bf6e513028

[CSBindings] Adjust impact of an event when `nil` is bound to a hole

view details

Pavel Yaskevich

commit sha a2b3b545230df44734077af68f59adde65fc3067

[CSGen] Rework constraint generation for `nil` to avoid failing

view details

Michael Gottesman

commit sha a1f4a43483c5c57e7879e40749dee3b4a3ec01ff

[ownership] Teach the ownership verifier how to verify that guaranteed yielded values are only used within the coroutine's lifetime. I think validating this was an oversight from the bringup of coroutines. I discovered this while writing test cases for coroutine lifetime extension. I realized it was possible to write a test case that should have triggered this but was not. I added some tests to make sure that we continue to flag this in the future. rdar://69597888

view details

Pavel Yaskevich

commit sha f96d6d348679f75313ac97a0e8451a34e3ec10fa

[Diagnostics] Remove obsolete special case for `_ = nil`

view details

Robert Widmann

commit sha 4d61b710da706e5904dc8ff538ac66ed7474e042

[Gardening] Rename Incremental/PrivateDependencies to Incremental/Dependencies

view details

push time in a month

pull request commentapple/swift-source-compat-suite

Xfail siesta and siesta-legacy

@swift-ci please test

nathawes

comment created time in a month

PR opened apple/swift-source-compat-suite

Reviewers
Xfail siesta and siesta-legacy

https://bugs.swift.org/browse/SR-13623

+12 -2

0 comment

1 changed file

pr created time in a month

pull request commentapple/swift

[next][SILOptimizer] Update LoopUtils.cpp for some upstream API changes

@swift-ci please smoke test

nathawes

comment created time in a month

PullRequestReviewEvent

pull request commentapple/swift

Fix SR-13490: Fix LT operator and add tests for ImportPath

@swift-ci please test

Interfere

comment created time in a month

push eventnathawes/swift

Nathan Hawes

commit sha 16c0d62302ac1ac4d6140b919e857ad3414bc464

[CodeCompletion] Migrate unresolved member completion to make use of typeCheckForCodeCompletion This hooks up unresolved member completion (i.e. `.<here>`) to the typeCheckForCodeCompletion API to generate completions from all solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any). This lets us produce unresolved member completions even when the contextual type is ambiguous or involves errors. Whenever typeCheckExpression is called on an expression containing a code completion expression and a CompletionCallback has been set, each solution formed is passed to the callback so the type of the completion expression can be extracted and used to lookup up the members to return.

view details

Nathan Hawes

commit sha a6a2cc42730b456a79ddf9a27101066a2ed5b7ef

[Sema][CodeCompletion] Record the index the missing argument was expected at in the 'AddMissingArguments' fix. This is needed to avoid having to rematch arguments to params after the fact to determine if the missing argument is after the argument containing the code completion expression, or before it (for ranking purposes we don't care about missing arguments after the completion position as the user likely just hasn't written them yet).

view details

push time in a month

push eventnathawes/swift

Varun Gandhi

commit sha e48469d03c87f8c1b87a2462fa3cd8c27c4d685f

[NFC] Add missing invariant checks for ExtInfoBuilders.

view details

Varun Gandhi

commit sha 5e9bf1f7c69395db4a99c6e749acc07b81ade90e

[SIL] Store ClangTypeInfo in SILFunctionType. This patch includes a large number of changes to make sure that: 1. When ExtInfo values are created, we store a ClangTypeInfo if applicable. 2. We reduce dependence on storing SIL representations in ASTExtInfo values. 3. Reduce places where we sloppily create ASTExtInfo values which should store a Clang type but don't. In certain places, this is unavoidable; see [NOTE: ExtInfo-Clang-type-invariant]. Ideally, we would check that the appropriate SILExtInfo does always store a ClangTypeInfo. However, the presence of the HasClangFunctionTypes option means that we would need to condition that assertion based on a dynamic check. Plumbing the setting down to SILExtInfoBuilder's checkInvariants would be too much work. So we weaken the check for now; we should strengthen it once we "turn on" HasClangFunctionTypes and remove the dynamic feature switch.

view details

Varun Gandhi

commit sha 983399c1e780c490be51fbf82edd029a584258b9

[Printer] Conditionally print Clang types in emitted SIL.

view details

Xiaodi Wu

commit sha 94887747a4e2746163e85438934a78a8c165fa8f

[benchmark] Add another test to floating point conversion benchmark

view details

Xiaodi Wu

commit sha 26f3c81e44d9cb53abdf51ed2f6a637bae5a3a77

[benchmark] Add another floating point conversion benchmark

view details

Xiaodi Wu

commit sha cb96bfbfdf0045383f11ed4c87e8142aafddf538

[benchmark] Tweak naming and workload for two new tests

view details

Joe Groff

commit sha 57215cb17f9312187d59b7c2465a10f4682bf8f3

SIL.rst: Add documentation for async function representation. Unlike our existing coroutines, async functions run independently within an async coroutine context, and don't directly yield values back and forth. They therefore mostly behave like normal functions with only an `@async` annotation to indicate the presence of async suspend points. The `withUnsafeContinuation` primitive requires some instructions to represent the operation that prepares the continuation to be resumed, which will be represented by `begin_async_continuation`...`await_async_continuation` regions.

view details

3405691582

commit sha 62a13e9ecd31da5ef335f245b66be826d6b5b4ff

[test] Erase SDKROOT since env -u is not portable. The `env -u` flag is not portable and not available on all platforms, so this unit test will fail when the feature is unavailable. Instead of trying to unset the field, just erase it instead, since trying to copy the entire invoked environment is difficult.

view details

Anthony Latsis

commit sha 103a8218380c9d72160f9ca3aa7d1e0ba4d8f1bc

Sema: Allow non-final classes to satisfy properties and subscripts with covariant Self

view details

3405691582

commit sha 42a3da29d77810fed0374ea7efe2faff02f0aef2

[test] Mark failing reflection tests XFAIL. See SR-12893. swift-reflection-dump does not properly handle offsets in ELF executable images that, when interpreted as vaddrs, belong in segments part of the image. This just empirically XFAIL's the unit tests that are crashing or failing, even though the other tests are just happening to pass anyway. There's no clear workaround; disable the expected failures for the moment.

view details

Joe Groff

commit sha 29587ac766e596a4f154ce5c0889c43978e19f77

Revise with feedback from John and Andy

view details

Joe Groff

commit sha e2dfe3a334333b742af60bd513bdfca89c2c5bf1

Add example of `withUnsafeContinuation` lowering to SIL

view details

Pavel Yaskevich

commit sha f97e80347b481494305737a5a82c9c5eef8933b4

[Diagnostics] Allow "unknown base" fix to be diagnosed in ambiguity situations If there are multiple overloads and all of them require explicit base type for a member reference, let's diagnose it as a single error since the problem is the same across the overload choices: ```swift func foo<T>(_: T, defaultT: T? = nil) {} func foo<U>(_: U, defaultU: U? = nil) {} foo(.bar) ``` In this example there is not enough contextual information to determine base type of `.bar` reference and hence both `foo` overloads are a considered valid solutions until explicitly set base type disambiguates them. Resolves: rdar://problem/66891544

view details

Doug Gregor

commit sha 6ce4eb2390df34b9db2987a025fc3d8f5e15346b

[Type checker] Use DotSyntaxCallExpr consistently for instance members. When building a curry thunk for unapplied references to instance methods, the type checker would build a CallExpr rather than a DotSyntaxCallExpr to work around various issues with source locations. Fix the underlying issues with source locations in DotSyntaxCallExpr so we can consistently build DotSyntaxCallExpr here, and assert that we don't do this again: * DotSyntaxCallExpr wasn't able to reason about having just one of its children having source location information; fix it. * @dynamicCallable support was passing the declaration source location for the call expression, which was nowhere in the expression itself. The above mistake was covering for this one.

view details

Slava Pestov

commit sha fa4f7dd664e5745e31214ee5e9729ae33b391f80

Parse: Don't create PatternBindingDecls with overlapping source ranges This was happening in the error recovery path when parsing accessors on a pattern binding declaration that does not bind any variables, eg let _: Int { 0 }

view details

Slava Pestov

commit sha 51a4a91a137c63ad5be04f9e2607a89ed816832b

Sema: Mark a PatternBindingDecl as implicit in the builder transform

view details

Doug Gregor

commit sha ec72db1d8ab63fac12d8c43759f2479caec3c98e

Merge pull request #34019 from DougGregor/curry-thunk-dot-syntax-call-source-locs [Type checker] Use DotSyntaxCallExpr consistently for instance members.

view details

Slava Pestov

commit sha 85ae2274653daa5f0da6bb08b03bc23c997ad715

ASTScope: Remove hacks for PatternBindingDecls with invalid source ranges

view details

Slava Pestov

commit sha c662c10d1eb75521d75bffe496ae5ee6dc1dfe6d

ASTScope: Use visitParsedAccessors() instead of getAllAccessors()

view details

Arnold Schwaighofer

commit sha 383d47fd0061dcd01f4801eda5ba6b66148f4358

IRGen: Scalar type layouts need to profile the SIL type It might contain archetypes whose type metadata is required. rdar://68972976 SR-13555

view details

push time in a month

pull request commentapple/swift

[next][SILOptimizer] Update LoopUtils.cpp for some upstream API changes

@swift-ci please smoke test

nathawes

comment created time in a month

pull request commentapple/swift

[next][SILOptimizer] Update LoopUtils.cpp for some upstream API changes

@swift-ci please smoke test

nathawes

comment created time in a month

push eventnathawes/swift

Varun Gandhi

commit sha e48469d03c87f8c1b87a2462fa3cd8c27c4d685f

[NFC] Add missing invariant checks for ExtInfoBuilders.

view details

Varun Gandhi

commit sha 5e9bf1f7c69395db4a99c6e749acc07b81ade90e

[SIL] Store ClangTypeInfo in SILFunctionType. This patch includes a large number of changes to make sure that: 1. When ExtInfo values are created, we store a ClangTypeInfo if applicable. 2. We reduce dependence on storing SIL representations in ASTExtInfo values. 3. Reduce places where we sloppily create ASTExtInfo values which should store a Clang type but don't. In certain places, this is unavoidable; see [NOTE: ExtInfo-Clang-type-invariant]. Ideally, we would check that the appropriate SILExtInfo does always store a ClangTypeInfo. However, the presence of the HasClangFunctionTypes option means that we would need to condition that assertion based on a dynamic check. Plumbing the setting down to SILExtInfoBuilder's checkInvariants would be too much work. So we weaken the check for now; we should strengthen it once we "turn on" HasClangFunctionTypes and remove the dynamic feature switch.

view details

Varun Gandhi

commit sha 983399c1e780c490be51fbf82edd029a584258b9

[Printer] Conditionally print Clang types in emitted SIL.

view details

Joe Groff

commit sha 57215cb17f9312187d59b7c2465a10f4682bf8f3

SIL.rst: Add documentation for async function representation. Unlike our existing coroutines, async functions run independently within an async coroutine context, and don't directly yield values back and forth. They therefore mostly behave like normal functions with only an `@async` annotation to indicate the presence of async suspend points. The `withUnsafeContinuation` primitive requires some instructions to represent the operation that prepares the continuation to be resumed, which will be represented by `begin_async_continuation`...`await_async_continuation` regions.

view details

Joe Groff

commit sha 29587ac766e596a4f154ce5c0889c43978e19f77

Revise with feedback from John and Andy

view details

Joe Groff

commit sha e2dfe3a334333b742af60bd513bdfca89c2c5bf1

Add example of `withUnsafeContinuation` lowering to SIL

view details

Pavel Yaskevich

commit sha f97e80347b481494305737a5a82c9c5eef8933b4

[Diagnostics] Allow "unknown base" fix to be diagnosed in ambiguity situations If there are multiple overloads and all of them require explicit base type for a member reference, let's diagnose it as a single error since the problem is the same across the overload choices: ```swift func foo<T>(_: T, defaultT: T? = nil) {} func foo<U>(_: U, defaultU: U? = nil) {} foo(.bar) ``` In this example there is not enough contextual information to determine base type of `.bar` reference and hence both `foo` overloads are a considered valid solutions until explicitly set base type disambiguates them. Resolves: rdar://problem/66891544

view details

Varun Gandhi

commit sha 7b967a80304fd1a843cffe2c81826a61e60b6e2d

Merge pull request #33085 from varungandhi-apple/vg-clang-types-in-sil-retry Propagate Clang function types through SIL

view details

Slava Pestov

commit sha 76802dd6354d67e75c8a206e435086a32a0342f4

ASTScope: FunctionBodyScope should not be nested inside ParameterListScope

view details

Slava Pestov

commit sha 753d303c73c1759ded7e9486407d93dd4285e48b

ASTScope: Remove expandIfConfigClauses() We're always guaranteed to visit the elements of the active clause as members of the parent AST node.

view details

Slava Pestov

commit sha c9f2060e54d52365a11c52d0c3d3695aaa81ca04

ASTScope: Remove shouldThisNodeBeScopedWhenFoundInSourceFileBraceStmtOrType()

view details

Slava Pestov

commit sha b7bd4fb8b3e5a2d20ebd27134a473a2e17fee211

ASTScope: Remove 'history' vector

view details

Doug Gregor

commit sha fb86fb3610c2467d8fcaea3b8dddac38b5ad894c

[SR-10251] Add test case for a bug that's already been fixed. Also tracked as rdar://68946205.

view details

Slava Pestov

commit sha 4ff6cda18043cf0f47523dd9485a0f18c45dc8fc

Add module interface printing test with non-trivial pattern binding initializer A stored property can be part of a pattern binding entry whose pattern declares multiple bindings with a single initializer, for example: struct S { let (x, y) = (0, 0) } Make sure these round-trip correctly.

view details

Artem Chikin

commit sha e0dbba569bc2cda697a7d585ae4272d1bf97a5cb

[Dependency Scanner] Add option to execute an import prescan With this option enabled, the dependency scanner gathers all import statements in source files of the main module (non-transitive) and outputs a list of imported modules. This will be used by build systems and the swift-driver as a way to avoid redundant re-scanning in incremental contexts.

view details

Mishal Shah

commit sha 20be565f66ddcf089c2534ba6391110ea430762b

Update CMark branch to main

view details

Artem Chikin

commit sha d5449bf55fb37deef04d0a652dd5e4b4787e0994

[Dependency Scanner] Add import-prescan handling to batch scanning

view details

Holly Borla

commit sha 9af195c73e948b75503d0bd9201edc5f92bc6a6b

[NFC] Remove a typealias from SILInstruction.h that's unused in noasserts builds.

view details

Mishal Shah

commit sha 65764c68fa7b9d3a9942064fd63459823123ca1e

Update the branch to main for swift-llbuild

view details

Mishal Shah

commit sha e7d7847609f94e36602ab618818a27d7ab03fc22

Update the branch to main for swift-tools-support-core

view details

push time in a month

push eventnathawes/swift-source-compat-suite

Mishal Shah

commit sha de829ebfcc3cfb2df05f474ffea29e19cc113b4e

Update the branch scheme for main

view details

Nathan Hawes

commit sha d3867e8863f81635b8f62047ecac8dcc78a4d066

Xfail ACHNBrowserUI

view details

push time in a month

pull request commentapple/swift

[next][SILOptimizer] Update LoopUtils.cpp for some upstream API changes

@swift-ci please smoke test

nathawes

comment created time in a month

pull request commentapple/swift

[next][SILOptimizer] Update LoopUtils.cpp for some upstream API changes

@swift-ci please smoke test

nathawes

comment created time in a month

PR opened apple/swift

[next][SILOptimizer] Update LoopUtils.cpp for some upstream API changes

https://ci.swift.org/view/Swift%20next/job/oss-swift-incremental-RA-linux-ubuntu-16_04-next/21434/

swift/lib/SILOptimizer/Utils/LoopUtils.cpp:254:31: error: no member named 'empty' in 'swift::SILLoop'
    Worklist.push_back({L, L->empty()});
                           ~  ^
swift/lib/SILOptimizer/Utils/LoopUtils.cpp:264:47: error: no member named 'empty' in 'swift::SILLoop'
        Worklist.push_back({Subloop, Subloop->empty()});
                                     ~~~~~~~  ^
swift/lib/SILOptimizer/Utils/LoopUtils.cpp:285:31: error: no member named 'empty' in 'swift::SILLoop'
    Worklist.push_back({L, L->empty()});
                           ~  ^
swift/lib/SILOptimizer/Utils/LoopUtils.cpp:296:47: error: no member named 'empty' in 'swift::SILLoop'
        Worklist.push_back({SubLoop, SubLoop->empty()});
                                     ~~~~~~~  ^
4 errors generated.
+4 -4

0 comment

1 changed file

pr created time in a month

push eventnathawes/swift

Nathan Hawes

commit sha 999d2ada8296fd7b2b5ec87736bfbe7b842eed5a

[SILOptimizer] Update LoopUtils.cpp for some upstream API changes

view details

push time in a month

create barnchnathawes/swift

branch : fix-upstream-breakage-on-next

created branch time in a month

pull request commentapple/swift-source-compat-suite

Xfail ACHNBrowserUI

Waiting on https://github.com/apple/swift-source-compat-suite/pull/459 to land this (it updates master->main everywhere else).

nathawes

comment created time in a month

push eventnathawes/swift-source-compat-suite

Nathan Hawes

commit sha 69c6b8d85d1b069fd8325064de272f1e73c1fe01

Use main rather than master for ACHNBrowserBrowserUI xfail in projects.json Co-authored-by: Mishal Shah <shahmishal@users.noreply.github.com>

view details

push time in a month

PullRequestReviewEvent

pull request commentapple/swift-source-compat-suite

Xfail ACHNBrowserUI

@swift-ci please test

nathawes

comment created time in a month

PR opened apple/swift-source-compat-suite

Reviewers
Xfail ACHNBrowserUI

https://bugs.swift.org/browse/SR-13592

+5 -0

0 comment

1 changed file

pr created time in a month

create barnchnathawes/swift-source-compat-suite

branch : xfail-achnbrowserui

created branch time in a month

PullRequestReviewEvent

PR opened apple/swift

[CodeCompletion] Migrate unresolved member completion to make use of typeCheckForCodeCompletion

Following on from updating regular member completion here, this hooks up unresolved member completion (i.e. .<complete here>) to the typeCheckForCodeCompletion API to generate completions from all solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any). This lets us produce unresolved member completions even when the contextual type is ambiguous or involves errors.

Whenever typeCheckExpression is called on an expression containing a code completion expression and a CompletionCallback has been set, each solution formed is passed to the callback so the type of the completion expression can be extracted and used to lookup up the members to return.

+691 -348

0 comment

22 changed files

pr created time in a month

push eventnathawes/swift

Nathan Hawes

commit sha ae004e4a6404d5b6f8f85f14cfcda783b4b45ca9

[CodeCompletion] Migrate unresolved member completion to make use of typeCheckForCodeCompletion This hooks up unresolved member completion (i.e. `.<here>`) to the typeCheckForCodeCompletion API to generate completions from all solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any). This lets us produce unresolved member completions even when the contextual type is ambiguous or involves errors. Whenever typeCheckExpression is called on an expression containing a code completion expression and a CompletionCallback has been set, each solution formed is passed to the callback so the type of the completion expression can be extracted and used to lookup up the members to return.

view details

push time in a month

push eventnathawes/swift

Yuta Saito

commit sha d6cddaabb59958737e048ff1a5dd4d283c555661

[LTO] Support LLVM LTO for driver This commit adds LTO support for handling linker options and LLVM BC emission. Even for ELF, swift-autolink-extract is unnecessary because linker options are embeded in LLVM BC content when LTO.

view details

Michael Gottesman

commit sha c8d4d168f7981fc0b6cadedd71c2e340c622bcb3

Revert "build-script: remove dead CMake options for Swift" This reverts commit 95102bc258a6b30ba2349d561ef56ea48c601cae. This is actually a dead option that is relied upon for some configurations. I am going to add a note to not touch the option. I talked with compnerd about this and they are cool with this. I think that we can redo this in a nicer way when we are further into the build-script-impl refactoring. I added a note to the code to explain that it isn't dead.

view details

Varun Gandhi

commit sha 384edd1f2b9c64d96dec169460b232f4ce14223f

[docs] Link 'The Swift Runtime' blog posts in ExternalResources.md.

view details

freddi

commit sha 495087f26f4a0288a8cf66be1829304ac403c43b

[sil-opt] Fix to satisfy all trapping instruction case at SILInstruction::mayTrap

view details

freddi

commit sha 2676839087baebf11d8f5b996249f61240bce411

[sil-opt] added test for unconditional_checked_cast_addr and unconditional_checked_cast_value at side-effect.sil

view details

Karoy Lorentey

commit sha c8523e59e403cd53f24ae564d1c8145b48369d21

[shims] Add AppKit overlay shims

view details

Owen Voorhees

commit sha f234da630a9fea3d3779df662e1f3498c8364389

[Changelog] Add SE-0284

view details

Erik Eckstein

commit sha 063929b3f022190bb578e3888215788e2e090bcf

Demangler: fix a crash when re-mangling retroactive conformances If there are multiple retroactive conformances in the mangling tree, they are put under a TypeList node. This case was not handled by the re-mangler. The crash shows up in an assert-build of the compiler, because the re-mangler is used for mangling verification. rdar://problem/68467435

view details

stevapple

commit sha fa6a8eceff308402420c3d3b559f9cdf2160b4cc

[test] Fix line-directive on Windows

view details

Slava Pestov

commit sha fec67d68a8f2a8f50530036fbc41e029b4cb343b

AST: Add a GenericParamList::walk() method

view details

Slava Pestov

commit sha d711c6defc878d7e8536a4d12be3ece0a7f8417a

AST: Add a GenericParamList::lookUpGenericParam() method

view details

Slava Pestov

commit sha 8f7c59ee3846759bfd0b80c8185dfd46660ba8bb

Sema: Plumb a GenericParamList through type resolution for SIL parsing When parse-time lookup is disabled, we can't rely on the parser binding IdentTypeReprs that name generic parameters, so we do it in type resolution by having the SIL parser supply a GenericParamList.

view details

Holly Borla

commit sha 1f426773eed1bbed59dfdbbcc4288e92454b2b07

[Property Wrappers] Lower assign_by_wrapper to re-assignment of the backing property wrapper before all of self is initialized if the wrapper has already been initialized.

view details

Slava Pestov

commit sha dbdbbff7433f2297db63fc7f633691aa2cb416ba

SILParser: Overhaul to not rely on parse-time lookup

view details

Owen Voorhees

commit sha 6f68c4c7f4a7f0163787becf2adbaf5fba0fc873

Merge pull request #33828 from owenv/284-changelog [Changelog] Add SE-0284

view details

Robert Widmann

commit sha 513d108a0e93c845bdc45b504b58e8553ad37852

[NFC] Drop SourceFileKind from getMainSourceFile The parameter here was derived from the CompilerInvocation-level parsing bits, which doesn't make any sense. This state is going away soon, so drop the parameter.

view details

Robert Widmann

commit sha 8b725d8713f96a2bb7599f92b2f64856aa9aaed3

[NFC] Inline inputFileKindCanHaveTBDValidated

view details

Robert Widmann

commit sha c3e33bec7a81619c7b0cd0cd0e471a6b91c5632b

[NFC] Drop getSourceFileKind

view details

Robert Widmann

commit sha 75116e9f86c8e676b302b7b8fda4939ca316502f

[NFC] Inline CompilerInstance::setUpForInput

view details

Robert Widmann

commit sha 66ad0c1c40411d85d48f6724daf1a1913e1f0204

[Gardening] Document InputFile

view details

push time in a month

push eventnathawes/swift

Yuta Saito

commit sha d6cddaabb59958737e048ff1a5dd4d283c555661

[LTO] Support LLVM LTO for driver This commit adds LTO support for handling linker options and LLVM BC emission. Even for ELF, swift-autolink-extract is unnecessary because linker options are embeded in LLVM BC content when LTO.

view details

Michael Gottesman

commit sha c8d4d168f7981fc0b6cadedd71c2e340c622bcb3

Revert "build-script: remove dead CMake options for Swift" This reverts commit 95102bc258a6b30ba2349d561ef56ea48c601cae. This is actually a dead option that is relied upon for some configurations. I am going to add a note to not touch the option. I talked with compnerd about this and they are cool with this. I think that we can redo this in a nicer way when we are further into the build-script-impl refactoring. I added a note to the code to explain that it isn't dead.

view details

Varun Gandhi

commit sha 384edd1f2b9c64d96dec169460b232f4ce14223f

[docs] Link 'The Swift Runtime' blog posts in ExternalResources.md.

view details

freddi

commit sha 495087f26f4a0288a8cf66be1829304ac403c43b

[sil-opt] Fix to satisfy all trapping instruction case at SILInstruction::mayTrap

view details

freddi

commit sha 2676839087baebf11d8f5b996249f61240bce411

[sil-opt] added test for unconditional_checked_cast_addr and unconditional_checked_cast_value at side-effect.sil

view details

Karoy Lorentey

commit sha c8523e59e403cd53f24ae564d1c8145b48369d21

[shims] Add AppKit overlay shims

view details

Owen Voorhees

commit sha f234da630a9fea3d3779df662e1f3498c8364389

[Changelog] Add SE-0284

view details

Erik Eckstein

commit sha 063929b3f022190bb578e3888215788e2e090bcf

Demangler: fix a crash when re-mangling retroactive conformances If there are multiple retroactive conformances in the mangling tree, they are put under a TypeList node. This case was not handled by the re-mangler. The crash shows up in an assert-build of the compiler, because the re-mangler is used for mangling verification. rdar://problem/68467435

view details

stevapple

commit sha fa6a8eceff308402420c3d3b559f9cdf2160b4cc

[test] Fix line-directive on Windows

view details

Slava Pestov

commit sha fec67d68a8f2a8f50530036fbc41e029b4cb343b

AST: Add a GenericParamList::walk() method

view details

Slava Pestov

commit sha d711c6defc878d7e8536a4d12be3ece0a7f8417a

AST: Add a GenericParamList::lookUpGenericParam() method

view details

Slava Pestov

commit sha 8f7c59ee3846759bfd0b80c8185dfd46660ba8bb

Sema: Plumb a GenericParamList through type resolution for SIL parsing When parse-time lookup is disabled, we can't rely on the parser binding IdentTypeReprs that name generic parameters, so we do it in type resolution by having the SIL parser supply a GenericParamList.

view details

Holly Borla

commit sha 1f426773eed1bbed59dfdbbcc4288e92454b2b07

[Property Wrappers] Lower assign_by_wrapper to re-assignment of the backing property wrapper before all of self is initialized if the wrapper has already been initialized.

view details

Slava Pestov

commit sha dbdbbff7433f2297db63fc7f633691aa2cb416ba

SILParser: Overhaul to not rely on parse-time lookup

view details

Owen Voorhees

commit sha 6f68c4c7f4a7f0163787becf2adbaf5fba0fc873

Merge pull request #33828 from owenv/284-changelog [Changelog] Add SE-0284

view details

Robert Widmann

commit sha 513d108a0e93c845bdc45b504b58e8553ad37852

[NFC] Drop SourceFileKind from getMainSourceFile The parameter here was derived from the CompilerInvocation-level parsing bits, which doesn't make any sense. This state is going away soon, so drop the parameter.

view details

Robert Widmann

commit sha 8b725d8713f96a2bb7599f92b2f64856aa9aaed3

[NFC] Inline inputFileKindCanHaveTBDValidated

view details

Robert Widmann

commit sha c3e33bec7a81619c7b0cd0cd0e471a6b91c5632b

[NFC] Drop getSourceFileKind

view details

Robert Widmann

commit sha 75116e9f86c8e676b302b7b8fda4939ca316502f

[NFC] Inline CompilerInstance::setUpForInput

view details

Robert Widmann

commit sha 66ad0c1c40411d85d48f6724daf1a1913e1f0204

[Gardening] Document InputFile

view details

push time in a month

create barnchnathawes/swift

branch : new-unresolved-member-completion

created branch time in a month

PullRequestReviewEvent

push eventnathawes/swift

Karoy Lorentey

commit sha 57ea964f2c3a659aef11eccf9a63e891b5ae4b74

Merge commit '3eb82c183662945687f48e11c09828f551b34858' into master-next # Conflicts: # include/swift/Frontend/FrontendInputsAndOutputs.h

view details

Karoy Lorentey

commit sha b65f1c4ca982de1d4e202b9be899d677535bf4ac

Merge remote-tracking branch 'origin/master' into master-next This merges the following two commits without taking any changes: 1c9b0908e65d9a06d1c5b7f13c9c1eb661619418 (a mismerge of master-next into master) 68351d21105d8bce516ce2108b87444526b54694 (the revert of the change above) The second commit reverts every change on master-next, which we don't want to pick up here.

view details

swift_jenkins

commit sha f68a884f2316ecae4dc7768f55b70b4c5a489505

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 64a1144b0148b76f54ba326f54707dcbb61dad2c

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 1ba2a7cf1d52ebf0b48ad92632dd4c186a9ff4bf

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 3fe9613c51c8c233ed34cad047e456baf3f29340

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha bce2026b1527bbf8d0e5df31258dc17665f28b26

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 54775ac3ad29a7fd52e689ac234d5c73072b2bc1

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 46aac32a1fc3148ba42c415b57f9b8175c54304f

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 048349ff5f0d011cb7438186d3cbd9e40f00b86d

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha eb3d0ef01bca77b381423d9a7a2b9c343bde82e3

Merge remote-tracking branch 'origin/master' into master-next

view details

David Zarzycki

commit sha 4be1192904a57d54f08e305c8307843b613385c1

Keep master-next building and tested

view details

swift_jenkins

commit sha 90d7a9d797e5c0b6bb4418ca6c769bc6d8619e33

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 82ea68930b22b36f127187e08bb6e69108a5310e

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 076e012f7961f519e9bdb429160a2b745af41349

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 9ce5177c140454eb7d946f2cfd32c98b09e35056

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha ee928338a7764a7aca80e800ed558862d6f3899d

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha b10d49a234e65afc29ae3d21473415c203a53ba8

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 44d992695840248d2c0a130722dde850e01d9817

Merge remote-tracking branch 'origin/master' into master-next

view details

swift_jenkins

commit sha 1e61a73ae6cfa44940a4d1510c447a8475ebcec0

Merge remote-tracking branch 'origin/master' into master-next

view details

push time in a month

push eventnathawes/swift

Brian Gontowski

commit sha 3425a6dbb16e5fa7ad4b735eff4533c279d61442

Added protocol to support CVarArg objects that need to be retained

view details

Brian Gontowski

commit sha 0e7749bcde5eb1bc9fec82ef0eb3896ec8d6de6f

Fixed comment

view details

Brian Gontowski

commit sha 17c77ba703b32c11e127573d414d31c9ec635188

Only use _CVarArgObject on non-ObjC platforms

view details

Brian Gontowski

commit sha 515c371be434ff49debfd145ebd9047bd148d47f

Avoid a warning when not modifying arg

view details

Hamish Knight

commit sha a7a8d9fd260bd2d5d1a213100c4000f5618e39bf

[AST] Remove NewBodyKind default A bunch of callers were accidentally misusing it.

view details

Hamish Knight

commit sha 9b8b2068d2931a60cd495fab59e3204c16db2d0f

Add AbstractFunctionDecl::getTypecheckedBody Refactor TypeCheckFunctionBodyRequest to return the type-checked body, and remove `typeCheckAbstractFunctionBody` in favor of a method on AbstractFunctionDecl. In addition, start returning an ErrorExpr body instead of a partially type-checked body if type-checking fails.

view details

Hamish Knight

commit sha 8fd6d7e19a9d8acf58cdd1182015df76ac88ea97

Add some missing calls to setThrows We no longer run error checking for already type-checked synthesized functions, so add a couple of `setThrows` calls where they were previously missing.

view details

Hamish Knight

commit sha 28246a7596dcc565b827b3666b9e4bed9adf6911

[SILGen] Use getTypecheckedBody Use `getTypecheckedBody` to allow lazy type-checking when emitting function definitions.

view details

Saleem Abdulrasool

commit sha 7128611a9d90b69a93a2adf8b01360ead0eedace

AST: align `ImportedModule` to 64-bits Align `ImportedModule` to 64-bits as it is used in other types which force the 8-byte alignment for the layout.

view details

Robert Widmann

commit sha 98765132c90af02b445e77988ba1d7047bbc57b5

[Gardening] Document a Strange Sort

view details

Pavel Yaskevich

commit sha 7b0e46bdfadded96df9c8d5673734c9475e8d5bd

[ConstraintSystem] Adjust impact of a missing member fix Currently its impact is set to be less than that of a conversion fix, which is incorrect. Let's adjust that and increase it even farther for cases where base is `Any` or `AnyObject`. We couldn't do it for `Any` before because it was used to represent type holes, but it's no longer the case. Resolves: rdar://problem/68155466

view details

Varun Gandhi

commit sha 58fcc4602da3412ecf958b2f62c6465ae0ef27d7

[docs] Fix typos and broken links.

view details

Varun Gandhi

commit sha 296d25294b53618ebe25603ba3a508067a5ad1db

[docs] Add link to FAQ in README.

view details

Varun Gandhi

commit sha b6558fd9ed6c89ffc0d5a643f303e8b9ca33895a

[docs] Describe using `git grep` in FAQ. Also changed the grep example to use long flag names for clarity.

view details

3405691582

commit sha b59910ef5bdc3c95415ada2beddec9f1eb1e687a

Add OpenBSD to PlatformKinds.def. In #31686 changes were introduced to ensure that capacity was stored in the ManagedBuffer allocation, and @lorentey sugested that as a stopgap measure for addressing the lack of platform malloc introspection on OpenBSD, we use Swift availability attributes instead on the relevant parts of ManagedBuffer and friends. Since platform availability symbols must be specifically set up to be used, this commit does so in advance of the above change.

view details

3405691582

commit sha cd7570fdee9c68dcc93b0107041c6c9bc47f101c

ManagedBuffer capacity is unavailable on OpenBSD. On OpenBSD, malloc introspection (e.g., malloc_usable_size or malloc_size) is not provided by the platform allocator. Since allocator introspection is currently a load-bearing piece of functionality for ManagedBuffer and ManagedBufferPointer, pending any API changes, as a stopgap measure, this commit marks methods in ManagedBuffer and ManagedBufferPointer calling _swift_stdlib_malloc_size and methods dependent thereon unavailable on OpenBSD. This may induce some compatibility issues for some files, but at least this change ensures that we can get stdlib to build on this platform until the evolution process addresses this problem more thoroughly.

view details

Dan Zheng

commit sha 5dad73589665b2edc53649c42f39d5544b27b609

[docs] Fix typos in CppInteroperabilityManifesto.md. - `specilalizations` -> `specializations` - Mark a setter method as `mutating`.

view details

Ben Barham

commit sha 4f5d4d80bb6e6da1218db7f505685fe508190833

[Gardening] Add re-usable copy* utility methods to use in code completion Various copy* methods were re-implemented in a bunch of files, move them to CodeCompletion.h so they can be re-used everywhere that needs them.

view details

Doug Gregor

commit sha 22a350b1acee19149ad13d233aab52ef2845d2eb

[Concurrency] Add parsing support for actor classes. Introduce the "actor class" syntax. Ensure that it is only used for root classes or classes that inherit from other actor classes.

view details

stevapple

commit sha 0e68e4de9aaa0e83d9aced70cab3c14807659ad1

Fix WindowsBuild.md

view details

push time in a month

delete branch nathawes/swift

delete branch : make-hascodecompletion-flag-not-imply-haserror

delete time in a month

push eventapple/swift

Nathan Hawes

commit sha bb773232a8f3e22f7950e5988527979913183681

[Parse][CodeCompletion] Stop code completion within a closure causing parser recovery after the closure. For example, the completion below would trigger error recovery within the closure, which we recover from by skipping to the first inner closure's right brace. The fact that we recovered though, was not recorded. The closure is treated as still being an error, triggering another recovery after it that skips over the 'Thing' token, giving a lone closure expression, rather than a call. CreateThings { Thing { point in print("hello") point.#^HERE^# } Thing { _ in } } This isn't an issue for code completion when the outer closure is a regular closure, but when it's a function builder, invalid elements result in no types being applied (no valid solutions) and we end up with no completion results. The fix here is removing the error status from the parser result after the initial parser recovery.

view details

Nathan Hawes

commit sha f0accb0003a89bd091f1c6489a5b1680893e28b5

[test] Cover a few more function builder cases in test/IDE/complete_ambiguous.swift (NFC)

view details

Nathan Hawes

commit sha 4b389cd4f1ddd808e2420b5033d36a98b0a8d308

Merge pull request #33907 from nathawes/make-hascodecompletion-flag-not-imply-haserror [Parse][CodeCompletion] Stop code completion within a closure causing parser recovery after the closure.

view details

push time in a month

PR merged apple/swift

[Parse][CodeCompletion] Stop code completion within a closure causing parser recovery after the closure.

For example, the completion below would trigger error recovery within the first closure, which we recover from by skipping to that closure's right brace. The fact that we recovered though, wasn't being recorded. The closure was treated as still being in error, triggering another recovery after it that skips over the Thing token, giving a lone closure expression, rather than a call as the next expression.

CreateThings {
    Thing { point in
      print("hello")
      point.#^HERE^#
    }
    Thing { _ in }
}

This isn't an issue for code completion when the outer closure is a regular closure, but when it's a function builder, invalid elements result in no types being applied (no valid solutions) and we end up with no completion results. We should have a fallback to handle when the other elements are legitimately invalid (rather than from parser recovery skipping things), but when the other elements are valid this fix gets us results in the meantime and should still give more accurate results compared to a single-function-builder-element fallback once we have one.

The fix here is removing the error status from the parser result after the initial parser recovery. We still needed to propagate the fact that the parsed AST node contained a code completion token though, so that the code completion callbacks still happen. This required dropping the invariant that ParserResult::hasCodeCompletion() implies ParserResult::isError(). To ensure there was no unintended behavior change, this updates existing checks of ParserResult::isError() that weren't directly related to this fix to use ParserResult::isErrorOrHasCompletion() instead (which is equivalent to the behavior of isError() prior to this change).

+194 -119

7 comments

11 changed files

nathawes

pr closed time in a month

more