profile
viewpoint

apple/swift 54793

The Swift Programming Language

apple/swift-evolution 11766

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

apple/swift-package-manager 8122

The Package Manager for the Swift Programming Language

llvm/llvm-project 7288

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-corelibs-foundation 4096

The Foundation Project, providing core utilities, internationalization, and OS independence

apple/swift-corelibs-libdispatch 1957

The libdispatch Project, (a.k.a. Grand Central Dispatch), for concurrency on multicore hardware

apple/swift-corelibs-xctest 871

The XCTest Project, A Swift core library for providing unit test support

apple/swift-llbuild 819

A low-level build system, used by Xcode and the Swift Package Manager

Pull request review commentllvm/circt

[FIRRTL] Deal with truncations before connects

 ParseResult FIRStmtParser::parseLeadingExpStmt(Value lhs, SubOpVector &subOps) {       parseOptionalInfo(info, subOps))     return failure(); -  if (kind == FIRToken::less_equal)+  if (kind == FIRToken::less_equal) {+    // Some operations, dshl for example, have implicit truncations, even in lo+    // firrtl.  Handle truncations in a connect here.+    if (lhs.getType() != rhs.getType()) {+      auto lhsType =+          lhs.getType().cast<FIRRTLType>().getPassiveType().dyn_cast<IntType>();+      auto rhsType =+          rhs.getType().cast<FIRRTLType>().getPassiveType().dyn_cast<IntType>();+      if (lhsType && rhsType && lhsType.hasWidth() && rhsType.hasWidth() &&+          lhsType.getWidthOrSentinel() < rhsType.getWidthOrSentinel()) {+        rhs = builder.create<TailPrimOp>(+            info.getLoc(),+            IntType::get(builder.getContext(), false,+                         lhsType.getWidthOrSentinel()),+            rhs, lhsType.getWidthOrSentinel());+        if (lhsType.isSigned()) // rhs is unsigned+          rhs = builder.create<AsSIntPrimOp>(info.getLoc(), lhsType, rhs);

I was thinking about turning this into a partial connect, but it seems like partial connects are suppose to be whole elements of structs or arrays, not some bits of a primitive type (that way lies madness!). If we can I'd like to keep distinct and clear partial connect semantics, thus inserting the truncation is seeming the correct thing.

darthscsi

comment created time in a minute

Pull request review commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

 Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-  Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) to expose elaborate behavior through a succinct interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to local variables and type properties, shattering the illusion that they helped realize in the first place when working with parameters. -### Memberwise initialization+Property wrappers attached to parameters have a wide variety of use cases. We present a few examples here. -Currently, property-wrapper attributes on struct properties interact with function parameters through the struct's synthesized memberwise initializer. However, property-wrapper attributes are _not_ supported on function parameters. This leads to complicated and nuanced rules for which type, between the wrapped-value type and the backing property-wrapper type, the memberwise initializer accepts.+### Argument validation -The compiler will choose the wrapped-value type to offer a convenience to the call-site when the property wrapper has an initializer of the form `init(wrappedValue:)` accepting the wrapped-value type, as seen here:+Both library developers and language users often need to assert their assumptions, for which `precondition(_:_:)` is often used:  ```swift-import SwiftUI---struct TextEditor {--  @State var document: Optional<URL>-  +enum Product {+  case plainSandwich +  case grilledCheeseSandwich +  case avocadoToast } --func openEditor(with swiftFile: URL) -> TextEditor {-  TextEditor(document: swiftFile) -  // The wrapped type is accepted here.+func buy(quantity: Int, of product: Product) {+  precondition(quanity >= 1, "Invalid product quanity.")+  +  if quantity == 1 {+    ...+  } } ``` -However, this can take flexibility away from the call-site if the property wrapper has other `init` overloads, because the call-site _cannot_ choose a different initializer. Further, if the property wrapper is explicitly initialized via `init()`, then the memberwise initializer will choose the backing-wrapper type, even if the wrapper supports `init(wrappedValue:)`. This results in unnecessary boilerplate at call-sites that _do_ want to use `init(wrappedValue:)`:+The above code is quite clear; it has, though, the obvious drawback that changing the the condition to be asserted or its error message requires significant effort as a precondition statement is individually written for each function and manually documented.++Furthermore, supposing the above is library code, we may want to test for our precondition while offering an easy-to-debug way. So, using `Validation` from [`ValidatedPropertyKit`](https://github.com/SvenTiigi/ValidatedPropertyKit) we can write:  ```swift-import SwiftUI+@propertyWrapper

Oh I see. I was confused because the function below this used Validated so I thought it was just a mistake, sorry! I do think it would be fine to use (a variation of) the Validated property wrapper from the package, but please feel free to change the name to whatever you think is best

filip-sakel

comment created time in 2 minutes

Pull request review commentllvm/circt

[rtl] Add basic dead wire elimination

 def ConnectOp : RTLOp<"connect", [InOutTypeConstraint<"src", "dest">]> {     ```     }]; -  let arguments = (ins InOutType:$dest, RTLValueType:$src);+  let arguments = (ins Arg<InOutType, "", [MemWrite]>:$dest, RTLValueType:$src);

They are being used to get CSE to delete read-only wires. Whether that should just be folded into the explicit code is a different question.

youngar

comment created time in 4 minutes

PR opened llvm/llvm-blog-www

Integration of libc++ and OpenMP packages into llvm-toolchain: Add my…

…self as an author

blogger didn't have this feature

+1 -1

0 comment

1 changed file

pr created time in 16 minutes

CommitCommentEvent

Pull request review commentcirct/images

Add CIRCT Dockerfile

+#!/usr/bin/env sh++git clone --depth 1 https://github.com/circt/circt.git+cd circt+git submodule update --init --depth 1++cd llvm

Sure. Will update in a rebase.

seldridge

comment created time in an hour

Pull request review commentcirct/images

Add CIRCT Dockerfile

+# CIRCT Utilities Container

Will do. I'll probably add one each for firtool, circt-opt, and circt-translate.

seldridge

comment created time in an hour

Pull request review commentcirct/images

Add CIRCT Dockerfile

+FROM alpine++RUN apk --no-cache add build-base clang cmake git ninja python3++COPY *.sh /tmp/+RUN cd /tmp && /tmp/circt.sh

Ah, cool. I didn't know this was how RUN worked (would've helped if I read the documentation... 😄). I can switch to the git commit hash approach.

There's probably a further optimization of making both the CIRCT and LLVM submodule hashes separate so that the latter can be cached if it didn't change. This is probably a future enhancement, though.

seldridge

comment created time in an hour

Pull request review commentcirct/images

Add CIRCT Dockerfile

+FROM alpine

Sure, I think that's fine. I had originally thought that this would be a minimal docker wrapper around CIRCT utilities, but it's fine if it's beefier. I was going to use this for other GitHub CI and I think packaging everything together (including Verilator) will work better there anyway.

seldridge

comment created time in an hour

push eventllvm/llvm-lnt

Danila Malyutin

commit sha 2e93cbd17fd5eb4b2e3773e5022186feac554d7c

[LNT] add __pycache__ to ignored files Fixes WARNING: ignoring item '__pycache__' ... warnings Differential Revision: https://reviews.llvm.org/D94775

view details

push time in 2 hours

push eventllvm/llvm-lnt

Danila Malyutin

commit sha 0982122b76efad15e244a18b42ce77de2a906140

[LNT] Fix F811 warnings Differential Revision: https://reviews.llvm.org/D94774

view details

push time in 2 hours

push eventllvm/llvm-lnt

Thomas Preud'homme

commit sha 9284050152ae4d9623a37dea2e7725f025d2c829

Ignore files generated by running tox Reviewed By: danilaml Differential Revision: https://reviews.llvm.org/D94758

view details

push time in 3 hours

Pull request review commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

 Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-  Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) to expose elaborate behavior through a succinct interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to local variables and type properties, shattering the illusion that they helped realize in the first place when working with parameters. -### Memberwise initialization+Property wrappers attached to parameters have a wide variety of use cases. We present a few examples here. -Currently, property-wrapper attributes on struct properties interact with function parameters through the struct's synthesized memberwise initializer. However, property-wrapper attributes are _not_ supported on function parameters. This leads to complicated and nuanced rules for which type, between the wrapped-value type and the backing property-wrapper type, the memberwise initializer accepts.+### Argument validation -The compiler will choose the wrapped-value type to offer a convenience to the call-site when the property wrapper has an initializer of the form `init(wrappedValue:)` accepting the wrapped-value type, as seen here:+Both library developers and language users often need to assert their assumptions, for which `precondition(_:_:)` is often used:

@hborla Do you think the language is appropriate here? Any suggestion is welcome!

filip-sakel

comment created time in 3 hours

Pull request review commentapple/swift-evolution

[Proposal Revision] Extend property wrappers to functions and closure parameters.

 Property Wrappers were [introduced in Swift 5.1](https://github.com/apple/swift-  Property wrappers have undoubtably been very successful. Applying a property wrapper to a property is enabled by an incredibly lightweight and expressive syntax. For instance, frameworks such as [SwiftUI](https://developer.apple.com/documentation/swiftui/) and [Combine](https://developer.apple.com/documentation/combine) introduce property wrappers such as [`State`](https://developer.apple.com/documentation/swiftui/state), [`Binding`](https://developer.apple.com/documentation/swiftui/binding) and [`Published`](https://developer.apple.com/documentation/combine/published) to expose elaborate behavior through a succinct interface, helping craft expressive yet simple APIs. However, property wrappers are only applicable to local variables and type properties, shattering the illusion that they helped realize in the first place when working with parameters. -### Memberwise initialization+Property wrappers attached to parameters have a wide variety of use cases. We present a few examples here. -Currently, property-wrapper attributes on struct properties interact with function parameters through the struct's synthesized memberwise initializer. However, property-wrapper attributes are _not_ supported on function parameters. This leads to complicated and nuanced rules for which type, between the wrapped-value type and the backing property-wrapper type, the memberwise initializer accepts.+### Argument validation -The compiler will choose the wrapped-value type to offer a convenience to the call-site when the property wrapper has an initializer of the form `init(wrappedValue:)` accepting the wrapped-value type, as seen here:+Both library developers and language users often need to assert their assumptions, for which `precondition(_:_:)` is often used:  ```swift-import SwiftUI---struct TextEditor {--  @State var document: Optional<URL>-  +enum Product {+  case plainSandwich +  case grilledCheeseSandwich +  case avocadoToast } --func openEditor(with swiftFile: URL) -> TextEditor {-  TextEditor(document: swiftFile) -  // The wrapped type is accepted here.+func buy(quantity: Int, of product: Product) {+  precondition(quanity >= 1, "Invalid product quanity.")+  +  if quantity == 1 {+    ...+  } } ``` -However, this can take flexibility away from the call-site if the property wrapper has other `init` overloads, because the call-site _cannot_ choose a different initializer. Further, if the property wrapper is explicitly initialized via `init()`, then the memberwise initializer will choose the backing-wrapper type, even if the wrapper supports `init(wrappedValue:)`. This results in unnecessary boilerplate at call-sites that _do_ want to use `init(wrappedValue:)`:+The above code is quite clear; it has, though, the obvious drawback that changing the the condition to be asserted or its error message requires significant effort as a precondition statement is individually written for each function and manually documented.++Furthermore, supposing the above is library code, we may want to test for our precondition while offering an easy-to-debug way. So, using `Validation` from [`ValidatedPropertyKit`](https://github.com/SvenTiigi/ValidatedPropertyKit) we can write:  ```swift-import SwiftUI+@propertyWrapper

ValidatedPropertyKit already defines a @Validated wrapper, hence my naming @Asserted. I tried to avoid reusing that name so as to avoid confusion. I think 'Asserted' could definitely be improved. Do you have any other ideas for a name?

filip-sakel

comment created time in 3 hours

push eventllvm/mlir-www

github-actions[bot]

commit sha 47f992e9e95588b40e72c96aeab3dfde3667adc0

deploy: 88bbb851a906c631a6cd22f9c68eaa6aaaed12d2

view details

push time in 4 hours

push eventllvm/mlir-www

github-actions[bot]

commit sha 6405930fd25f6269bdc308425753c7d53596480f

deploy: 88bbb851a906c631a6cd22f9c68eaa6aaaed12d2

view details

push time in 8 hours

pull request commentllvm/circt

[FIRRTL] Remove node name attribute by adding fancy directive

RTL dialect that can do the same thing (rtl.wire). Sounds good. Where should I put the implementation of parse/printImplicitSSAName?

uenoku

comment created time in 9 hours

Pull request review commentllvm/circt

[FIRRTL] Remove node name attribute by adding fancy directive

 def NodeOp : FIRRTLOp<"node", [NoSideEffect, SameOperandsAndResultType]> {   let arguments = (ins PassiveType:$input, OptionalAttr<StrAttr>:$name);   let results = (outs FIRRTLType:$result); -  let assemblyFormat = "$input attr-dict `:` type($input)";+  let assemblyFormat = "$input custom<Fancy>(attr-dict) `:` type($input)";

Thanks. I changed it.

uenoku

comment created time in 9 hours

push eventllvm/llvm-www

Tom Stellard

commit sha 365470a4910d03c1cf73dd278421814234868382

Add 11.0.1 release and update release schedule

view details

push time in 10 hours

push eventllvm/www-releases

Tom Stellard

commit sha 0d7bbc9ee36a918a57f09c55b614e9ad2faffa42

Add 11.0.1 release

view details

push time in 11 hours

push eventllvm/mlir-www

github-actions[bot]

commit sha 2101688d10b869390722bae4f62c1c0fcc698847

deploy: 88bbb851a906c631a6cd22f9c68eaa6aaaed12d2

view details

push time in 12 hours

pull request commentcirct/images

Add CIRCT Dockerfile

Thanks for the feedback, @teqdruid! I think this is fine if it lives here. I'll get this updated to address your comments.

seldridge

comment created time in 12 hours

issue commentllvm/circt

[FIRRTL] (dshl) error

dshl looks a-okay. And while that is in the spec, I think you're thinking of the undocumented dshlw. That should only show up in "optimized low FIRRTL" and is an artifact of making the FIRRTL IR to Verilog mapping easier because FIRRTL and Verilog disagree about width behavior (life is very hard when you don't have multiple IRs... 😃).

drom

comment created time in 12 hours

push eventllvm/mlir-www

github-actions[bot]

commit sha f10cc0422bb4d2f154eafd8bc027dac0dfe48b35

deploy: 88bbb851a906c631a6cd22f9c68eaa6aaaed12d2

view details

push time in 15 hours

PR opened llvm/circt

[CAPI] Fix the windows build with #453 broke

#453 broke the Windows build!

@lattner Does this addition break your tests?

+1 -0

0 comment

1 changed file

pr created time in 15 hours

create barnchllvm/circt

branch : windows-fix

created branch time in 15 hours

Pull request review commentcirct/images

Add CIRCT Dockerfile

+FROM alpine++RUN apk --no-cache add build-base clang cmake git ninja python3++COPY *.sh /tmp/+RUN cd /tmp && /tmp/circt.sh

Docker stores a temporary image for each RUN so it can very quickly replay steps which it's already cached. The problem with that is it cannot tell if there are changes from the outside world which affect steps. So it's possible for this Dockerfile to run from an older cached version instead of re-running this script. I don't think this would happen in the GH workflow since I don't think they cache images between runs, but this behavior may change in the future for efficiency's sake. (Pulling down Docker images for each of the builds which happen in docker containers is probably quite costly.)

I would suggest adding a git commit hash parameter to this Dockerfile indicating the circt commit you want to build, inlining the circt.sh script, and cloning the requested commit. In the workflow, you'd have to get the commit from circt/main and pass it into docker build

seldridge

comment created time in 16 hours

Pull request review commentcirct/images

Add CIRCT Dockerfile

+#!/usr/bin/env sh++git clone --depth 1 https://github.com/circt/circt.git+cd circt+git submodule update --init --depth 1++cd llvm

I'd suggest using the script in circt purely for consistency's sake. We've validated when building with that script...

seldridge

comment created time in 16 hours

Pull request review commentcirct/images

Add CIRCT Dockerfile

+FROM alpine

Given that the llvm/circt builds are based on Ubuntu 20.04, we should probably stick with that. Actually, why not base this on the integration image? That way we'd get versions of Verilator, capnp, and yosys which have already been "validated" by the circt integration tests.

seldridge

comment created time in 16 hours

Pull request review commentcirct/images

Add CIRCT Dockerfile

+# CIRCT Utilities Container

Docker run commands are soooo boilerplate and cumbersome. You may want to provide some scripts like this example. For instance, start the docker container, run a particular command, and "do the right thing".

seldridge

comment created time in 16 hours

more