profile
viewpoint

llvm/llvm-project 6380

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.

apple/swift-syntax 1423

SwiftPM package for SwiftSyntax library.

akyrtzi/cairo-gral 10

A hardware accelerated cairo backend. Leverages GPU hardware as much as possible and minimizes CPU usage.

nathawes/swift 1

The Swift Programming Language

akyrtzi/indexstore-db 0

Index database library for use with sourcekit-lsp

akyrtzi/sourcekit-lsp 0

Language Server Protocol implementation for Swift and C-based languages

akyrtzi/swift 0

The Swift Programming Language

akyrtzi/swift-cmark 0

CommonMark parsing and rendering library and program in C

pull request commentapple/swift-syntax

Fixes typo by renaming CustomReflcatbleTests to CustomReflectableTests

@swift-ci Please test

maldahleh

comment created time in 35 minutes

push eventapple/swift

Argyrios Kyrtzidis

commit sha a9f497d20cdd1fee7953f762f4cd2fe032262026

[utils/swift_build_sdk_interfaces.py] Remove passing '-track-system-dependencies' when prebuilding modules from the interfaces Including all the system header dependencies and `stat`ing them all the time introduces significant performance overhead for normal compilation, and other features like code-completion, without being worth it in practice.

view details

Argyrios Kyrtzidis

commit sha 91a8a82c4fa6b0f9f1615a394ed9a297fe15e037

Merge pull request #34384 from akyrtzi/util-prebuild-modules-stop-system-depend-track [utils/swift_build_sdk_interfaces.py] Remove passing '-track-system-dependencies' when prebuilding modules from the interfaces

view details

push time in 5 days

delete branch akyrtzi/swift

delete branch : util-prebuild-modules-stop-system-depend-track

delete time in 5 days

PR merged apple/swift

[utils/swift_build_sdk_interfaces.py] Remove passing '-track-system-dependencies' when prebuilding modules from the interfaces

Including all the system header dependencies and stating them all the time introduces significant performance overhead for normal compilation, and other features like code-completion, without being worth it in practice.

+2 -3

2 comments

2 changed files

akyrtzi

pr closed time in 5 days

delete branch akyrtzi/indexstore-db

delete branch : warn-to-info

delete time in 5 days

push eventapple/indexstore-db

Argyrios Kyrtzidis

commit sha aaef40147bf651b3eef6bca2360bc3f303222323

[Database] Downgrade the "failed moving <directory> ..." to 'info' from 'warning', NFC

view details

Argyrios Kyrtzidis

commit sha 65405a51039aa4b30b4066987f70133a6f1579bd

Merge pull request #118 from akyrtzi/warn-to-info [Database] Downgrade the "failed moving <directory> ..." to 'info' from 'warning', NFC

view details

push time in 5 days

create barnchakyrtzi/indexstore-db

branch : warn-to-info

created branch time in 5 days

push eventakyrtzi/swift

Argyrios Kyrtzidis

commit sha a9f497d20cdd1fee7953f762f4cd2fe032262026

[utils/swift_build_sdk_interfaces.py] Remove passing '-track-system-dependencies' when prebuilding modules from the interfaces Including all the system header dependencies and `stat`ing them all the time introduces significant performance overhead for normal compilation, and other features like code-completion, without being worth it in practice.

view details

push time in 5 days

create barnchakyrtzi/swift

branch : util-prebuild-modules-stop-system-depend-track

created branch time in 5 days

PR opened apple/swift

[utils/swift_build_sdk_interfaces.py] Remove passing '-track-system-dependencies' when prebuilding modules from the interfaces

Including all the system header dependencies and stating them all the time introduces significant performance overhead for normal compilation, and other features like code-completion, without being worth it in practice.

+0 -1

0 comment

1 changed file

pr created time in 5 days

push eventapple/swift-syntax

Mattt

commit sha 498c4a5aa44c12aa8a70cad3cec249b36c2a072c

Replace unevaluated gyb values in documentation comments (#244)

view details

push time in 6 days

PR merged apple/swift-syntax

Replace unevaluated gyb values in documentation comments

Some of the documentation comments in SyntaxProtocol include unescaped GYB expressions (${node.name}), which appear to be a copy-paste error introduced in 65a49c426aeccfe8e5738a6fafad7c99ccaff6e5. This PR replaces them with the phrase "syntax node", to match the other documentation comments.

+3 -3

1 comment

1 changed file

mattt

pr closed time in 6 days

push eventapple/swift-syntax

Keith Smiley

commit sha f957158a9892ab517d9b0daa0de7e454e0fc4d98

Make DiagnosticEngine thread safe (#243) This allows consumers to emit diagnostics from multiple threads. Primarily motivated by https://github.com/apple/swift-format/pull/117

view details

push time in 6 days

PR merged apple/swift-syntax

Make DiagnosticEngine thread safe

This allows consumers to emit diagnostics from multiple threads.

Primarily motivated by https://github.com/apple/swift-format/pull/117

+31 -2

1 comment

1 changed file

keith

pr closed time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentapple/swift-syntax

Revert "Add Double and Int Convenience Properties (#239)"

This causes an error for valid UInt64 integer literals

To be more clear, this was causing a fatalError crash.

rintaro

comment created time in 12 days

delete branch akyrtzi/swift-llbuild

delete branch : walk-built-nodes-67816715

delete time in 12 days

push eventapple/swift

Argyrios Kyrtzidis

commit sha b848bf785dd95350508f7115d32d7f57ff5181d7

[parser lib build] For the "parser lib only" build, avoid building unnecessary llvm libraries that clangBasic brings

view details

Argyrios Kyrtzidis

commit sha 025322096785f252c3112fcaba9c34e03e9822bf

Merge pull request #34250 from akyrtzi/parser-lib-build-less-build [parser lib build] For the "parser lib only" build, avoid building unnecessary llvm libraries that clangBasic brings

view details

push time in 17 days

delete branch akyrtzi/swift

delete branch : parser-lib-build-less-build

delete time in 17 days

create barnchakyrtzi/swift

branch : parser-lib-build-less-build

created branch time in 17 days

push eventapple/swift

Argyrios Kyrtzidis

commit sha 771738c1eb7f55196ad4443eaa24abce85de11f2

[utils/build-parser-lib] Add '--no-install' option to skip installing.

view details

Argyrios Kyrtzidis

commit sha a665ba632a21bc4479c8410433c5b6af713d0def

Merge pull request #34248 from akyrtzi/build-parser-lib-no-install [utils/build-parser-lib] Add '--no-install' option to skip installing.

view details

push time in 17 days

delete branch akyrtzi/swift

delete branch : build-parser-lib-no-install

delete time in 17 days

create barnchakyrtzi/swift

branch : build-parser-lib-no-install

created branch time in 17 days

pull request commentapple/swift

[utils/build-parser-lib] Add '--no-install' option to skip installing.

@swift-ci smoke test

akyrtzi

comment created time in 17 days

delete branch akyrtzi/swift

delete branch : parser-lib-build-enhance

delete time in 17 days

PullRequestReviewEvent

create barnchakyrtzi/swift

branch : parser-lib-build-enhance

created branch time in 18 days

pull request commentapple/swift

[utils/build-parser-lib] Add an optional `--short-host` option for defining the host

@swift-ci smoke test

akyrtzi

comment created time in 18 days

push eventllvm/llvm-project

Ben Barham

commit sha fbb499ef255b77c5a3300543de88956b13e706b7

[AST] Fix crashes caused by redeclarations in hidden prototypes ObjCContainerDecl.getMethod returns a nullptr by default when the container is a hidden prototype. Callsites where the method is being looked up on the redeclaration's own container should skip this check since they (rightly) expect a valid method to be found. Resolves rdar://69444243 Reviewed By: akyrtzi Differential Revision: https://reviews.llvm.org/D89024

view details

push time in 18 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

push eventapple/swift

Argyrios Kyrtzidis

commit sha 73727051fa61fe48b12bfc72233cdf28d804f58f

[AST] Fix linker errors with the parser-only build

view details

Argyrios Kyrtzidis

commit sha 56bab66c2cd502bcf6caa31ce918dc8ca8b77661

Merge pull request #34187 from akyrtzi/parser-lib-build-fix-link-errors [AST] Fix linker errors with the parser-only build

view details

push time in 20 days

delete branch akyrtzi/swift

delete branch : parser-lib-build-fix-link-errors

delete time in 20 days

PR merged apple/swift

[AST] Fix linker errors with the parser-only build

Parser-only build avoids linking clangAST library.

+8 -0

3 comments

2 changed files

akyrtzi

pr closed time in 20 days

pull request commentapple/swift

[AST] Fix linker errors with the parser-only build

@swift-ci smoke test linux platform

akyrtzi

comment created time in 20 days

pull request commentapple/swift

[AST] Fix linker errors with the parser-only build

@swift-ci smoke test linux platform

akyrtzi

comment created time in 21 days

pull request commentapple/swift

[AST] Fix linker errors with the parser-only build

@swift-ci test linux platform

akyrtzi

comment created time in 21 days

pull request commentapple/swift

[AST] Fix linker errors with the parser-only build

@swift-ci smoke test

akyrtzi

comment created time in 21 days

PR opened apple/swift

[AST] Fix linker errors with the parser-only build

Parser-only build avoids linking clangAST library.

+8 -0

0 comment

2 changed files

pr created time in 21 days

create barnchakyrtzi/swift

branch : parser-lib-build-fix-link-errors

created branch time in 21 days

pull request commentapple/swift-syntax

Implement Additional Feedback on PR for SR-11580

@xwu would you be fine with making these simple changes for now (make the properties optional and remove must_uphold_invariant) so that at least we avoid potential crashes in the interface, and if you are able to outline in a forum post what do you recommend as an API I'd really appreciate it 🙏

vermont42

comment created time in 24 days

PullRequestReviewEvent

push eventapple/swift

Suyash Srijan

commit sha fd4b01f09a4137caca0f28741db3a35f0de3cb7f

[AST] Look through try expressions inside open existential expression's sub expression in 'getUnwrappedCurryThunkExpr()' (#32458)

view details

Argyrios Kyrtzidis

commit sha 5f803ee6457fd7c062c933e616c0fe17610a25c9

Merge pull request #34131 from MaxDesiatov/maxd/fix-SR-12994 AST: Fix assertions crash with try expressions (main branch cherry-pick)

view details

push time in 25 days

PR merged apple/swift

AST: Fix assertions crash with try expressions (main branch cherry-pick) r5.3

Look through try expressions inside open existential expression's sub expression in getUnwrappedCurryThunkExpr().

This cherry-picks #32458 to the 5.3 branch.

<!-- If this pull request resolves any bugs in the Swift bug tracker, provide a link: --> Resolves SR-12994.

+14 -2

1 comment

2 changed files

MaxDesiatov

pr closed time in 25 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentapple/indexstore-db

[tsan] Workaround uninstrumented library code

I'm wondering if we should just add the mutex unconditionally anyway, instead of diverging the code based on whether sanitizer is enabled or not? What do you think, are there performance concerns?

benlangmuir

comment created time in a month

pull request commentapple/swift-syntax

Implement Additional Feedback on PR for SR-11580

I know that this is a semantic property, but I would say that for the sake of usability, it would be alright to harness this semantic property. What do you think @xwu and @akyrtzi?

That would require that we change the parser to make overflowing literals syntactically invalid. But I don't think that is appropriate, I'd recommend that we adhere to what is valid syntax and avoid bringing in semantic/code-generation concepts.

vermont42

comment created time in a month

pull request commentapple/swift-cmark

Fix SR-13534: fix normalize_html test

Thank you for looking into this! 🙏 But we intend swift-cmark to be a fork of commonmark/cmark that we primarily use for release management, not for making cmark-specific fixes.

Such fixes should go to commonmark/cmark, and once committed create a PR to bring the fork up-to-date against upstream cmark.

Interfere

comment created time in a month

Pull request review commentapple/swift-syntax

Add Double and Int Convenience Properties

+//===- SyntaxConvenienceMethods.swift - Convenience funcs for syntax nodes ===//+//+// This source file is part of the Swift.org open source project+//+// Copyright (c) 2014 - 2020 Apple Inc. and the Swift project authors+// Licensed under Apache License v2.0 with Runtime Library Exception+//+// See https://swift.org/LICENSE.txt for license information+// See https://swift.org/CONTRIBUTORS.txt for the list of Swift project authors+//+//===----------------------------------------------------------------------===//++public extension FloatLiteralExprSyntax {+  var floatingValue: Double {+    return potentialFloatingValue!+  }++  fileprivate var potentialFloatingValue: Double? {+    let floatingDigitsWithoutUnderscores = floatingDigits.text.filter {+      $0 != "_"+    }+    return Double(floatingDigitsWithoutUnderscores)+  }+}++public extension IntegerLiteralExprSyntax {+  var integerValue: Int {+    return potentialIntegerValue!+  }++  fileprivate var potentialIntegerValue: Int? {+    let text = digits.text+    let (prefixLength, radix) = IntegerLiteralExprSyntax.prefixLengthAndRadix(text: text)+    let digitsStartIndex = text.index(text.startIndex, offsetBy: prefixLength)+    let textWithoutPrefix = text.suffix(from: digitsStartIndex)++    let textWithoutPrefixOrUnderscores = textWithoutPrefix.filter {+      $0 != "_"+    }++    return Int(textWithoutPrefixOrUnderscores, radix: radix)

I agree with @allevato, this "overflows" error is not even coming from typechecking, it's coming from SIL code generation. Many thanks to @xwu for catching this, I believe we need to make integerValue return an optional.

vermont42

comment created time in a month

PullRequestReviewEvent

push eventapple/swift

vermont42

commit sha c311e451951b28afacebae69107cef28e4af9e44

Implements SR-11580

view details

Argyrios Kyrtzidis

commit sha 493d56748e6820d70c2ec91fa0b7dd49a9bf7759

Merge pull request #33948 from vermont42/literal-values Update GYB Files for SwiftSyntax Double and Int Convenience Properties

view details

push time in a month

PR merged apple/swift

Update GYB Files for SwiftSyntax Double and Int Convenience Properties

This SwiftSyntax PR implements SR-11580, whose goal is to add convenience properties to get Double and Int values from FloatLiteralExprSyntax and IntegerLiteralExprSyntax, respectively. The SwiftSyntax PR requires certain changes to Node.py and ExprNodes.py in the main Swift repo. I have been using these changes locally, but SwiftSyntax-PR reviewer @ahoppen recommended that I create this PR to the main Swift repo for the purpose of CI testing.

+8 -3

1 comment

2 changed files

vermont42

pr closed time in a month

push eventapple/swift-syntax

Josh Adams

commit sha 94fc5ae3f34fac87380756b9c17ea7c6752a227b

Add Double and Int Convenience Properties (#239) * Implements SR-11580

view details

push time in a month

PR merged apple/swift-syntax

Add Double and Int Convenience Properties

Building on the work of @ahoppen on SR-11580, this PR adds convenience properties to get Double and Int values from FloatLiteralExprSyntax and IntegerLiteralExprSyntax, respectively.

The two new properties, floatingValue and intValue, use failable initializers of Double and Int: init?<S>(_ text: S) where S : StringProtocol and init?<S>(_ text: S, radix: Int) where S : StringProtocol. These initializers fail if the Strings passed in do not represent valid Doubles or Ints. The question arises: what should floatingValue and intValue return, if anything, if initialization fails? I considered the following possibilities, ultimately choosing the fourth.

  1. floatingValue could return Double.nan. This would make sense because, for example, "🍕.🌍" is truly not a number, floating-point or otherwise. The problem with this approach is that there is no corresponding Int.nan, which would prevent floatingValue and intValue from returning the same sort of value given invalid input. Decimal does have a nan value, so if intValue returned a Decimal rather than an Int, that would solve the problem, but I, as a consumer of the API, would find this counter-intuitive because "42" in a source file represents an Int, not a Decimal.

  2. The return types of floatingValue and intValue could be optional. If Double or Int initialization fails, floatingValue and intValue could therefore return nil. I preferred not to impose on API consumers the burden of unwrapping.

  3. The return types of floatingValue and intValue could be Result<Double, LiteralError> and Result<Int, LiteralError>, respectively. If Double or Int initialization fails, floatingValue and intValue could return .failure(.invalid). I preferred not to impose on API consumers the burden of switching on the returned value.

  4. The result of the Double or Int initialization can be force-unwrapped. This causes a crash if initialization fails. Crashing is considered harmful, though not by everyone. Force-unwrapping is the most convenient option for API consumers, which is why I chose it. I observe that force-unwrapping does appear elsewhere in SwiftSyntax, for example here, here, here, and here, and I suspect that the authors of this code made similar judgments about the convenience of force-unwrapping versus the crashing risk it imposes.

Feedback on this code occurred in this PR, which I closed due to a rebase error described here.

+316 -44

12 comments

20 changed files

vermont42

pr closed time in a month

PullRequestReviewEvent

pull request commentapple/swift-syntax

Add Double and Int Convenience Properties

apple/swift#33948

@swift-ci Please test

vermont42

comment created time in a month

pull request commentapple/swift-syntax

Add Double and Int Convenience Properties

The failures are because the generated files differ:

***************
*** 1080 ****
!   public init?(_ build: (inout FloatLiteralExprSyntaxBuilder) -> Void) {
--- 1080 ----
!   public init(_ build: (inout FloatLiteralExprSyntaxBuilder) -> Void) {

Does the swift repo PR need update?

vermont42

comment created time in a month

created tagapple/swift-syntax

tag0.50300.0

SwiftPM package for SwiftSyntax library.

created time in a month

delete branch akyrtzi/swift-syntax

delete branch : update-readme-for-5.3

delete time in a month

delete branch akyrtzi/swift-syntax

delete branch : 5.3-readme-for-5.3

delete time in a month

push eventapple/swift-syntax

Argyrios Kyrtzidis

commit sha 4ef4703fe5e845cb9818036bf8d6bb5257291a37

[readme] Update for 5.3

view details

Argyrios Kyrtzidis

commit sha 844574d683f53d0737a9c6d706c3ef31ed2955eb

Merge pull request #238 from akyrtzi/5.3-readme-for-5.3 [5.3][readme] Update for 5.3

view details

push time in a month

PR opened apple/swift-syntax

[5.3][readme] Update for 5.3
+1 -1

0 comment

1 changed file

pr created time in a month

create barnchakyrtzi/swift-syntax

branch : 5.3-readme-for-5.3

created branch time in a month

push eventapple/swift-syntax

Argyrios Kyrtzidis

commit sha 605fac3bea805ce25fc915c3f438aaa4c70201f3

[readme] Update for 5.3

view details

Argyrios Kyrtzidis

commit sha c6bbd1422b3fa68405bc0370e63c4198df425c3f

Merge pull request #237 from akyrtzi/update-readme-for-5.3 [readme] Update for 5.3

view details

push time in a month

create barnchakyrtzi/swift-syntax

branch : update-readme-for-5.3

created branch time in a month

PR opened apple/swift-syntax

[readme] Update for 5.3
+1 -1

0 comment

1 changed file

pr created time in a month

push eventapple/swift

Ben Rimmington

commit sha ba06cfacae2c5ea10f199bc68c943110b6b5c17d

[docs] Remove the /docs/Refactoring.md file

view details

Argyrios Kyrtzidis

commit sha 5f98d39dd4114eb02f2cdb661fc00247a4f4bef1

Merge pull request #33867 from benrimmington/docs-refactoring-placeholder [docs] Remove the /docs/Refactoring.md file

view details

push time in 2 months

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentapple/swift

[Serialization] Minor ModuleFile/ModuleFileSharedCore improvements

Nice improvement to avoid passing ExtendedValidationInfo to so many APIs! Is ExtendedValidationInfo still usable from other places or can it be moved to implementation detail of ModuleFileSharedCore?

rintaro

comment created time in 2 months

pull request commentapple/swift

[Serialization] Minor ModuleFile/ModuleFileSharedCore improvements

It's a bit unclear to me why we need the bits accessible from both ModuleFile and ExtendedValidationInfo. You are replacing the accesses from ExtendedValidationInfo with accesses from ModuleFile but then why do we need them in ExtendedValidationInfo and if we do need them, why add the accessors in ModuleFile and not initialize the ExtendedValidationInfo bits from the Core object?

rintaro

comment created time in 2 months

PullRequestReviewEvent

push eventapple/indexstore-db

woshiccm

commit sha 7223f30fb4de0052c4080376901a651416363b2e

add file include api

view details

woshiccm

commit sha 5a4e3ef11a4a798b23e51e15e02ca9925046d192

add file including api

view details

woshiccm

commit sha 55375de7407a4554bb9d4756bf067ded4f9fb9f3

add new api tests

view details

woshiccm

commit sha 4ae504b5fe44af67b14503148dd413ca7126034c

merge receivers and tests

view details

woshiccm

commit sha cbd377a0fe4098edfb8d82638aca09a355069aae

fix testFilesIncludes

view details

Argyrios Kyrtzidis

commit sha e093926dd78a64ae48329397d99d2c72b7443c5f

Merge pull request #109 from woshiccm/file-include-api add file include api

view details

push time in 2 months

PR merged apple/indexstore-db

Reviewers
add file include api
+102 -0

6 comments

4 changed files

woshiccm

pr closed time in 2 months

pull request commentapple/indexstore-db

add file include api

@swift-ci Please test

woshiccm

comment created time in 2 months

PullRequestReviewEvent

pull request commentapple/indexstore-db

add file include api

@woshiccm, there is a CI failure:

/Users/buildnode/jenkins/workspace/swift-indexstore-db-PR-macOS/branch-master/indexstore-db/Tests/IndexStoreDBTests/IndexTests.swift:317: error: -[IndexStoreDBTests.IndexTests testFilesIncludes] : XCTAssertEqual failed: ("["/Users/buildnode/jenkins/workspace/swift-indexstore-db-PR-macOS/branch-master/indexstore-db/Tests/INPUTS/MainFiles/main2.c", "/Users/buildnode/jenkins/workspace/swift-indexstore-db-PR-macOS/branch-master/indexstore-db/Tests/INPUTS/MainFiles/main1.c"]") is not equal to ("["/Users/buildnode/jenkins/workspace/swift-indexstore-db-PR-macOS/branch-master/indexstore-db/Tests/INPUTS/MainFiles/main1.c", "/Users/buildnode/jenkins/workspace/swift-indexstore-db-PR-macOS/branch-master/indexstore-db/Tests/INPUTS/MainFiles/main2.c"]")

This is because the order that the includes are received is not stable from run to run. Could you change the test so that it compares sorted lists?

woshiccm

comment created time in 2 months

pull request commentapple/indexstore-db

add file include api

@swift-ci Please test

woshiccm

comment created time in 2 months

PullRequestReviewEvent
more