text:
Warning for Documentation.docc: found 1 file(s) which are unhandled; explicitly declare them as resources or exclude from the target

Building a swift package that has swift-algorithms as dependency outputs warning in the terminal
Swift Algorithms version: 1.2.0
Swift version:
swift-driver version: 1.115 Apple Swift version 6.0 (swiftlang-6.0.0.9.10 clang-1600.0.26.2)
Target: arm64-apple-macosx15.0

Checklist

[ ] If possible, I've reproduced the issue using the main branch of this package
[x] I've searched for existing GitHub issues

I see this issue is closed https://github.com/apple/swift-algorithms/pull/237 but I don't see the exclude argument in the main branch as suggested in that issue.
Steps to Reproduce
Build the Hummingbird template project https://github.com/hummingbird-project/template
Expected behavior
No warning for package documentation
Actual behavior
warning: 'swift-algorithms': found 1 file(s) which are unhandled; explicitly declare them as resources or exclude from the target
    /Users/atacan/Developer/Repositories/speech-router-hb/.build/checkouts/swift-algorithms/Sources/Algorithms/Documentation.docc

Just chiming in to say I also get this on everyone of my builds and was about to file an issue 😛

authors: atacan dimitribouniol

repo: apple/swift-algorithms


text:
[OrderedSet] Tiny doc fixes for isSuperset.

OrderedSet's documentation mistakenly refers to the subset relation when explaining what isSuperset is doing.
Checklist

[X] I've read the Contribution Guidelines
[X] My contributions are licensed under the Swift license.
[X] I've followed the coding style of the rest of the project.
[ ] I've added tests covering all new code paths my change adds to the project (if appropriate).
[ ] I've added benchmarks covering new functionality (if appropriate).
[X] I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions.
[X] I've updated the documentation if necessary.

@swift-ci test

source: gharchive/pull-request

repo: apple/swift-collections

license_type: permissive

license_source: github-api


text:
[Windows] Search for Dlls in Bundles Properly

On Windows, dlls don't begin with "lib" so the tests should be searching
for "MyDLL.dll", not "libMyDLL.dll"

@swift-ci please test and merge

repo: apple/swift-corelibs-foundation


text:
SR-11926: [FileHandle] Ensure the Darwin compatibility of Access Control of new methods.

From Swift 5.0, new APIs of FileHandle are introduced.
While they are defined as open in DarwinFoundation (as you know they are imported from objc), they are public in SwiftFoundation.
They should be defined as open also in SwiftFoundation to ensure compatibility (for example, making subclasses of FileHandle in other modules).
Resolves SR-11926.

Note that at least some of these changes are incorrect. e.g.: write(contentsOf:) is public, not open, on Darwin.

It seems to come to a conclusion.
Unfortunately, I'm going to close this PR.

authors: YOCKOW millenomi


text:
[Caching] Fix incremental cache build with bridging header

When planning a caching build with bridging header, the consumer of the pre-compiled bridging header needs to know the cache key for the bridging header in order to construct the correct build command, which requires visibility to the job that creates PCH.
Fix the incremental planning for bridging header users so those job can be correctly constructed even the bridging header job is skipped for the incremental build.
rdar://118143215

@swift-ci please test

repo: apple/swift-driver

license_source: bigquery


text:
Improve libswiftReflection Linking on Linux

Using CMAKE_SYSTEM_PROCESSOR is a good first step, but for platforms where it maps to something different (say, armv7l to armv7), then you need more complete logic. Ideally, we would want Swift itself to tell us what to link against, but this change is still an improvement, although it is blatantly reusing similar logic from Swift's cmake scripts.

This is definitely better.

@swift-ci test and merge

authors: Kaiede dcci

repo: apple/swift-lldb


text:
fix macOS build & cleanup Thread

Motivation:
The macOS build was broken by #1424, also the Thread.swift file became
a bit of a mess with #if os(...)/#else everywhere.
Modifications:

fix macOS build
cleanup Thread by splitting it into ThreadPosix & ThreadWindows

Result:

build working again
cleaner code

@swift-nio-bot test this please

repo: apple/swift-nio


text:
ByteBuffer.viewBytes now returns an Optional

Motivation:
ByteBuffer.viewBytes would unconditionally return a ByteBufferView even
if the requested bytes were not readable.
Modifications:

make it return an Optional<ByteBufferView>

Result:

safer, better APIs
fixed #877

@swift-nio-bot test this please


text:
Emit a descriptive error when running the generator on iOS, tvOS, or watchOS

The _OpenAPIGeneratorCore library and swift-openapi-generator executable are mostly an implementation detail of the OpenAPIGenerator plugin, all vended by the swift-openapi-generator package.
The generator runs at build time to generate code, but the _OpenAPIGeneratorCore library shouldn't actually be linked by adopters's target, which is documented correctly here (Step 7 of https://swiftpackageindex.com/apple/swift-openapi-generator/0.1.3/tutorials/swift-openapi-generator/clientxcode#Configuring-your-target-to-use-the-Swift-OpenAPI-Generator-plugin), but it's also easy to get it wrong and link it when adding the package in Xcode.
We should make it so that a clear, descriptive error is emitted when someone links the generator module itself to a non-macOS/Linux target.

One example question on the developer forums: https://developer.apple.com/forums/thread/732178

source: gharchive/issue

repo: apple/swift-openapi-generator


text:
Tests Fail to link on Windows when macros are present, jeopardizing Swift's cross-platform support.

Description
Tests fail to link on Windows using swift 5.9.1-RELEASE when macros are present.
This is a trivial repo that reproduces the issue:
https://github.com/lynchsft/swift-windows-macro-testing
The locus of this problem is on Windows platform, but I conclude that it indirectly negatively affects the entire Swift community. As macros proliferate through common libraries, all swift-on-windows tools will either have to abandon testing or wholly abandon windows as a platform. Neither of these outcomes speaks well of the "swift is a cross platform language" story.
Particularly, I'm asserting that this is a rapidly worsening problem because library authors that don't usually concern themselves with Windows are eagerly adopting macros feature. Soon, the libraries that Windows projects currently rely on will be un-ingestiable, effectively locking our dependences at the last-macro-free version.
This in turn, is a security problem as code-currency (up-to-date dependencies) are a crucial topic for averting and responding to security threats.
@neonichu, @MaxDesiatov During construction of that ^^ trivial reproduction repo, I actually encountered a success case, where I WAS able to ingest a macro and use it on Windows. The linker error did not arise.
Including this state in case its a useful resource to have.
Branch: success_case
Repo: https://github.com/lynchsft/swift-windows-macro-testing
Expected behavior
The tests should link and run properly.
Actual behavior
The tests fail to link (compilation succeeds):
Building for debugging...
lld-link: error: duplicate symbol: main
>>> defined at C:\Users\lynchsft\swift-windows-macro-testing\.build\x86_64-unknown-windows-msvc\debug\PowerAssertPlugin.build\PowerAssertPlugin.swift.o
>>> defined at C:\Users\lynchsft\swift-windows-macro-testing\.build\x86_64-unknown-windows-msvc\debug\SwiftWindowsPackageTestingPackageTests.build\runner.swift.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[238/239] Linking C:\Users\lynchsft\swift-windows-macro-testing\.build\x86_64-unknown-windows-msvc\debug\SwiftWindowsPackageTestingPackageTests.xctest
error: fatalError

Steps to reproduce
swift --test
Swift Package Manager version/commit hash
5.9.1-RELEASE
Swift & OS version (output of swift --version ; uname -a)
Swift version 5.9.1 (swift-5.9.1-RELEASE)
Target: x86_64-unknown-windows-msvc
MSYS_NT-10.0-22631 lynchal-z01 3.4.6.x86_64 2023-05-18 20:39 UTC x86_64 Msys

Is this reproducible for you with latest development snapshots? (at the moment of writing it's https://download.swift.org/development/windows10/swift-DEVELOPMENT-SNAPSHOT-2023-11-27-a/swift-DEVELOPMENT-SNAPSHOT-2023-11-27-a-windows10.exe)

It is reproducible with the latest snapshot:
> swift --version
Swift version 5.11-dev (LLVM d50917983d84235, Swift 3f06b5efd0ebcfb)
Target: x86_64-unknown-windows-msvc

I have a slightly different example though:
https://github.com/tishin/MacroTestIssue
It has two targets - an empty macro implementation target with a @main attribute (which I believe causes this issue)
import SwiftCompilerPlugin
import SwiftSyntaxMacros

@main
struct MyMacroPlugin: CompilerPlugin {
    let providingMacros: [Macro.Type] = [
    ]
}

And a trivial test target:
import XCTest

final class MyMacroTests: XCTestCase {
    func testMacro() throws {
        XCTAssertTrue(true)
    }
}

Running swift test -v using the latest snapshot (as well as 5.9.2 release) fails with the duplication error:
lld-link: error: duplicate symbol: main
>>> defined at C:\Projects\MacroTestIssue\.build\x86_64-unknown-windows-msvc\debug\MyMacroMacros.build\MyMacroMacro.swift.o
>>> defined at C:\Projects\MacroTestIssue\.build\x86_64-unknown-windows-msvc\debug\MyMacroPackageTests.build\runner.swift.o

Thank you @tishin .
@MaxDesiatov, @neonichu Are you able to provide a read on the situation? Have I concluded wrongly that as time goes on this bug will strand Windows projects in the past?

authors: MaxDesiatov lynchsft tishin

repo: apple/swift-package-manager


text:
[Workspace] Use topological sort when creating DependencyManifests

rdar://problem/43700179 isResolutionRequired is non-deterministic when a graph contains both revision and version based dependency requirements

Need to write a test for this

@swift-ci smoke test


text:
[bootstrap] Remove deprecated "--build-tests"

The "--build-tests" option is marked "deprecated" in the SwiftPM bootstrap script and is no longer used by the script. It is also no longer used by any systems calling the bootstrap script; its only usage in the Swift build script has been removed in https://github.com/apple/swift/pull/1547.
Remove the option to reduce confusion.

This is trivial and safe change so I'm going to merge it.
I've tested that  ./Utilities/bootstrap test works as expected both on MacOS and Linux and we don't need  "--build-tests"

Thanks, @kostiakoval! :bow:

authors: kostiakoval modocache


text:
Binary targets workspace implementation

This implements the download and unarchiving implementation of the binary targets proposal.

I have several diagnostics in the PR reported using the emit(error: "description of error") instead of emit(.errorName(arguments)). I thought the second form was preferred, but I also saw a few instances of the first form using in Workspace. @aciidb0mb3r what do you think?

@hartbit The string variant is ok for one-off cases where we don't need to emit the same error from somewhere else but emit(.errorName(arguments)) is probably better/preferable.

@swift-ci smoke test self hosted

@swift-ci smoke test


text:
Parser should emit a single diagnostic if both open and close quote are missing from string literal

Issue Kind
Bad Diagnostic Produced
Source Code
@_expose(Cxx, baz) func foo() {}

Description
From https://github.com/apple/swift-syntax/pull/1688/files#r1201105564
In the above example the parser produces two diagnostics: One for the missing opening " before baz and one for the missing closing " after baz. It should emit a single diagnostic instead that offers to add both.

Tracked in Apple’s issue tracker as rdar://109685043

Go for it @TTOzzi 🙌

Thank you! 😉

authors: TTOzzi ahoppen kimdv

repo: apple/swift-syntax


text:
Complete WebAssembly/WASI Support

Motivation:
Trying to support WebAssembly/WASI before shipping swift-testing as a part of toolchain
Modifications:
Thanks to prior WASI compatibility efforts by @grynspan, most of the parts work as is now. Here are a few items I changed:

Remove SWT_NO_FILE_IO definition since wasi-libc provides all IO functionalities we need
Stop including signal.h
Fix metadata accessor function pointer representation on WASI to use absolute pointer instead of relative pointer
Define primitive lock type as Void for WASI
It's not the optimal representation but I couldn't find a better way 😓

Result:
Tested with DEVELOPMENT-SNAPSHOT-2024-07-15-a toolchain
$ swift sdk install https://github.com/swiftwasm/swift/releases/download/swift-wasm-DEVELOPMENT-SNAPSHOT-2024-07-16-a/swift-wasm-DEVELOPMENT-SNAPSHOT-2024-07-16-a-wasm32-unknown-wasi.artifactbundle.zip

$ swift package init --name Hello --enable-experimental-swift-testing
# Replace swit-testing dependency entry in Package.swift with:
#   .package(url: "https://github.com/kateinoigakukun/swift-testing.git", branch: "yt/wasi-support"),

$ swift build --swift-sdk DEVELOPMENT-SNAPSHOT-2024-07-16-a-wasm32-unknown-wasi --build-tests --enable-experimental-swift-testing
$ wasmkit-cli run --dir . ./.build/debug/HelloPackageTests.wasm
◇ Test run started.
↳ Testing Library Version: 3702b3a53779ccca0f8205b7a76a6f5038197120
◇ Test example() started.
✔ Test example() passed after 0.041244319 seconds.
✔ Test run with 1 test passed after 0.081816901 seconds.

Checklist:

[x] Code and documentation should follow the style of the Style Guide.
[x] If public symbols are renamed or modified, DocC references should be updated.

@swift-ci test

Thanks for taking a look at all this! We really appreciate it. :)

@swift-ci test

One other thing! Can you modify the project readme to include this line in the supported OS table? 😁
| **Wasm** | | | Experimental |

@swift-ci please test

Ready to merge when you are.

⛵

authors: grynspan kateinoigakukun

repo: apple/swift-testing


text:
Move build-script apply default arguments into separate module

Purpose
This PR moves the apply_default_arguments logic out of the main build-script code into the driver_arguments module in order to better stage for #11872 and eventually #11880. The diff will show that the move was not strictly a copy-paste, the chunk for determining if ninja ought be built requires the toolchain information which only exists in the BuildScriptInvocation class. I've opted instead to single out that single case and keep it where it was, everything else was moved verbatim.
rdar://problem/34336890

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

As soon as the builds for this branch pass I'll merge it, then onwards to #11872!

This broke the build-script on my machine. It can no longer find ninja in /usr/local/bin. What do you need to help debug this?

@davezarzycki I've made a PR to address the issue #11919. I'll have it merged tonight or in the morning, Sorry for the inconvenience.

Can you unsubscribe me from this email service cause I don’t want any
emails from git hub
On Thu, Sep 14, 2017 at 11:32 AM Ross Bayer notifications@github.com
wrote:

@davezarzycki https://github.com/davezarzycki I've made a PR to address
the issue #11919 https://github.com/apple/swift/pull/11919. I'll have
it merged tonight or in the morning, Sorry for the inconvenience.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/apple/swift/pull/11882#issuecomment-329382112, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQ86b_vQseMcea4728BLdWX66v9Jcs63ks5siMF0gaJpZM4PVPK6
.

@tishansteve You can change your email preferences in your Github account settings. I can't do anything about it.

authors: Rostepher davezarzycki tishansteve

repo: apple/swift


text:
Add useSnakeCasedKeys to JSONDecoder.KeyDecodingStrategy

Adds JSONDecoder.KeyDecodingStrategy.useSnakeCasedKeys.
This will make following code works.
import Foundation

struct S: Codable {
    var myURLProperty: String
}

let encoder = JSONEncoder()
encoder.keyEncodingStrategy = .convertToSnakeCase
let data = try encoder.encode(S(myURLProperty: "property"))
let decoder = JSONDecoder()
decoder.keyDecodingStrategy = .useSnakeCasedKeys
let decoded = try decoder.decode(S.self, from: data)

/cc: @itaiferber

Resolves SR-6629.

@itaiferber For what's its worth, I tried using convertToSnakeCase/convertFromSnakeCase for the first time today and was really surprised that the behaviour was not what @norio-nomura is proposing. Converting the CodingKeys to snake_case instead of converting the JSON keys to camelCase seems like the only solution to avoid all those round-trip errors.

@hartbit @norio-nomura I forgot to update this PR (and the SR) with some additional discussion and notes for thought. Even if we decide to special-case convertToSnakeCase and convertFromSnakeCase here and perform the conversions in the "favorable" direction, there are still other cases which can't necessarily be fixed.
Consider KeyedDecodingContainer<Key>.allKeys, which maps the contents of what is in the payload to a list of Keys. This is done by iterating the keys in the payload and creating a Key with the value of every found key via CodingKey.init?(stringValue:).
Right now, we do this by having two conversions — Key-to-String (Key.stringValue → case conversion) and String-to-Key (case conversion → Key.init?(stringValue:)). If we "fix" the issue by only using Key-to-String conversions as suggested, there's no real way to map from something already in the payload to a Key. One way to do this could be to require all CodingKeys to be CaseIterable and on every request for allKeys, take Key, iterate every case, converts every key to a string, applies the case conversion, and then iterate all of the keys in the payload and try to look them up in the converted table. This is both expensive, and not necessarily possible as not all CodingKeys can be CaseIterable (think _DictionaryCodingKey and other dynamic keys).
We could decide to "fix" this but still leave allKeys as-is, but this is still bad because you can't rely on iterating through allKeys to really know what's in the payload.

And at that, this is a special case for convertToSnakeCase/convertFromSnakeCase; we could not apply this to strategies which are even more lossy (e.g. .custom, for which we really only have one direction of conversion). There's a balance here between doing the "right" (i.e. magic) thing for some API consumers and being consistent.
One thing to keep in mind, I think, is that these conversions are by nature lossy. There are always going to be edge cases where we've lost too much information to round-trip the keys. The question is where is the balance between preserving more cases and being consistent across the board. I currently favor being consistent here.

Seems like a loose-loose situation where there is not great solution.

One way to do this could be to require all CodingKeys to be CaseIterable and on every request for allKeys, take Key, iterate every case, converts every key to a string, applies the case conversion, and then iterate all of the keys in the payload and try to look them up in the converted table.

Couldn't KeyedDecodingContainer cache the converted keys?
How about special casing the snake_case to camelCase conversion to recognise common abbreviations often found in Swift code and uppercasing them as the naming conventions suggests? The obvious that come to mind are: HTTP, URL, UUID, XML, JSON

Yes, caching is possible, though unfortunately this doesn't solve the problem for keys which are not iterable.
Recognizing special words is certainly an option (and can be done transparently without updated API); the question is — what abbreviations are important enough to make it into that list? 🙂 All the ones you listed, I agree with. If we're doing HTTP, should we do HTTPS? (And what about other schemes?) It gets a bit hairier... What if people have other abbreviations they want that are not on our list? One option is to make an extensible list of known initialisms that anyone can extend in their process and just do that.
(I'm not trying to say that just because there isn't a "best" solution we shouldn't do anything; it's just about trying to figure out the best way going forward.)
Another solution is simply exposing JSONEncoder.KeyEncodingStrategy.toSnakeCase() and JSONDecoder.KeyDecodingStrategy.fromSnakeCase() and letting folks more easily do what they need to in .custom conversions.

I noticed another problem as a consequence of the current behaviour: resolving the round-trip issue in @norio-nomura's example requires giving the CondingKey a rawValue of myUrlProperty. I think this is very unintuitive and not easily discoverable as no domain (wether the Swift domain or JSON domain) ever declares a key with the value myUrlProperty: it feels outlandish to both domains.
The more I think about it the more I think that @norio-nomura's useSnakeCasedKeys has to be part of the solution, whatever the cost is of resolving KeyedDecodingContainer. By the way, isn't KeyedDecodingContainer.keys invisible to users to JSONEncoder and JSONDecoder? Can't we just return an empty array?

No, we can't do that, unfortunately. JSONDecoder.container(keyedBy:) returns a KeyedDecodingContainer, which exposes allKeys. That value has to be consumable for types which iterate through the possible keys in the payload in order to decide how to decode; we can't simply return an empty array for the benefit of making these edge cases work.
Perhaps we should take this to the Swift Forums for discussion on possible ways forward. At this point, we're not going to be able to introduce new API into Swift 4.2, but maybe there are other directions we can take this.

I started a thread on the Swift forums to discuss this in a more public setting. :)

Thx @itaiferber! Would it worth moving the discussion to Swift Evolution?

I think it would be good to gather feedback first about potential directions before suggesting API to Swift Evolution, but eventually, yes

Was any conclusion on the issue reached through the discussion?

There were three responses to the thread, all supportive of this approach; if we consider that to be enough signal to go ahead with this, we'll need to figure out how we want to review and schedule this API change. Given the amount of things going on at the moment, I'm not sure this will make the 4.2 release.
@parkera Any thoughts here?

Let's aim for 5.0. master is still the branch for that, but since we need time to do additional API review here, we will leave this open for a bit longer.

Hi there. I hope that it is ok that I bump this thread.
@parkera you mention that you hope to aim for 5.0. Now that we are nearing 5.0 do you think that there is any hope that this could make it?

Any updates on this? Could we merge this and cherry pick into 5.1 perhaps? Seems like there's a lot of support for this so it would be a shame if this gets abandoned.

Any changes made here would need to go through API review, which won't make it into Swift 5.1, unfortunately. We will try to push on this internally, given bandwidth.

Okay! I hope it makes into Swift 5.2 then :)

FYI, I opened https://github.com/jpsim/Yams/pull/200 as PoC that improved from this PR.

It's been a while, so let's get this moving again.  Because this change is API and ABI breaking (not that I anticipate there are many clients switching over this enum), it requires a formal proposal to Swift evolution.  During that process, it's possible you may hear from the core team that this change is OK to take without a formal review.  Luckily, you've already done the heavy lifting by providing an implementation.
I'm going to tag this as pending evolution discussion.

@codafi Since JSONDecoder does not live in the standard library, this should not require full Swift evolution, but does require Foundation review. /CC @parkera to weigh in on changes here

I have checked, and I stand corrected. The overlays are Foundation’s and are not subject to evolution.  Hopefully @parkera can get this reviewed in time.

cc @bendjones on this one

Can one of the admins verify this patch?

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

How to change the base branch: (Link)
More detail about the branch update: (Link)

Hi there,
Apologies for the bump, but unfortunately this PR was automatically closed - and I don't think it got the attention that it deserved.
The comments do mention internal reviews, so I am hoping that perhaps the issue is not yet off of the radar.
Otherwise: might I reopen a copy of the PR against main?
I am certain that the issue is very well understood, but I think that the current state causes a lot of confusion - even for experienced developers. The intention was to keep the key conversion in the encoder and decoder, but the current state is that this often 'leaks' into the CodingKey definition where you have to 'translate' something like imageURL to imageUrl for it to roundtrip to snake case correctly. I've seen quite a few bugs due to the misunderstanding that it would help to translate the key directly into snake case as:
  case imageURL = "image_url"

As mentioned elsewhere, the big issue is that the 'imageUrl' representation belongs neither to the source or the destination domains but must be added for the sake of the key coding strategy.
@parkera , @CodaFi , @bendjones

authors: CodaFi futurejones hartbit itaiferber mortenbekditlevsen norio-nomura parkera shahmishal theblixguy


text:
IRGen: adjust for LLVM API change

SVN r332881 introduced an additional parameter to emit a DWO file.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

CC: @bob-wilson


text:
[passmanager] Add the ability to verify before/after/around a specifi…

…c transform.
This helps speed up triaging failures caught by -sil-verify-all since this
allows one to trigger the -sil-verify-all verification around specific passes in
the pipeline rather than after every pass run. Was useful for me when tracking
down missing pass manager notification.

@swift-ci smoke test

Actually, I am going to centralize this logic a little bit before the review. Erik, I'll ping you again when I am ready.

I'm wondering what's the motivation for this. Is -sil-verify-all really too slow for debugging?

@eeckstein I found that the PassManagerNotificationVerificationAnalysis was too expensive to run with sil-verify-all since it has to run over all functions. I found an alternative solution (namely, verifyFull), but this seemed like generally useful functionality.

authors: eeckstein gottesmm


text:
Fix some edge cases when inlining coroutines

The current inlining strategy doesn't support inlining coroutines when there are multiple end_apply or abort_apply instructions in the caller, so refuse to inline such cases.  Also, handle the case where there are no yield instructions in the callee, which can happen if e.g. the callee calls a no-return function.
I also simplified the code somewhat by removing the vestiges of the code that tried to unify control flow with switches.
As an unrelated fix, suppress function signature optimization for coroutines for now.

Build failed
Swift Test Linux Platform
Git Sha - 8613761487ed929b51267d0473aa8ab488cfea69

@swift-ci Please clean test Linux.

authors: rjmccall swift-ci


text:
[runtime] enhanced and refactored recently added Mutex abstraction

added read / write lock support
added non-fatal error support to allow use of mutex in fatal error reporting pathway
isolated pthread implementation to it own header/cpp file pair
expanded unit tests to cover new code as well as better test existing mutex
removed a layer of complexity that added no real value
added static allocation friendly versions of Mutex, ConditionVariable, and ReadWriteLock

Resolved bug number: (SR-946)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

Looking at conflict now.

Not a review, just triggering the CI.
@swift-ci Please test

Offline until morning (PST).

Looks like both Linux and Mac passed thanks for the early CI run.

Think I dealt with most comments with an open question or two for folks. If possible getting a CI and benchmark run would be helpful.

@swift-ci Please test
@swift-ci Please benchmark

@swift-ci Please test

!!! Couldn't read commit file !!!

In addition to CI, some should verify that this doesn't introduce any additional -Wglobal-constructors or -destructors warnings.

Looks like a lingering use of Condition instead of ConditionVariable not sure why my local benchmark run didn't flag it.

This is not a review of anything in this patch, but when writing tests for your synchronization primitives please bear in mind that 1) sleeping for XX ms is not sufficient to always have all your threads started and 2)  gtest ASSERT_* macros won't force the test to stop running if they happen inside a thread, since they work by using 'return'.
I just fixed a race in the previous tests with fa77a7a.

Yeah that test has been reworked in this patch for that very reason. I had made a comment on the prior PR about that issue after it was reported to be seen on Linux.

I'm looking at Mutex::lockOrWait(). Its body is equivalent to below code, is it right?
template <typename CriticalSection>
   void lockOrWait(ConditionVariable &condition,
                   CriticalSection criticalSection) {
     lock([&] {
       while (!criticalSection()) {
         wait(condition);
       }
     });
   }

  lock();
  while (!criticalSection()) {
    ConditionPlatformHelper::wait(condition.Handle, Handle);
  }
  unlock();

According to their manuals, all three condition variable's wait function (pthread, <condition_variable>, Win32) release the associated lock. I think the second while loop will be running in unlocked.

Upon successful return, the mutex shall have been locked and shall be owned by the calling thread.
I believe the above is universal for condition wait behavior (quoted from http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html). You must hold the lock before calling wait, then before waiting (blocking calling thread) the wait function drops the lock, and before wait returns (assuming no error / timeout) it must reacquire the lock.

So while looping the lock is held except when inside of the wait call.

Oh I understand. I was wrong about pthread, <condition_variable>, but Win32 SleepConditionVariableSRW() may differ.

I see the following community addition to the docs about SleepConditionVariableSRW(). I would be very surprised if it didn't acquire the lock before returning.

Even after the wait time expires, this function does not return until it acquires the lock again no matter how long it takes. This thread must always release the lock regardless of the return value. The return value indicates that the conditional variable was set (true) or wait timed out (false + ERROR_TIMEOUT).

Yes, I confirmed with test code. It locks again !. MSDN document was poor. Thanks for reference.

I wrote MutexWin32.cpp(.h) and they passed your test code unittests/runtime/Mutex.cpp. It was very simple. Thanks you.

I think this is finally good to go. It will need a CI & benchmark before any attempt to merge.
I have held off removing ReadWriteLock::readWriteLock([]{}, []{}) for the moment since unlock got separated into readUnlock and writeUnlock in support of Win32 version of this code. The abstraction helps avoid mistakes with calling the wrong unlock (granted likely easily detected in testing) and of course avoids duplication of code in typical fast path / slow path type usage of read write locks. I will remove it folks want.

@swift-ci Please test
@swift-ci Please benchmark

@swift-ci Please test

!!! Couldn't read commit file !!!

@shawnce There's some linker heartburn:
Undefined symbols for architecture x86_64:
  "swift::Condition::notifyAll()", referenced from:
      __swift_allocBox_ in libswiftRuntime.a(HeapObject.cpp.o)
      _swift_getGenericMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getObjCClassMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getFunctionTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getTupleTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getExistentialMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      ...
  "swift::Condition::Condition()", referenced from:
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::BoxCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(HeapObject.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::ObjCClassCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::FunctionCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::TupleCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::MetatypeCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::GenericCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::WitnessTableCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      ...
  "swift::MutexImpl::lock()", referenced from:
      __swift_allocBox_ in libswiftRuntime.a(HeapObject.cpp.o)
      _swift_getGenericMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getObjCClassMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getFunctionTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getTupleTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getExistentialMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      ...
  "swift::MutexImpl::wait(swift::Condition&)", referenced from:
      __swift_allocBox_ in libswiftRuntime.a(HeapObject.cpp.o)
      _swift_getGenericMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getObjCClassMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getFunctionTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getTupleTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getExistentialMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      ...
  "swift::MutexImpl::unlock()", referenced from:
      __swift_allocBox_ in libswiftRuntime.a(HeapObject.cpp.o)
      _swift_getGenericMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getObjCClassMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getFunctionTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getTupleTypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      _swift_getExistentialMetatypeMetadata in libswiftRuntime.a(Metadata.cpp.o)
      ...
  "swift::MutexImpl::MutexImpl(bool)", referenced from:
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::BoxCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(HeapObject.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::ObjCClassCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::FunctionCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::TupleCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::MetatypeCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<(anonymous namespace)::ForeignTypeState>::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      swift::Lazy<swift::MetadataCache<(anonymous namespace)::GenericCacheEntry> >::defaultInitCallback(void*) in libswiftRuntime.a(Metadata.cpp.o)
      ...
ld: symbol(s) not found for architecture x86_64

@jckarter I spotted that I can't explain why that is happening. Can a plain CI run be done to confirm what I am seeing on my end (I don't see any linker issues, etc.). I will rerun benchmarks locally to confirm I see no issues (didn't see any last time).

@swift-ci Please test

@jckarter the issue looks specific to what the benchmark operation is doing. I can build --benchmark locally without issues. I suspect somehow a reference branch is being made from some invalid merge point that is resulting in a mix of old and new code trying to be compiled.
Any place I can look to see how a given CI build is setup, to understand the command executed, etc.?

@shahmishal Any idea why the benchmark runner would fail with linker errors when the normal CI works?

I looked the failed benchmark consol output https://ci.swift.org/job/swift-PR-osx-perf/35/console. I think the problem is in the ci build process.
The commit a0452be removed stdlib/public/runtime/Mutex.cpp and added stdlib/public/runtime/MutexPThread.cpp, but the benchmark compiled both.
It seems it tested without MutexPThread.cpp, and older source set. There is no MutexImpl class in current commit, isn't it?
[505/949] Building CXX object stdlib/public/runtime/CMakeFiles/swiftRuntime-macosx-x86_64.dir/Mutex.cpp.o
.....
[30/167] Building CXX object stdlib/public/runtime/CMakeFiles/swiftRuntime-macosx-x86_64.dir/MutexPThread.cpp.o
.....
"swift::MutexImpl::lock()", referenced from:

@shahmishal @jckarter Do the build commands exist in git someplace for what the benchmark CI plan does? ..or does a lot of that live in Jenkins? Would a new pull request potentially side step some state that may have a hand in an incorrect merge being used?

@swift-ci Please benchmark

@shawnce Benchmark bot:

Checkout master branch  (Targeted Branch)
run swift/utils/build-script -R --no-assertions --benchmark
Checkout origin/pr/1950/merge
run swift/utils/build-script -R --no-assertions --benchmark
Upload the results to GitHub pull request.

Build comment file:
Optimized (O)

Regression (1)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ClassArrayGetter
12
13
+8.3%
0.92x

Improvement (1)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeFromNSArrayAnyObjectToString
166404
155969
-6.3%
1.07x(?)

No Changes (113)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeToNSSet
16349
15737
-3.7%
1.04x(?)

DictionaryLiteral
3418
3277
-4.1%
1.04x

ObjectiveCBridgeFromNSDictionaryAnyObjectToString
190926
185476
-2.9%
1.03x

ObjectiveCBridgeStubFromArrayOfNSString
113176
109936
-2.9%
1.03x(?)

Array2D
2024
1981
-2.1%
1.02x(?)

StringInterpolation
10080
9920
-1.6%
1.02x

Walsh
311
306
-1.6%
1.02x

ObjectiveCBridgeToNSArray
29678
29149
-1.8%
1.02x(?)

ObjectiveCBridgeToNSDictionary
16343
16057
-1.8%
1.02x(?)

DictionaryRemove
4799
4718
-1.7%
1.02x(?)

NSStringConversion
616
606
-1.6%
1.02x

Chars
670
660
-1.5%
1.02x(?)

ArraySubscript
1338
1330
-0.6%
1.01x

ObjectiveCBridgeFromNSArrayAnyObjectForced
3654
3617
-1.0%
1.01x

ErrorHandling
2866
2829
-1.3%
1.01x(?)

ArrayLiteral
993
987
-0.6%
1.01x(?)

ProtocolDispatch2
163
162
-0.6%
1.01x

DictionarySwapOfObjects
7176
7116
-0.8%
1.01x(?)

StrComplexWalk
2808
2783
-0.9%
1.01x(?)

ArrayOfRef
3454
3434
-0.6%
1.01x(?)

ObjectiveCBridgeFromNSArrayAnyObject
63195
62477
-1.1%
1.01x(?)

NSDictionaryCastToSwift
8554
8436
-1.4%
1.01x(?)

HashTest
1807
1791
-0.9%
1.01x(?)

LinkedList
8997
8931
-0.7%
1.01x(?)

MonteCarloPi
42564
42587
+0.1%
1.00x

StackPromo
18991
18990
-0.0%
1.00x(?)

RecursiveOwnedParameter
1829
1829
+0.0%
1.00x

ObjectiveCBridgeStubToNSString
1373
1375
+0.1%
1.00x(?)

Histogram
652
652
+0.0%
1.00x

SortStrings
1753
1747
-0.3%
1.00x

DictionaryBridge
3528
3530
+0.1%
1.00x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectForced
4550
4567
+0.4%
1.00x(?)

ArrayOfGenericPOD
207
208
+0.5%
1.00x

StringWithCString
81188
81245
+0.1%
1.00x(?)

ObjectiveCBridgeFromNSStringForced
2202
2194
-0.4%
1.00x(?)

Prims
729
730
+0.1%
1.00x(?)

SortLettersInPlace
1003
1001
-0.2%
1.00x

PopFrontArray
1228
1230
+0.2%
1.00x(?)

Dictionary3OfObjects
1184
1185
+0.1%
1.00x(?)

ByteSwap
1
1
+0.0%
1.00x

SuperChars
282895
283773
+0.3%
1.00x(?)

XorLoop
359
359
+0.0%
1.00x

ObjectiveCBridgeStubFromNSStringRef
327
327
+0.0%
1.00x

ProtocolDispatch
2879
2885
+0.2%
1.00x(?)

ObjectAllocation
141
141
+0.0%
1.00x

TypeFlood
0
0
+0.0%
1.00x

ObjectiveCBridgeFromNSSetAnyObject
93758
94213
+0.5%
1.00x(?)

Dictionary3
726
727
+0.1%
1.00x(?)

Dictionary2
2399
2400
+0.0%
1.00x(?)

SetIntersect_OfObjects
2728
2719
-0.3%
1.00x(?)

NSError
353
352
-0.3%
1.00x(?)

DictionaryOfObjects
2687
2693
+0.2%
1.00x(?)

PopFrontUnsafePointer
8506
8501
-0.1%
1.00x(?)

PolymorphicCalls
61
61
+0.0%
1.00x

114
2243449
2236732
-0.3%
1.00x

Hanoi
3431
3414
-0.5%
1.00x(?)

OpenClose
49
49
+0.0%
1.00x

DictionaryRemoveOfObjects
19410
19485
+0.4%
1.00x(?)

UTF8Decode
257
256
-0.4%
1.00x

SetIsSubsetOf
480
479
-0.2%
1.00x

NopDeinit
34609
34660
+0.1%
1.00x(?)

SetIntersect
1134
1133
-0.1%
1.00x(?)

RGBHistogramOfObjects
22346
22384
+0.2%
1.00x

StringBuilder
1369
1365
-0.3%
1.00x(?)

Phonebook
9288
9299
+0.1%
1.00x(?)

Sim2DArray
413
411
-0.5%
1.00x(?)

SetExclusiveOr_OfObjects
8855
8839
-0.2%
1.00x(?)

MonteCarloE
10048
10034
-0.1%
1.00x(?)

SetUnion_OfObjects
7013
7020
+0.1%
1.00x(?)

RC4
251
251
+0.0%
1.00x

SetIsSubsetOf_OfObjects
540
540
+0.0%
1.00x

ArrayAppend
730
728
-0.3%
1.00x(?)

RGBHistogram
3359
3352
-0.2%
1.00x(?)

ArrayValueProp4
5
5
+0.0%
1.00x

ArrayOfPOD
172
172
+0.0%
1.00x

SetUnion
3242
3234
-0.2%
1.00x

StrToInt
3622
3632
+0.3%
1.00x(?)

BitCount
1
1
+0.0%
1.00x

AngryPhonebook
3367
3358
-0.3%
1.00x(?)

SevenBoom
1267
1269
+0.2%
1.00x(?)

StringWalk
6438
6452
+0.2%
1.00x(?)

ArrayValueProp
5
5
+0.0%
1.00x

GlobalClass
0
0
+0.0%
1.00x

Memset
222
222
+0.0%
1.00x

ArrayAppendReserved
508
508
+0.0%
1.00x

ArrayValueProp2
5
5
+0.0%
1.00x

ArrayValueProp3
5
5
+0.0%
1.00x

ObjectiveCBridgeToNSString
1021
1028
+0.7%
0.99x(?)

ObjectiveCBridgeFromNSDictionaryAnyObject
184245
186150
+1.0%
0.99x(?)

DictionarySwap
757
762
+0.7%
0.99x(?)

Integrate
228
230
+0.9%
0.99x(?)

ObjectiveCBridgeStubFromNSString
697
701
+0.6%
0.99x(?)

Join
428
433
+1.2%
0.99x

PopFrontArrayGeneric
1255
1262
+0.6%
0.99x

CaptureProp
3752
3779
+0.7%
0.99x(?)

MapReduce
329
332
+0.9%
0.99x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToStringForced
122660
124131
+1.2%
0.99x(?)

Dictionary
959
973
+1.5%
0.99x

ArrayInClass
82
83
+1.2%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObjectToStringForced
106501
107077
+0.5%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObjectToString
169579
171590
+1.2%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObjectForced
4023
4070
+1.2%
0.99x(?)

DeadArray
176
177
+0.6%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObjectToStringForced
159423
160487
+0.7%
0.99x(?)

Dictionary2OfObjects
3969
4005
+0.9%
0.99x

TwoSum
1713
1727
+0.8%
0.99x

RangeAssignment
262
266
+1.5%
0.98x(?)

ObjectiveCBridgeStubToArrayOfNSString
29702
30248
+1.8%
0.98x(?)

SetExclusiveOr
3782
3844
+1.6%
0.98x

ArrayOfGenericRef
3475
3542
+1.9%
0.98x(?)

ObjectiveCBridgeFromNSString
1529
1553
+1.6%
0.98x(?)

StaticArray
2598
2672
+2.9%
0.97x(?)

Calculator
32
33
+3.1%
0.97x

**Unoptimized (Onone)**

Regression (1)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

TypeFlood
142
151
+6.3%
0.94x(?)

Improvement (0)

No Changes (114)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeFromNSSetAnyObjectToStringForced
121775
116408
-4.4%
1.05x(?)

OpenClose
451
433
-4.0%
1.04x(?)

DictionaryOfObjects
7282
7049
-3.2%
1.03x

StringWalk
42766
41327
-3.4%
1.03x(?)

StringInterpolation
13674
13419
-1.9%
1.02x(?)

StrComplexWalk
7871
7686
-2.4%
1.02x

PopFrontArrayGeneric
12442
12203
-1.9%
1.02x

CaptureProp
55130
54267
-1.6%
1.02x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToStringForced
127072
124314
-2.2%
1.02x

StackPromo
80945
80335
-0.8%
1.01x(?)

Histogram
13859
13768
-0.7%
1.01x(?)

PopFrontArray
12262
12107
-1.3%
1.01x(?)

ErrorHandling
7241
7181
-0.8%
1.01x(?)

ObjectiveCBridgeStubFromNSString
1138
1132
-0.5%
1.01x

ProtocolDispatch
5602
5568
-0.6%
1.01x(?)

MapReduce
45175
44618
-1.2%
1.01x(?)

Integrate
348
346
-0.6%
1.01x

UTF8Decode
39402
39202
-0.5%
1.01x(?)

Dictionary
4532
4500
-0.7%
1.01x

ObjectiveCBridgeStubToArrayOfNSString
30424
30172
-0.8%
1.01x(?)

StringBuilder
8268
8153
-1.4%
1.01x(?)

TwoSum
9273
9193
-0.9%
1.01x(?)

ArraySubscript
4450
4448
-0.0%
1.00x(?)

DictionarySwapOfObjects
25809
25767
-0.2%
1.00x(?)

ObjectiveCBridgeFromNSDictionaryAnyObject
192412
191679
-0.4%
1.00x(?)

RecursiveOwnedParameter
10283
10293
+0.1%
1.00x(?)

ObjectiveCBridgeStubToNSString
1672
1676
+0.2%
1.00x

ClassArrayGetter
1264
1264
+0.0%
1.00x

Array2D
697294
697454
+0.0%
1.00x(?)

SortStrings
5672
5652
-0.3%
1.00x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectForced
7074
7042
-0.5%
1.00x(?)

MonteCarloPi
50224
50226
+0.0%
1.00x(?)

StringWithCString
713012
712645
-0.1%
1.00x(?)

ObjectiveCBridgeFromNSArrayAnyObjectForced
7029
7038
+0.1%
1.00x(?)

Prims
13669
13646
-0.2%
1.00x(?)

SortLettersInPlace
2319
2315
-0.2%
1.00x(?)

DictionarySwap
11593
11587
-0.1%
1.00x(?)

ByteSwap
9
9
+0.0%
1.00x

XorLoop
18434
18445
+0.1%
1.00x(?)

ObjectiveCBridgeStubFromNSStringRef
651
651
+0.0%
1.00x

StaticArray
17031
16984
-0.3%
1.00x(?)

ArrayLiteral
1033
1035
+0.2%
1.00x(?)

Walsh
12244
12243
-0.0%
1.00x(?)

Dictionary3
2099
2098
-0.1%
1.00x(?)

Dictionary2
5147
5143
-0.1%
1.00x(?)

SetIntersect_OfObjects
18893
18918
+0.1%
1.00x(?)

Join
1340
1334
-0.5%
1.00x

ArrayOfRef
9929
9908
-0.2%
1.00x(?)

PopFrontUnsafePointer
95350
95047
-0.3%
1.00x(?)

Calculator
932
931
-0.1%
1.00x

DictionaryRemoveOfObjects
60971
60879
-0.1%
1.00x(?)

SetIsSubsetOf
2952
2948
-0.1%
1.00x(?)

NopDeinit
53314
53273
-0.1%
1.00x(?)

SetIntersect
18837
18853
+0.1%
1.00x(?)

SetExclusiveOr
48566
48583
+0.0%
1.00x(?)

RGBHistogramOfObjects
97745
98173
+0.4%
1.00x(?)

ArrayInClass
3648
3647
-0.0%
1.00x

ArrayOfGenericRef
10569
10563
-0.1%
1.00x(?)

Phonebook
59729
59869
+0.2%
1.00x(?)

Sim2DArray
13143
13139
-0.0%
1.00x(?)

SetExclusiveOr_OfObjects
66912
66855
-0.1%
1.00x(?)

MonteCarloE
98538
98873
+0.3%
1.00x

SetUnion_OfObjects
51158
51146
-0.0%
1.00x(?)

GlobalClass
0
0
+0.0%
1.00x

HashTest
6016
6036
+0.3%
1.00x

SetIsSubsetOf_OfObjects
2835
2847
+0.4%
1.00x(?)

ArrayAppend
2874
2865
-0.3%
1.00x(?)

DictionaryRemove
30422
30428
+0.0%
1.00x(?)

LinkedList
26390
26358
-0.1%
1.00x

RGBHistogram
49481
49605
+0.2%
1.00x(?)

ArrayOfPOD
2335
2328
-0.3%
1.00x(?)

SetUnion
34827
34854
+0.1%
1.00x(?)

Chars
54412
54391
-0.0%
1.00x(?)

DeadArray
128681
128252
-0.3%
1.00x(?)

BitCount
77
77
+0.0%
1.00x

AngryPhonebook
5880
5887
+0.1%
1.00x(?)

SevenBoom
1417
1422
+0.3%
1.00x

ArrayValueProp
2225
2227
+0.1%
1.00x(?)

RC4
8737
8753
+0.2%
1.00x(?)

Memset
20655
20659
+0.0%
1.00x(?)

Dictionary2OfObjects
6936
6918
-0.3%
1.00x(?)

ArrayAppendReserved
2697
2688
-0.3%
1.00x(?)

ArrayValueProp2
18192
18189
-0.0%
1.00x(?)

ArrayValueProp3
2580
2574
-0.2%
1.00x(?)

ObjectiveCBridgeToNSString
1048
1056
+0.8%
0.99x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToString
193233
194649
+0.7%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObjectToString
159865
160995
+0.7%
0.99x(?)

ObjectiveCBridgeFromNSStringForced
2566
2581
+0.6%
0.99x(?)

Dictionary3OfObjects
2725
2740
+0.6%
0.99x

RangeAssignment
15535
15615
+0.5%
0.99x

SuperChars
691413
694997
+0.5%
0.99x(?)

114
5537837
5570509
+0.6%
0.99x

ObjectAllocation
1292
1301
+0.7%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObject
99870
101059
+1.2%
0.99x

ProtocolDispatch2
421
424
+0.7%
0.99x

ObjectiveCBridgeToNSSet
16368
16559
+1.2%
0.99x(?)

ObjectiveCBridgeToNSArray
29459
29780
+1.1%
0.99x(?)

NSError
648
653
+0.8%
0.99x(?)

DictionaryLiteral
20071
20229
+0.8%
0.99x(?)

Hanoi
22703
22848
+0.6%
0.99x

ArrayOfGenericPOD
3426
3475
+1.4%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObject
66231
66937
+1.1%
0.99x(?)

NSDictionaryCastToSwift
9559
9662
+1.1%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObjectToString
189658
190659
+0.5%
0.99x(?)

NSStringConversion
2553
2570
+0.7%
0.99x(?)

ArrayValueProp4
2522
2535
+0.5%
0.99x(?)

DictionaryBridge
3534
3623
+2.5%
0.98x(?)

PolymorphicCalls
1133
1154
+1.9%
0.98x

StrToInt
18521
18920
+2.1%
0.98x

ObjectiveCBridgeFromNSString
4939
5036
+2.0%
0.98x(?)

ObjectiveCBridgeToNSDictionary
16261
16616
+2.2%
0.98x(?)

ObjectiveCBridgeStubFromArrayOfNSString
108740
111878
+2.9%
0.97x(?)

ObjectiveCBridgeFromNSSetAnyObjectForced
7453
7790
+4.5%
0.96x

ObjectiveCBridgeFromNSArrayAnyObjectToStringForced
158374
164849
+4.1%
0.96x(?)

**Hardware Overview**
      Model Name: Mac mini
      Model Identifier: Macmini7,1
      Processor Name: Intel Core i7
      Processor Speed: 3 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      L2 Cache (per Core): 256 KB
      L3 Cache: 4 MB
      Memory: 16 GB

@nadavrot Do these regressions look OK to you? It looks potentially legitimate, since both of the affected benchmarks are type-metadata-access-heavy.

@jckarter I am seeing one improvement and one regression. The numbers we are seeing could be noise. In any case, we'll benchmark this change again with the internal setup of the performance benchmark. I think that this change can go in.

Also looking at the numbers it seems like some of the benchmarks result in low values that can cause what look like larger percentage changes. It seems like they should be enhanced to always achieve a threshold of say 100 if they are going to be measured in the way they are.

bump

Any remaining objections @gparker42 @nadavrot ?

I'm going to be out next week; @gparker42, if this looks good, do you mind merging?

I am building with your code on Cygwin. I found errors.
In file included from /cygdrive/c/Work/swift_msvc/swift/stdlib/public/runtime/Casting.cpp:25:
In file included from /cygdrive/c/Work/swift_msvc/swift/include/swift/Runtime/Mutex.h:24:
/cygdrive/c/Work/swift_msvc/swift/include/swift/Runtime/MutexPThread.h:49:32: error: constexpr function never produces a constant expression [-Winvalid-constexpr]
  static constexpr MutexHandle staticInit() {
                               ^
/cygdrive/c/Work/swift_msvc/swift/include/swift/Runtime/MutexPThread.h:50:12: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
    return PTHREAD_MUTEX_INITIALIZER;
           ^
/usr/include/pthread.h:52:35: note: expanded from macro 'PTHREAD_MUTEX_INITIALIZER'
#define PTHREAD_MUTEX_INITIALIZER PTHREAD_NORMAL_MUTEX_INITIALIZER_NP
                                  ^
/usr/include/pthread.h:50:45: note: expanded from macro 'PTHREAD_NORMAL_MUTEX_INITIALIZER_NP'
#define PTHREAD_NORMAL_MUTEX_INITIALIZER_NP (pthread_mutex_t)19
                                            ^

@tinysun212 Any suggestions to how to correct? I don't currently have a usable Windows install with Cygwin (it will take me a bit to get it going). I guess Cygwin doesn't support staticly allocated pthread mutex?

I extracted some definitions from pthread.h in Cygwin.
I think you can reproduce above compile error with temporarily changing #include <pthread.h> to #include "swift/Runtime/_pthread.h" in Mutex.h/MutexPThread.h.
typedef __uint32_t pthread_mutex_t;      /* identify a mutex */
typedef __uint32_t pthread_cond_t;       /* identify a condition variable */
typedef __uint32_t pthread_rwlock_t;         /* POSIX RWLock Object */

#define PTHREAD_COND_INITIALIZER (pthread_cond_t)21
#define PTHREAD_MUTEX_INITIALIZER PTHREAD_NORMAL_MUTEX_INITIALIZER_NP
#define PTHREAD_NORMAL_MUTEX_INITIALIZER_NP (pthread_mutex_t)19
#define PTHREAD_RWLOCK_INITIALIZER (pthread_rwlock_t)22

int pthread_cond_broadcast (pthread_cond_t *);
int pthread_cond_destroy (pthread_cond_t *);
int pthread_cond_init (pthread_cond_t *, const pthread_condattr_t *);
int pthread_cond_signal (pthread_cond_t *);
int pthread_cond_wait (pthread_cond_t *, pthread_mutex_t *);

int pthread_mutexattr_init (pthread_mutexattr_t *);
int pthread_mutexattr_settype (pthread_mutexattr_t *, int);
int pthread_mutexattr_destroy (pthread_mutexattr_t *);

int pthread_mutex_destroy (pthread_mutex_t *);
int pthread_mutex_init (pthread_mutex_t *, const pthread_mutexattr_t *);
int pthread_mutex_lock (pthread_mutex_t *);
int pthread_mutex_trylock (pthread_mutex_t *);
int pthread_mutex_unlock (pthread_mutex_t *);

int pthread_rwlock_destroy (pthread_rwlock_t *rwlock);
int pthread_rwlock_init (pthread_rwlock_t *rwlock, const pthread_rwlockattr_t *attr);
int pthread_rwlock_rdlock (pthread_rwlock_t *rwlock);
int pthread_rwlock_tryrdlock (pthread_rwlock_t *rwlock);
int pthread_rwlock_trywrlock (pthread_rwlock_t *rwlock);
int pthread_rwlock_unlock (pthread_rwlock_t *rwlock);
int pthread_rwlock_wrlock (pthread_rwlock_t *rwlock);

I guess we will have to predicate the use of constexpr on not Cygwin. It won't make cygwin any worse then it apparently was (doesn't have a "true" static allocated mutex, etc.) while allowing other platforms to correctly honor static allocation (under C++).

Sorry, I captured wrong header. In include/cygwin/types.h, the typedef part is as follows,
typedef struct __pthread_condattr_t {char __dummy;} *pthread_condattr_t;
typedef struct __pthread_cond_t {char __dummy;} *pthread_cond_t;
typedef struct __pthread_rwlock_t {char __dummy;} *pthread_rwlock_t;
typedef struct __pthread_rwlockattr_t {char __dummy;} *pthread_rwlockattr_t;

I wrote simple source to test.
$ cat tt.cpp

typedef struct __pthread_cond_t {char __dummy;} *pthread_cond_t;
#define PTHREAD_COND_INITIALIZER (pthread_cond_t)21

typedef pthread_cond_t ConditionHandle;

static constexpr ConditionHandle staticInit() {
  return PTHREAD_COND_INITIALIZER;
};

$ clang++ -c -std=c++11 tt.cpp
tt.cpp:7:34: error: constexpr function never produces a constant expression [-Winvalid-constexpr]
static constexpr ConditionHandle staticInit() {
                                 ^
tt.cpp:8:10: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
  return PTHREAD_COND_INITIALIZER;
         ^
tt.cpp:3:34: note: expanded from macro 'PTHREAD_COND_INITIALIZER'
#define PTHREAD_COND_INITIALIZER (pthread_cond_t)21
                                 ^
1 error generated.

Do you have any idea to keep constexpr?

@tinysun212 I just pushed a change that should deal with the issue you reported under Cygwin on Windows. If possible can you try it out to verify it works as expected?

It is successfully compiled without any warning or error. Thanks for your patch.

@tinysun212 cool, you will need to update your Win32 implementation have the following in its header.
#define CONDITION_SUPPORTS_CONSTEXPR 1
#define MUTEX_SUPPORTS_CONSTEXPR 1
#define READWRITELOCK_SUPPORTS_CONSTEXPR 1

@gparker42 @jckarter ok I think this ready to go after a CI

@swift-ci Please test
@swift-ci Please benchmark

Build comment file:
Optimized (O)

Regression (1)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeToNSDictionary
16422
17423
+6.1%
0.94x

Improvement (3)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeFromNSArrayAnyObjectToString
166571
157769
-5.3%
1.06x

Calculator
35
33
-5.7%
1.06x

StringHasSuffix
714
675
-5.5%
1.06x(?)

No Changes (117)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ObjectiveCBridgeToNSSet
16729
15967
-4.5%
1.05x(?)

ObjectiveCBridgeFromNSDictionaryAnyObject
196894
189306
-3.9%
1.04x(?)

DictionaryOfObjects
2264
2204
-2.6%
1.03x

Dictionary
731
713
-2.5%
1.03x

SetExclusiveOr_OfObjects
8077
7816
-3.2%
1.03x

SetUnion_OfObjects
6748
6546
-3.0%
1.03x

SortStrings
1762
1730
-1.8%
1.02x

ObjectiveCBridgeStubToNSString
1415
1392
-1.6%
1.02x

AngryPhonebook
3389
3337
-1.5%
1.02x(?)

DictionaryRemove
5015
4907
-2.1%
1.02x(?)

ObjectiveCBridgeFromNSSetAnyObjectToString
166038
162739
-2.0%
1.02x(?)

ObjectiveCBridgeStubFromArrayOfNSString
109552
107570
-1.8%
1.02x

ObjectiveCBridgeToNSString
1062
1055
-0.7%
1.01x(?)

PopFrontArray
1060
1054
-0.6%
1.01x(?)

Array2D
2024
2012
-0.6%
1.01x(?)

DictionaryBridge
3636
3609
-0.7%
1.01x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectForced
4574
4544
-0.7%
1.01x(?)

Prims
714
710
-0.6%
1.01x

DictionarySwap
757
752
-0.7%
1.01x(?)

RangeAssignment
273
270
-1.1%
1.01x

StrComplexWalk
3023
2993
-1.0%
1.01x(?)

ObjectAllocation
143
142
-0.7%
1.01x(?)

Dictionary2
1918
1904
-0.7%
1.01x

ArrayOfRef
3451
3429
-0.6%
1.01x(?)

ObjectiveCBridgeStubToArrayOfNSString
30347
30111
-0.8%
1.01x(?)

Phonebook
7221
7130
-1.3%
1.01x

NSStringConversion
612
606
-1.0%
1.01x

Chars
618
609
-1.5%
1.01x(?)

StrToInt
4936
4866
-1.4%
1.01x

DeadArray
173
172
-0.6%
1.01x

120
2294275
2269762
-1.1%
1.01x

ArraySubscript
1325
1321
-0.3%
1.00x(?)

MonteCarloPi
42667
42668
+0.0%
1.00x(?)

StackPromo
18693
18709
+0.1%
1.00x(?)

RecursiveOwnedParameter
1826
1827
+0.1%
1.00x(?)

Integrate
233
232
-0.4%
1.00x

ClassArrayGetter
12
12
+0.0%
1.00x

Histogram
639
639
+0.0%
1.00x

StringWithCString
75595
75613
+0.0%
1.00x(?)

ObjectiveCBridgeFromNSStringForced
2187
2186
-0.1%
1.00x(?)

SortLettersInPlace
940
943
+0.3%
1.00x(?)

ArrayOfGenericPOD
207
208
+0.5%
1.00x

Dictionary3OfObjects
850
846
-0.5%
1.00x

ByteSwap
1
1
+0.0%
1.00x

SuperChars
276889
275774
-0.4%
1.00x

XorLoop
359
359
+0.0%
1.00x

ObjectiveCBridgeStubFromNSStringRef
327
327
+0.0%
1.00x

StaticArray
2648
2643
-0.2%
1.00x(?)

ProtocolDispatch
2892
2888
-0.1%
1.00x(?)

TypeFlood
0
0
+0.0%
1.00x

ProtocolDispatch2
151
151
+0.0%
1.00x

Dictionary3
497
498
+0.2%
1.00x(?)

StringHasPrefix
576
577
+0.2%
1.00x(?)

SetIntersect_OfObjects
2360
2358
-0.1%
1.00x(?)

ErrorHandling
2859
2845
-0.5%
1.00x(?)

ObjectiveCBridgeToNSArray
30182
30037
-0.5%
1.00x(?)

NSError
359
359
+0.0%
1.00x

PopFrontArrayGeneric
1049
1051
+0.2%
1.00x(?)

PopFrontUnsafePointer
8657
8655
-0.0%
1.00x(?)

CaptureProp
3741
3742
+0.0%
1.00x(?)

PolymorphicCalls
61
61
+0.0%
1.00x

RC4
250
250
+0.0%
1.00x

MapReduce
327
327
+0.0%
1.00x

Hanoi
3405
3405
+0.0%
1.00x

OpenClose
48
48
+0.0%
1.00x

DictionaryRemoveOfObjects
19503
19471
-0.2%
1.00x(?)

UTF8Decode
260
260
+0.0%
1.00x

SortStringsUnicode
8994
9013
+0.2%
1.00x(?)

SetIsSubsetOf
548
549
+0.2%
1.00x(?)

NopDeinit
34619
34609
-0.0%
1.00x

ObjectiveCBridgeFromNSArrayAnyObject
61546
61842
+0.5%
1.00x

SetIntersect
1300
1298
-0.1%
1.00x(?)

SetExclusiveOr
3830
3836
+0.2%
1.00x(?)

RGBHistogramOfObjects
21199
21271
+0.3%
1.00x(?)

StringBuilder
1389
1390
+0.1%
1.00x(?)

ArrayInClass
85
85
+0.0%
1.00x

ArrayOfGenericRef
3519
3524
+0.1%
1.00x(?)

Sim2DArray
410
412
+0.5%
1.00x

MonteCarloE
9996
10032
+0.4%
1.00x

StringHasSuffixUnicode
62311
62479
+0.3%
1.00x(?)

HashTest
1819
1816
-0.2%
1.00x(?)

SetIsSubsetOf_OfObjects
617
617
+0.0%
1.00x

ArrayAppend
730
728
-0.3%
1.00x(?)

StringHasPrefixUnicode
14981
15017
+0.2%
1.00x(?)

LinkedList
6847
6843
-0.1%
1.00x

RGBHistogram
3233
3238
+0.1%
1.00x(?)

ObjectiveCBridgeFromNSSetAnyObjectForced
3981
3968
-0.3%
1.00x(?)

ArrayAppendReserved
507
507
+0.0%
1.00x

ArrayOfPOD
171
171
+0.0%
1.00x

SetUnion
3385
3398
+0.4%
1.00x(?)

BitCount
1
1
+0.0%
1.00x

ArrayLiteral
979
981
+0.2%
1.00x(?)

SevenBoom
1276
1274
-0.2%
1.00x

ObjectiveCBridgeFromNSArrayAnyObjectToStringForced
159858
159122
-0.5%
1.00x(?)

StringWalk
6008
6014
+0.1%
1.00x(?)

ArrayValueProp
5
5
+0.0%
1.00x

GlobalClass
0
0
+0.0%
1.00x

Memset
222
223
+0.5%
1.00x

Dictionary2OfObjects
3293
3283
-0.3%
1.00x(?)

ArrayValueProp4
5
5
+0.0%
1.00x

TwoSum
1642
1643
+0.1%
1.00x(?)

ArrayValueProp2
5
5
+0.0%
1.00x

ArrayValueProp3
5
5
+0.0%
1.00x

DictionarySwapOfObjects
6606
6658
+0.8%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObjectForced
3609
3633
+0.7%
0.99x(?)

StringInterpolation
9999
10054
+0.6%
0.99x(?)

Join
439
445
+1.4%
0.99x(?)

ObjectiveCBridgeStubFromNSString
694
700
+0.9%
0.99x

StringEqualPointerComparison
7102
7160
+0.8%
0.99x

ObjectiveCBridgeFromNSString
1561
1572
+0.7%
0.99x

ObjectiveCBridgeFromNSSetAnyObjectToStringForced
101734
103174
+1.4%
0.99x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToString
180143
182976
+1.6%
0.98x(?)

ObjectiveCBridgeFromNSSetAnyObject
95459
97047
+1.7%
0.98x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToStringForced
114004
116779
+2.4%
0.98x(?)

NSDictionaryCastToSwift
8281
8422
+1.7%
0.98x(?)

DictionaryLiteral
3006
3113
+3.6%
0.97x(?)

Walsh
317
329
+3.8%
0.96x

**Unoptimized (Onone)**

Regression (1)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

TypeFlood
145
156
+7.6%
0.93x(?)

Improvement (3)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

StringHasPrefix
1630
1516
-7.0%
1.08x

ByteSwap
10
9
-10.0%
1.11x

StringWalk
26926
23276
-13.6%
1.16x

No Changes (117)

TEST
OLD_MIN
NEW_MIN
DELTA (%)
SPEEDUP

ArrayOfPOD
2256
2152
-4.6%
1.05x

StringHasSuffix
1561
1487
-4.7%
1.05x

ObjectiveCBridgeToNSSet
16775
16073
-4.2%
1.04x(?)

NopDeinit
60929
59005
-3.2%
1.03x

ObjectiveCBridgeFromNSSetAnyObjectToString
184614
179171
-3.0%
1.03x(?)

OpenClose
452
442
-2.2%
1.02x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectToStringForced
122508
119650
-2.3%
1.02x(?)

StringHasPrefixUnicode
16769
16441
-2.0%
1.02x

ObjectiveCBridgeFromNSSetAnyObjectToStringForced
115560
113711
-1.6%
1.02x(?)

ArrayAppendReserved
2701
2659
-1.6%
1.02x(?)

Chars
53814
52725
-2.0%
1.02x(?)

PopFrontArray
11670
11546
-1.1%
1.01x

SortStrings
14096
13993
-0.7%
1.01x

SortLettersInPlace
4158
4134
-0.6%
1.01x(?)

ObjectiveCBridgeFromNSDictionaryAnyObject
199443
197410
-1.0%
1.01x(?)

Integrate
347
345
-0.6%
1.01x(?)

Join
1370
1363
-0.5%
1.01x(?)

ErrorHandling
7549
7464
-1.1%
1.01x(?)

PopFrontArrayGeneric
11885
11821
-0.5%
1.01x(?)

PopFrontUnsafePointer
96350
95260
-1.1%
1.01x(?)

StringEqualPointerComparison
9779
9645
-1.4%
1.01x

ArrayOfGenericPOD
3493
3449
-1.3%
1.01x(?)

DictionaryRemoveOfObjects
60808
60183
-1.0%
1.01x

UTF8Decode
38869
38347
-1.3%
1.01x

SortStringsUnicode
23042
22860
-0.8%
1.01x

StrToInt
19217
18965
-1.3%
1.01x(?)

ArrayAppend
3130
3112
-0.6%
1.01x(?)

LinkedList
26288
26108
-0.7%
1.01x(?)

StringBuilder
8351
8250
-1.2%
1.01x(?)

ObjectiveCBridgeStubFromArrayOfNSString
113665
112449
-1.1%
1.01x(?)

ArrayValueProp4
2484
2449
-1.4%
1.01x

ArraySubscript
5398
5380
-0.3%
1.00x(?)

ObjectiveCBridgeToNSString
1052
1052
+0.0%
1.00x

ObjectiveCBridgeStubToNSString
1663
1667
+0.2%
1.00x

ClassArrayGetter
1182
1183
+0.1%
1.00x(?)

Array2D
759861
760971
+0.1%
1.00x

Histogram
13495
13503
+0.1%
1.00x(?)

MonteCarloPi
50444
50489
+0.1%
1.00x(?)

StringWithCString
73856
73828
-0.0%
1.00x(?)

ObjectiveCBridgeFromNSStringForced
2605
2597
-0.3%
1.00x(?)

Prims
14107
14082
-0.2%
1.00x(?)

Dictionary3OfObjects
2653
2652
-0.0%
1.00x(?)

RangeAssignment
12817
12807
-0.1%
1.00x(?)

SuperChars
720170
720255
+0.0%
1.00x(?)

XorLoop
18026
18042
+0.1%
1.00x(?)

ObjectiveCBridgeStubFromNSStringRef
649
649
+0.0%
1.00x

StaticArray
17222
17296
+0.4%
1.00x(?)

ProtocolDispatch
5395
5398
+0.1%
1.00x(?)

ObjectAllocation
1282
1277
-0.4%
1.00x(?)

ArrayLiteral
1039
1038
-0.1%
1.00x(?)

HashTest
6172
6158
-0.2%
1.00x(?)

Dictionary3
2024
2023
-0.1%
1.00x(?)

Dictionary2
5100
5094
-0.1%
1.00x(?)

StrComplexWalk
8557
8558
+0.0%
1.00x(?)

SetIntersect_OfObjects
18947
18892
-0.3%
1.00x(?)

ArrayOfRef
8836
8796
-0.5%
1.00x

ObjectiveCBridgeToNSArray
30251
30255
+0.0%
1.00x(?)

DictionaryOfObjects
6904
6931
+0.4%
1.00x(?)

CaptureProp
52080
52161
+0.2%
1.00x(?)

RC4
8433
8430
-0.0%
1.00x(?)

MapReduce
41976
41773
-0.5%
1.00x

Hanoi
18879
18903
+0.1%
1.00x(?)

SetIsSubsetOf
3012
3002
-0.3%
1.00x

SetIntersect
18957
18953
-0.0%
1.00x(?)

SetExclusiveOr
48910
48885
-0.1%
1.00x(?)

RGBHistogramOfObjects
114910
114596
-0.3%
1.00x(?)

ArrayInClass
3562
3560
-0.1%
1.00x(?)

ArrayOfGenericRef
9464
9493
+0.3%
1.00x(?)

Sim2DArray
13160
13155
-0.0%
1.00x(?)

SetExclusiveOr_OfObjects
67180
67096
-0.1%
1.00x(?)

MonteCarloE
102055
102489
+0.4%
1.00x(?)

SetUnion_OfObjects
51266
51226
-0.1%
1.00x(?)

StringHasSuffixUnicode
64403
64445
+0.1%
1.00x(?)

Walsh
11993
11994
+0.0%
1.00x(?)

SetIsSubsetOf_OfObjects
2836
2840
+0.1%
1.00x

DictionaryRemove
30238
30204
-0.1%
1.00x(?)

NSStringConversion
2596
2608
+0.5%
1.00x(?)

RGBHistogram
65805
65844
+0.1%
1.00x(?)

SetUnion
35038
35061
+0.1%
1.00x(?)

BitCount
92
92
+0.0%
1.00x

AngryPhonebook
6087
6080
-0.1%
1.00x(?)

ObjectiveCBridgeFromNSArrayAnyObjectToStringForced
159358
158771
-0.4%
1.00x(?)

ArrayValueProp
2176
2172
-0.2%
1.00x(?)

120
5250686
5254294
+0.1%
1.00x

GlobalClass
0
0
+0.0%
1.00x

Memset
18649
18643
-0.0%
1.00x(?)

ArrayValueProp2
17864
17913
+0.3%
1.00x

SevenBoom
1436
1430
-0.4%
1.00x(?)

StackPromo
161665
164036
+1.5%
0.99x

RecursiveOwnedParameter
7555
7607
+0.7%
0.99x

ObjectiveCBridgeFromNSDictionaryAnyObjectToString
195015
196489
+0.8%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObjectToString
156329
157882
+1.0%
0.99x(?)

ObjectiveCBridgeFromNSDictionaryAnyObjectForced
7059
7137
+1.1%
0.99x(?)

ObjectiveCBridgeFromNSArrayAnyObjectForced
6948
7012
+0.9%
0.99x(?)

DictionarySwap
11425
11532
+0.9%
0.99x(?)

StringInterpolation
15303
15419
+0.8%
0.99x(?)

ObjectiveCBridgeStubFromNSString
1122
1130
+0.7%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObject
103827
104526
+0.7%
0.99x(?)

ProtocolDispatch2
425
428
+0.7%
0.99x

NSError
634
639
+0.8%
0.99x(?)

PolymorphicCalls
1137
1151
+1.2%
0.99x(?)

Calculator
938
952
+1.5%
0.99x

DictionaryLiteral
20228
20461
+1.1%
0.99x(?)

ObjectiveCBridgeFromNSString
5072
5105
+0.7%
0.99x(?)

Phonebook
84595
85233
+0.8%
0.99x(?)

ObjectiveCBridgeFromNSSetAnyObjectForced
7430
7504
+1.0%
0.99x(?)

DeadArray
136053
137218
+0.9%
0.99x(?)

ArrayValueProp3
2503
2519
+0.6%
0.99x

Dictionary2OfObjects
6866
6903
+0.5%
0.99x(?)

TwoSum
9227
9288
+0.7%
0.99x(?)

DictionarySwapOfObjects
25014
25456
+1.8%
0.98x

DictionaryBridge
3669
3753
+2.3%
0.98x(?)

Dictionary
4130
4199
+1.7%
0.98x(?)

ObjectiveCBridgeFromNSArrayAnyObject
65215
66489
+1.9%
0.98x(?)

NSDictionaryCastToSwift
9712
9926
+2.2%
0.98x

ObjectiveCBridgeStubToArrayOfNSString
30388
31338
+3.1%
0.97x

ObjectiveCBridgeToNSDictionary
16430
16901
+2.9%
0.97x(?)

**Hardware Overview**
      Model Name: Mac mini
      Model Identifier: Macmini7,1
      Processor Name: Intel Core i7
      Processor Speed: 3 GHz
      Number of Processors: 1
      Total Number of Cores: 2
      L2 Cache (per Core): 256 KB
      L3 Cache: 4 MB
      Memory: 16 GB

@swift-ci Please test

It looks like the Linux build issues continues to affect things?
ERROR: testREPL (TestREPLArray.REPLArrayTestCase)

@swift-ci Please test

I noted a few stylistic things that should be changed, but this is good enough to accept now and polish later.

@gparker42 I will work on the changes outlined and open a new pull request when ready. Thanks

authors: benlangmuir gparker42 gribozavr jckarter nadavrot shahmishal shawnce swift-ci tinysun212


text:
[stdlib] Fix return type of swift_{uint64,int64,float*}ToString

The return type of these functions are uint64_t in Stubs.cpp but UInt in the Swift code; this changes the Swift code to match the C++ return type.
Found when compiling the stdlib for WebAssembly, which requires that all return types match: UInt maps to i32 while uint64_t maps to i64, so functions calling these functions fail the validation.

CC: @airspeedswift

@airspeedswift would you be able to have a look please? Is there anyone who else who could be pinged about reviewing this PR?

@swift-ci please smoke test

Thanks @zhuowei. Sorry that we didn't see this earlier. FWIW, your best bet is to tag me or @tbkka for this stuff.

N.B. this was a "safe" return type mismatch because the actual implementation has a signature compatible with the signature used; the high 32b of the result were simply ignored by the caller on 32b targets, but they are semantically guaranteed to be zero anyway.

The return value here is the length of the formatted string, so a 32-bit value would be preferable to avoid overhead on 32-bit platforms.  I believe this is all internal, so changing the type won't break the ABI.
Of course, that might mean touching more places to get the types to line up all the way down.

Does it mean that this PR needs any more changes to pass the review and be merged? I'm a co-maintainer of @swiftwasm, and as far as I'm aware @zhuowei is not actively maintaining it currently, but I have access to the PR branch and I'm ready to push it forward and to apply any changes if needed

I agree with @tbkka that it would be better if these just returned int32. But, the cpp functions are marked SWIFT_RUNTIME_STDLIB_API, so we formally can't modify them (they are API), and the difference in efficiency is minimal.
@MaxDesiatov since we know that the result is always in-range, can you replace the Int inits (line 172 and similar) with Int(truncatingIfNeeded: ...)? This will eliminate the check so that the only overhead on 32b platforms is zeroing out a register, which is sufficiently cheap to not worry about.

Actually, I'll just merge this and make the other change myself as a follow on. Thanks all!

authors: MaxDesiatov compnerd stephentyrone tbkka zhuowei


text:
Fix off-by-one in @noescape fixit

What's in this pull request?

This
func noescapeD(@noescape f: () -> Bool) {}

used to become this
func noescapeD( f: @noescape() -> Bool) {}

It now becomes
func noescapeT(f: @noescape () -> Bool) {}

Moreover this
func autoclosureD(@autoclosure f: () -> Bool) {}

used to become this
func autoclosureD( f: @autoclosure@noescape() -> Bool) {}

It now becomes
func autoclosureD(f: @autoclosure @noescape () -> Bool) {}

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci Please fix

@slavapestov I wish it worked that way...

@swift-ci please test

Oh man, this is not the first time I asked CI to 'please fix'. I guess I'm just begging our AI overlords to automate me out of a job...

The Linux failure is unrelated. @shahmishal?
Otherwise this LGTM.

authors: CodaFi harlanhaskins slavapestov


text:
Update README for new target names

@swift-ci smoke test and merge

@swift-ci smoke test and merge

Hmm. Why did the smoke tests not run? 😕
@swift-ci please smoke test and merge

authors: CodaFi Jumhyn varungandhi-apple


text:
[ast] Rename VarPattern -> BindingPattern.

VarPattern is today used to implement both 'let' and 'var' pattern bindings, so
today is already misleading. The reason why the name Var was chosen was done b/c
it is meant to represent a pattern that performs 'variable binding'. Given that
I am going to add a new 'inout' pattern binding to this, it makes sense to
give it now a better fitting name before I make things more confusing.

Its actually a NFC.

@swift-ci test

TSPL refers to it as “value-binding pattern”. Should it be reflected here (i.e. ValueBindingPattern) or should TSPL be updated? Or does it not matter at all?

I don't think it matters. And I am not sure the larger name helps. I am trying not to change things in a large way. Only what I need.

@theblixguy the bigger change here is that I am going to change how it represents lets/vars to use a true kind + exhaustive switches instead of isLet(). That will make it easier to update this later. This is just the first in a series of changes.

authors: gottesmm theblixguy


text:
id-as-Any support

What's in this pull request?

Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

Apparently direct casting is all working now!
But indirect casting
(bouncing through Any) fails in really strange ways, without reaching
any known stdlib entry points.

@swift-ci Please test Linux platform

@swift-ci Please test and merge

@swift-ci Please test and merge

@swift-ci Please test and merge

@swift-ci Please test and merge


text:
[Reflection] Fix iterateAsyncTaskAllocations.

Fix the declaration of AsyncTask and add a test for iterateAsyncTaskAllocations. Reflection's declaration of AsyncTask had fallen out of sync with the real thing. The test that was supposed to catch this was never actually committed, oops.
While we're in there, switch out uses of Builtin.getCurrentAsyncTask for the less error prone _getCurrentAsyncTask.
rdar://80035307

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - f0e41d7414ae943e156e68664e08620cab74c723

Build failed
Swift Test OS X Platform
Git Sha - f0e41d7414ae943e156e68664e08620cab74c723

@swift-ci please test

@swift-ci please test

@swift-ci please test

authors: mikeash swift-ci


text:
AllocStackHoisting: fix the check for availability-checks

This is not a function call anymore, but a builtin
rdar://87090714

@swift-ci test


text:
sema: set locator properly when diagnosing constness mismatches

rdar://90210674

@swift-ci please smoke test


text:
Add descriptive doc comments to withMemoryRebound(to:capacity:_:) and…

… bindMemory(to:capacity:).
SR-2480: Improve documentation for withMemoryRebound(to:capacity:_:)
rdar://problem/28440528

––– CCC Information –––
• Explanation: Users migrating to Swift 3 often hit a compiler error with a diagnostic pointing them to this API. I have interacted with several developers who don't understand how to use the API. A more detailed description was necessary in the doc comments.
• Scope of Issue: Developers migrating to Swift 3 and using UnsafePointers.
• Origination: SE-0107 UnsafeRawPointer--terse doc comments.
• Risk: None whatsoever.
• Reviewed By: Dave Abrahams
• Testing: None needed.
• Directions for QE: None

@swift-ci test.

@swift-ci test OS X.

@swift-ci test OS X

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 36f3921f65b3afb00582c4341800963bf0fb2c0e
Test requested by - @bob-wilson

This failed because it was merged before testing was completed.

authors: atrick bob-wilson shahmishal swift-ci


text:
Fix and re-enable test resilient_debug_value.sil

In non-asserts compiler we don't seem to get named llvm values.
rdar://102535969

@swift-ci test


text:
allow move-only types to conform to Sendable

Part of the reason why we do not want to
permit conformance to protocols for
move-only types is that they're
fundamentally wrong: all existing protocols
assume the type is copyable, so we'd be
allowing people to write conformances to
things that are not actually true.
The other aspect of it is that we may
need to change the runtime representation
for conformance descriptors of move-only
types. So we can't have these conformances
leaving residue at runtime. Luckily, that
means marker protocols would be OK,
since they leave no residue at runtime.
So for, now we're going to specifically
permit move-only types to conform to the
marker protocol Sendable since it's needed
for move-only types to work with concurrency.
All of the existing rules about mixing
move-only types with generics still apply.
That means you still can't turn it into the
existential any Sendable in any way at all,
despite it conforming. The purpose of the
conformance is purely to allow the concrete
instances to cross actor isolation boundaries
if it is actually Sendable.
resolves rdar://104987062

@swift-ci please smoke test and merge

@swift-ci please smoke test and merge


text:
[SILGen] Emit block after unreachable when emitting if/switch expressions

When emitting the underlying switch statement for a switch expression, we emit an unreachable if the subject is uninhabited. Statement emission code can handle this, but expression emission expects an RValue to handed back. To remedy this, emit an unreachable block that we can emit the rest of the expression emission code into. The SILOptimizer will then drop this unreachable block.
Resolves #66490

@swift-ci please test

@swift-ci please test Windows


text:
NFC: Remove ClangModuleLoader.h include from ExtInfo.h

This was unnecessarily pulling in a whole bunch of Clang headers when all was needed was a forward declaration.

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test


text:
Frontend: Add -experimental-skip-non-inlinable-function-bodies-is-lazy

This option causes the -experimental-lazy-typecheck and -experimental-skip-non-exportable-decls options to be inferred from the presence of -experimental-skip-non-inlinable-function-bodies. This new option is meant to be a temporary testing aid that allows lazy typechecking to be tested on projects without full build system support for passing the other flags to the right jobs.
Also, ignore -experimental-lazy-typecheck during interface verification jobs, since the flag does not make sense during that action but the driver will pass the flag down regardless.
Resolves rdar://118938251

@swift-ci please smoke test


text:
Handle implicit member references inside extensions of nested types

Within an extension, references to other members of the extended type are permitted without qualification. This is intended to work even when the extended type was a nested type, although members of the enclosing type are not visible in this case. In order to implement this, the type checker pre-checks to see if there are any members with this name and then rewrites the unqualified reference to a qualified one, based on an unresolved TypeExpr with the name of the enclosing type. Unfortunately, if the enclosing type is a nested type, that isn't going to work very well—we find the correct declaration, but fail to map it into context by virtue of not realizing where it came from. Fix this by explicitly checking for this case.
SR-3847

@swift-ci Please test

Oh I see, thanks.

Does that mean the fix makes sense? I admit I'm not very familiar with this part of name resolution.

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - ac5cb46c2c2e14201fc8fcb93bf74842c04da34b
Test requested by - @jrose-apple

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - ac5cb46c2c2e14201fc8fcb93bf74842c04da34b
Test requested by - @jrose-apple

@swift-ci Please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - ac5cb46c2c2e14201fc8fcb93bf74842c04da34b
Test requested by - @jrose-apple

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - ac5cb46c2c2e14201fc8fcb93bf74842c04da34b
Test requested by - @jrose-apple

mapTypeIntoContext() translates interface types to archetypes. Here, I think the code path is resolving an unbound generic reference, which implicitly gets generic parameters from context.

LGTM, by the way. Longer term, we should try to remove findDeclContextForType() altogether. It duplicates the DeclContext walk that's already done in AST/NameLookup.cpp, because we just throw out that information in UnqualifiedLookup. That's really stupid and it causes assertions because apparently the walk here is slightly different than the one name lookup does...

Test case added.
@swift-ci Please smoke test

Unrelated crash in serialization. @aciidb0mb3r, have you seen this before? Did you file it already?
3.	While type-checking expression at [/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/swiftpm/Sources/PackageGraph/PackageGraphLoader.swift:111:35 - line:111:118] RangeText="externalModuleDependencies.lazy.map({$0.name}).duplicates(modules.lazy.map{$0.name})"
4.	While loading members for 'LazyMapRandomAccessCollection' in module 'Swift'
5.	While deserializing 'init' (ConstructorDecl #11643)in 'Swift'
6.	While deserializing 'transform' (ParamDecl #22123)in 'Swift'

@swift-ci Please smoke test Linux

@jrose-apple Haven't seen that one, seems new

Another failure.

swift: /home/buildnode/disk2/workspace/swift-PR-Linux-smoke-test/branch-master/swift/lib/AST/ArchetypeBuilder.cpp:2484: auto swift::ArchetypeBuilder::getGenericEnvironment(swift::GenericSignature *)::(anonymous class)::operator()(swift::ArchetypeBuilder::PotentialArchetype *) const: Assertion `(inContext->isEqual(repInContext) || inContext->hasError() || repInContext->hasError()) && "Potential archetype mapping differs from representative!"' failed.

@swift-ci Please smoke test Linux

authors: aciidb0mb3r jrose-apple slavapestov swift-ci


text:
[Demangler] Fix assertion failure.

It's illegal to call node->addChild() with a NULL child argument; it's possible to construct unexpected Node trees by passing invalid manglings, and in this case that was causing popTypeAndGetChild() to fail (because the top node was not a Type node), which then meant that the call to addChild had a NULL child argument.
The simplest fix is to use createWithChildren() to do the node construction, because that function checks its arguments for NULLs.
rdar://125350219

@swift-ci Please smoke test


text:
[6.0][region-isolation] Dont crash when processing global actor isolated init accessors.

This just means that I stopped treating it like an actor instance isolated thing. This was fun to track down since ActorIsolation has a union in it that was being misinterpreted, leading to memory corruption... my favorite! = ).
rdar://129256560
(cherry picked from commit f035590784023f16136abd7b593151b3f0375829)

Going to add CCC in the morning

@swift-ci test

Original: https://github.com/apple/swift/pull/74321


text:
Fix HTTP client with incluster config

Remove inclusterconfig option https://github.com/appscode/searchlight/blob/master/docs/guides/cluster-alerts/json_path.md

Fixed

repo: appscode/searchlight


text:
[Docs]: Upgrade to Business Edition - Kubernetes

Is there an existing issue for this?

[X] I have searched the existing issues

Documentation Link
https://docs.appsmith.com/getting-started/setup/upgrade-to-business-edition/kubernetes
Discord/slack/intercom Link
No response
Describe the problem and improvement.
Rehaul the doc

fixed by https://github.com/appsmithorg/appsmith-docs/pull/1324

authors: danciaclara jnikhila

repo: appsmithorg/appsmith-docs


text:
Update disable-user-signup.md

Checklist
I have:

[x] run the content through Grammarly
[ ] linked to sample apps when relevant
[ ] added the meta description for each page in the PR
[x] minimized the callouts and added only when necessary
[ ] added the queryString parameter to the Tabs (if used)
[ ] masked PII in images. For example, login credentials, account details, and more
[ ] added images only when necessary
[ ] deleted the images that are no longer used for the updated pages in the PR
[ ] followed the image file naming convention while renaming or adding new images. (Use lowercase letters, dashes between words, and be as descriptive as possible)
[ ] used the <figure/> tag instead of a markdown representation for images
[ ] added the <figcaption/> tag to add a caption to the image
[ ] added the alt attribute in the <img/> tag
[ ] verified and updated the cross-references or created redirect rules for the changed or removed content
[x] reviewed and applied the style changes for UI formatting. For example, Bold the UI elements(Buttons on screen) used in the doc.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant DevDengChao


text:
Test-event-driver docker command

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks
Docker commands for ted:
docker run --name appsmithted -d -p 2222:22 -p 5001:5001 -p 3306:3306 -p 28017:27017 -p 5432:5432 -p 25:25 -v `pwd`/git-server/keys:/git-server/keys -v `pwd`/git-server/repos:/git-server/repo --pull always appsmith/test-event-driver

Here's the repository link : https://github.com/appsmithorg/TestEventDriver

The issue here is that connecting to MySQL from the TED image doesn't work, and throws an SSL error sporadically. Disabling SSL also doesn't help.
Currently on-hold since MySQL doesn't seem to be coming up in the latest TED image which @Parthvi12 is looking into. Once that is running, I'll investigate the original issue again.

repo: appsmithorg/appsmith


text:
[Bug]: Auto-layout Jank issues

Is there an existing issue for this?

[X] I have searched the existing issues

Description
I have a few radio buttons in my app, and based on which radio button is selected a different input widget is shown - https://share.cleanshot.com/ZyXJsn86
If you see the GIF carefully, you will see that the input widget and date picker widget shifts a bit whenever the radio button selection is changed. This jank makes the UI look a bit bad. The logic to toggle between the input widget and date picker is very simple and is working perfectly.
I can confirm that this jank was not there before using auto layout. But after I started using auto layout, I am seeing this issue. Hopefully, this UI issue can be fixed.
Steps To Reproduce
Try a similar setup as described in the GIF here,
https://share.cleanshot.com/ZyXJsn86
Public Sample App
No response
Environment
Production
Issue video log
No response
Version
Cloud & Self - Hosted > 1.9.19

@narhzih Request you to correct the app version to Appsmith Community v1.9.20.4

@aswathkk I believe this is happening coz of row gap issue. Can you confirm?

Closing as we have a new layout builder

authors: Nikhil-Nandagopal aritraroy marks0351 narhzih


text:
[Task]: FE changes for Homepage experience - Search bar

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks

[ ] 1. Search bar UI
[ ] 2. API integration
[ ] 3. Real-time filtering to server side search with debounce
[ ] 4. Cypress

Reduced 0.5sp from this ticket as we are tracking cypress changes in this ticket https://github.com/appsmithorg/appsmith/issues/28980

fixed and merged in release. Hence closing the ticket


text:
bug: adjust WDS caption text style

Currently it's bigger than body text, should be smaller than that (close or identical to footnote if we have range between that and body).

@ichik Is this issue ready to pick up? If yes, can you tell me the value we need for caption? I'll update it.

@jsartisan discussed on a call: just one (or two) steps smaller than body text.

authors: ichik jsartisan


text:
[Task] Move the dataTree diff calculations back to worker

Diff calculation takes about 100ms and is directly proportional to data, so could be very high in some cases.
This was moved to main thread from worker to unblock a user. This was misdiagnosed as the diffs on workers being the reason.
Moving the diffs to main thread does effectively the same thing, there was no issue reported related to it in the last 30days.

@somangshu The data tree diff is taking 10-25 ms on the main thread (checked on multiple apps, depending on the size of the data tree). Moving this to worker thread should bring down time by the same.

Moving this to the icebox and out of the sprint, We do not plan to work on this right now.

authors: SatishGandham ayushpahwa somangshu


text:
test: Cypress | SetWidget property validations + CI Stabilize

Description

This PR added validations for SetWidget properties

Flaky fixes below:

/Widgets/Others/IconButton_2_spec.ts

Type of change

Script fix (non-breaking change which fixes an issue)

Testing

How Has This Been Tested?

[X] Cypress CI runs

Checklist:
QA activity:

[X] Added Test Plan Approved label after Cypress tests were reviewed

/ci-test-limit runId=6641552552

/ci-test-limit runId=6641552552

/ci-test-limit runId=6641552552


text:
chore: add analytics event for query failure post schema fetch pass

Description

Add event to capture scenario where the schema fetch succeeds but data fetch fails for schema preview page.
Fix a bug where the error message and error type values were interchanged before the Appsmith plugin exception was returned to client.

Fixes #28535 #28618
Media

Type of change

Bug fix (non-breaking change which fixes an issue)
Chore (housekeeping or task changes that don't impact user perception)

Testing

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Also list any relevant details for your test configuration.
Delete anything that is not relevant

[x] Manual
Not aware how to add automation test for this at the moment.

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test

/ok-to-test


text:
Adopt a volume-mounting Docker syntax that allows colons in path names

Is your feature request related to a problem? Please describe.
Please refer to https://github.com/appsody/appsody/issues/31
Describe the solution you'd like
Please refer to https://github.com/appsody/appsody/issues/31
Describe alternatives you've considered
Please refer to https://github.com/appsody/appsody/issues/31
Additional context
https://github.com/appsody/appsody/pull/338 is raised in appsody, a similar change in controller in this repo would compliment it

cc @kewegner

@gireeshpunathil why would the controller need this? The controller does not run docker commands.

The controller uses the APPSODY_MOUNTS environment variable in the case there are no APPSODY_WATCH_DIRS.
If we change the value of APPSODY_MOUNTS to have something other than ";" as a separator, the logic in the controller would have to change, because it splits on ";".  See line 269 of main.go.

Ok, so to clarify, adopting the docker --mount syntax to allow colons does NOT need controller changes.
However if as a result we change the APPSODY_MOUNTS separator, then yes the controller needs to support this.

When this issue is done, we would also want to consider the separator for the APPSODY_WATCH_DIRs and the APPSODY_WATCH_IGNOREDIRS (PATHS).  Since those are in a list using ';' as the separator.

We should address https://github.com/appsody/controller/issues/31 at the same time.  Also the changes we made for single mount testing might be affected.

I have started to code this up and will work with @rykal-nate  prior to Friday.

authors: gireeshpunathil kewegner kylegc

repo: appsody/controller


text:
Add ARG to allow appsody to pass docker-options for build-arg - WIP DO NOT MERGE

Checklist:

[ ] Read the Code of Conduct and Contributing Guidelines.

[ ] Followed the commit message guidelines.

[ ] Stack adheres to Appsody stack structure.

Modifying an existing stack:

[ ] Updated the stack version in stack.yaml

Contributing a new stack:

Describe how application dependencies are managed:

Explain how Appsody file watcher is utilized:

Describe other Appsody environment variables defined by the stack image:

Describe any limitations and known issues:

Related Issues:

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Ragu Kattinakere seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@raguibm - Thanks for raising this. Please could you raise this as two separate PR's? (one for microprofile and one for open liberty)

authors: Kamran64 claassistantio raguibm

repo: appsody/stacks


text:
🐛 Bug Report: Project creates two times

👟 Reproduction steps

Go to the console https://cloud.appwrite.io/console
Click "Create project"
Go trough the setup proccess

👍 Expected behavior
It should take me to the new project page right after clicking the button (of course with some delay because of some async stuff).
👎 Actual Behavior
At the end after clicking the "Create" button, nothing happens even after waiting a few seconds, but after I click it the second time, it takes me to the new project page. However now when I go to the console again, I can see two projects named the same, even tho I just wanted created one.
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[x] I have read the Code of Conduct

Also I apologise for accidentally creating the issue in the website repo, I had to move it here

Can reproduce this, probably a state management issue which re-enables the Create button before the setup is completed.
I proceeded to click the Create three times and 3 projects were created. Also note, if you provide a Project ID then the multiple projects will not be created and an error will be thrown.

Can reproduce this, probably a state management issue which re-enables the Create button before the setup is completed.
I proceeded to click the Create three times and 3 projects were created. Also note, if you provide a Project ID then the multiple projects will not be created and an error will be thrown.
Probable source -
https://github.com/appwrite/console/blob/737457c1446318c4f39fcc373024537af1bc09b6/src/lib/layout/wizard.svelte#L103-L105

Does the setTimeout() function have any purpose? Because I feel like this part of code doesn't make sense with the timeout there.

This is fixed in a recent release

authors: Honzoraptor31415 ItzNotABug ernstmul

repo: appwrite/console