text:
IRGen createTypeMetadataAccessFunction crash

Description
The following code causes the compiler to crash:
@available(macOS 10.15, iOS 13.0, tvOS 13.0, watchOS 6.0, *)
public struct MakeExplode<Element, Source: Sequence> where Source.Element == () async -> Element {}

Steps to reproduce
Add the above code to a file in a Swift package and attempt to compile.  The essential part seems to be the constraint to an async function whose return type is another type parameter (removing async or replacing Element with a specific type like Int avoids the crash).
Expected behavior
The code should either compile or trigger a compile error, but not a crash.
Environment

Swift compiler version info: swift-driver version: 1.75.2 Apple Swift version 5.8.1 (swiftlang-5.8.0.124.5 clang-1403.0.22.11.100) Target: x86_64-apple-macosx13.0
Xcode version info: Xcode 14.3.1 Build version 14E300c
Deployment target: macOS 10.13, iOS 11

Stack trace:
SwiftStackTrace.txt

Narrow down this issue to the implementation of mangledNameIsUnknownToDeployTarget

We may fix the issue on the open-source Swift side. But it probably will not solve the original issue.
And I do hope someone at Apple who is familiar with Xcode's private Swift fork can help take a look at this.
Tell us why Xcode's Swift will not crash for "iOS 14" test case. And why it will crash for iOS 13- iOS device platform.

cc @AnthonyLatsis

authors: Kyle-Ye aetherealtech


text:
Form a GenericSignatureBuilder for a RequirementEnvironment as needed.

In a number of cases, we would form a GenericSignatureBuilder as part
of computing the RequirementEnvironment, only to throw it away when we
realized we didn’t need it. Stop doing that.

8% speedup type-checking the standard library

@swift-ci please smoke test and merge

source: gharchive/pull-request

repo: apple/swift

license_type: permissive

license_source: github-api


text:
Make sure protocol witness errors don't leave the conformance context

That is, if there's a problem with a witness, and the witness comes from a different extension from the conformance (or the original type, when the conformance is on an extension), put the main diagnostic on the conformance, with a note on the witness. This involves some shuffling and rephrasing of existing diagnostics too.
There's a few reasons for this change:

More context. It may not be obvious why a declaration in file A.swift needs to be marked 'public' if you can't see the conformance in B.swift.

Better locations for imported declarations. If you're checking a conformance in a source file but the witness came from an imported module, it's better to put the diagnostic on the part you have control over. (This is especially true in Xcode, which can't display diagnostics on imported declarations in the source editor.)

Plays better with batch mode. Without this change, you can have diagnostics being reported in file A.swift that are tied to a conformance declared in file B.swift. Of course the contents of A.swift also affect the diagnostic, but compiling A.swift on its own wouldn't produce the diagnostic, and so putting it there is problematic. (See #16485.)

The change does in some cases make for a worse user experience, though; if you just want to apply the changes and move on, the main diagnostic isn't in the "right place". It's the note that has the info and possible fix-it. It's also a slightly more complicated implementation.

@swift-ci Please test

@swift-ci Please test source compatibility

Still needs new tests for the new behavior in addition to the updates for the existing tests, but I want to see if anything breaks, or if reviewers have objections.

For you and Graydon it was more a CC than a review request, I guess. "Here's the part I've been working on, here's the general approach I took". It's Huon and/or Doug, who've been working with conformance checking more, that I really want to look over this.

Now with tests for everything except the witness_non_objc_* diagnostics, which don't have any other tests except one lonely case that should probably be valid anyway (SR-7601). I can't figure out how to get the others to happen, so I'm leaving it for now.
@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test Linux

@swift-ci Please smoke test


text:
Resolve for https://bugs.swift.org/browse/SR-5846

This Pull request is intended for resolving a bug affected on arm32 ARMv7

Resolves SR-5846.

Thanks @chnmrc !

@swift-ci please test

Reading through the bug report, I'm not quite sure how this fixes it. It sounds like this might have been a compiler bug, does this convince the compiler to emit correct code, or was it something else? Should every architecture be using InlineRefCounts::Initialized like this?

There hasn't been any movement or activity here for a while, and the SR has lost its assignee.  When you find the time, please update the SR with the current behavior, and particularly what the current ASM dump looks like.  I'm really curious if this is a Clang bug.

authors: CodaFi chnmrc hpux735 mikeash


text:
Teach build-toolchain how to pass distcc down to build-script.

This just causes build-toolchain to pass --distcc to build-script.

@swift-ci smoke test


text:
[GSB] Avoid emitting associated type diagnostics on the protocol decl

For explicit abstract protocol floating requirement sources, get the source location from the protocol requirement rather than delegating to the parent RequirementSource. This allows us to diagnose on an associated type requirement directly rather than on the protocol declaration.
(Also, clean up a few unnecessary TypeLoc::withoutLoc()s)

Great idea, but can't RequirementSource provide this information itself? There's a note in RequirementSource::getLoc about why it's not doing it, but I don't understand it myself.

@swift-ci Please smoke test

Is this good to go?

authors: hamishknight jrose-apple slavapestov


text:
Revert "Temporarily disable stdlib tests depending on autorelease elision."

Reverts apple/swift#24049
The tests should work after apple/swift#23911
rdar://49791522

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 1e63ce77fbdc457f946d09a3df569bfc47c5a6c6

Swift(iphonesimulator-x86_64) :: SILOptimizer/definite_init_failable_initializers_objc.swift
failure is unrelated also fails here:
https://ci.swift.org/job/oss-swift-pr-test/7044/consoleFull#7528303603122a513-f36a-4c87-8ed7-cbc36a1ec144

@swift-ci Please smoke test macos

authors: aschwaighofer swift-ci


text:
Convert RST files to Markdown.

As requested by @lattner on the mailing list.
This is currently the result of running the following command in the root directory:
find ./ -iname "*.rst" -type f -exec sh -c 'pandoc "${0}" -o "${0%.rst}.md"' {} \;

I'm seeing a couple of similar artifacts that weren't handled well in the conversion, so will address those too. Unfortunately the diff is too big for GitHub, but an example can be seen here.

Yep, a pandoc conversion is just a starting point; after that, we need to manually fix up the output to look good in GitHub-Flavored Markdown again. There are a few docs that make extensive use of ReST features and we definitely don't want to regress usability for those—possibly even to the point of leaving them as ReST for now.
(Why GitHub-Flavored Markdown? Because most likely the most common way to view them will be on GitHub. If we can also get Kramdown compatibility that's great, because that's what our website uses, but that's just a bonus.)

Could I get some advice on how to convert the following type of thing?
.. default-role:: term
.. title:: Library Evolution Support in Swift ("Resilience")

:Author: Jordan Rose
:Author: John McCall

:Author: can just turn into regular text, and title…doesn't really fit on the GitHub page, although maybe it would work well in a Jekyll-style YAML front matter block.
default-role is a little more important: it means that everything in backticks in the document is being treated as a ReST term for the glossary at the bottom. Those can be turned into manual links and anchors.
(I wish GitHub Flavored Markdown supported definition lists in a non-HTML way, but we should probably reformat without them.)

Speaking of manual links and anchors, I just implemented some of that here.
I made some adjustments to respect the existing line limit. If that's not really a requirement anymore, please let me know.

@jrose-apple please let me know what you think of my efforts here.

This type of thing is also possible:

title
author
author

Library Evolution Support in Swift ("Resilience")
Jordan Rose
John McCall

but much more code:
| title                                             | author      | author      |
| ------------------------------------------------- | ----------- | ----------- |
| Library Evolution Support in Swift ("Resilience") | Jordan Rose | John McCall |

when compared to front matter:
---
title: Library Evolution Support in Swift ("Resilience")
authors: Jordan Rose, John McCall
---

It is a weekend today. :-) I'll come back and look through this carefully on Monday. Thanks for taking this on!

@jrose-apple thanks for reminding me :smile:
In no way did I expect any immediate feedback.
I was actually going to leave this for the day anyway. Enjoy the weekend!

@paulyoung The YAML front matter is probably preferable – that’s a fairly standard format for specifying info at the top of documents. Markdown tables are just icky.

All right, I got through the "A" docs and I have a fair number of comments already:

ReST lists using (1), (2), etc are coming through unformatted.
Several internal links are missing. In some cases this is also leaving a dangling trailing underscore (example).
note:: blocks are coming through with "note" in lowercase (example). It should probably at least be uppercase, but I'd actually suggest reflowing this to > **Note:** This rule...
Definition lists aren't supported, which already stinks, but it's specifically causing formatting issues for multi-line definitions (example).
Odd line breaks in blockquotes (example).
Inline CSS is just showing up as text (example). (You also missed some front matter there.)
GitHub Markdown doesn't support footnotes (example). I don't really know what we're going to do about this one.
(nitpick) URLs are no longer autolinked, so using Markdown <url> syntax would be nice.

Thanks for taking this on. Since I'm being fairly nitpicky about this conversion, it's okay if at any point you want to set it down and leave it to someone else. Another possibility might be to do this work in a public branch, so that others can help, but leave the main repo as ReST for now so that there remains only one way to build the docs for a normal user.

But i need helo at any cost so i have evidence againts offenders.
Eniro
Den 8. des. 2015 kl. 19.12 skrev Jordan Rose notifications@github.com:
All right, I got through the "A" docs and I have a fair number of comments already:
ReST lists using (1), (2), etc are coming through unformatted.
Several internal links are missing. In some cases this is also leaving a dangling trailing underscore (example).
note:: blocks are coming through with "note" in lowercase (example). It should probably at least be uppercase, but I'd actually suggest reflowing this to > Note: This rule...
Definition lists aren't supported, which already stinks, but it's specifically causing formatting issues for multi-line definitions (example).
Odd line breaks in blockquotes (example).
Inline CSS is just showing up as text (example). (You also missed some front matter there.)
GitHub Markdown doesn't support footnotes (example). I don't really know what we're going to do about this one.
(nitpick) URLs are no longer autolinked, so using Markdown  syntax would be nice.
Thanks for taking this on. Since I'm being fairly nitpicky about this conversion, it's okay if at any point you want to set it down and leave it to someone else. Another possibility might be to do this work in a public branch, so that others can help, but leave the main repo as ReST for now so that there remains only one way to build the docs for a normal user.
—
Reply to this email directly or view it on GitHub.
--
Confidentiality Notice: This e-mail transmission may contain confidential
or legally privileged information that is intended only for the individual
or entity named in the e-mail address. If you are not the intended
recipient, you are hereby notified that any disclosure, copying,
distribution, or reliance upon the contents of this e-mail is strictly
prohibited and may be unlawful. If you have received this e-mail in error,
please notify the sender immediately by return e-mail and delete all copies
of this message.

@jrose-apple yeah, I really only did some manual work on ABI.md and LibraryEvolution.md up until now
I was actually thinking it may be best to do this one document at a time to make it easier to review. It would also (hopefully) have a shorter turnaround time and reduce the probability of conflicts.
How does that sound to you?

Another suggestion is that it is probably best to tackle one or two documents at a time, to reduce conflicts with other parallel changes to the documents.

I'm happy to do things that way, but again I don't want to have the master branch have a mix of ReST and Markdown for an extended period of time. If both of you agree I'll make an rst-to-markdown branch in the main repository and we can do the docs one by one there. (And I'd suggest starting with the docs that haven't been significantly changed recently!)
What do you think?

@jrose-apple rst-to-markdown in the main repo sounds good to me.

I've added the branch. Let's start doing small pull requests there. Thanks, @paulyoung!

a question: why?
rST and ASCIIdoc are due to their extrensible nature a natural fit for technical documentation. creating yet another incompatible dialect of markdown is something nobody wants to see.
they easily allow to specify internal links that can be displayed with meaningful formatting, as well as external ones using intersphinx.
using rST or ASCIIdoc leads to works of beauty like this. observe how functions, classes, code samples, and links differ visually.
using markdown leads to generic, unlinked stuff like this

Good question. ReST is harder to write*, isn't what we're using for anything else (doc comments, proposals, website), and doesn't buy us much when most people will be reading the docs directly on GitHub anyway, which only supports very basic ReST. Most of the docs don't refer to the stdlib as it is today, nor to each other, meaning auto-cross-linking isn't so useful; they are designs, rationales, notes, and proposals.
It'd be a little different if we generated the docs somewhere for people to read, but even then I bet quite a few of them would end up looking at the version on GitHub anyway.
* My number 1 pet peeve with ReST is not being able to nest markup easily. Number 2 is that Sphinx exits early if you have any errors in your syntax.

On Dec 17, 2015, at 1:28 PM, Jordan Rose notifications@github.com wrote:
Good question. ReST is harder to write*, isn't what we're using for anything else (doc comments, proposals, website), and doesn't buy us much when most people will be reading the docs directly on GitHub anyway, which only supports very basic ReST. Most of the docs don't refer to the stdlib as it is today, nor to each other, meaning auto-cross-linking isn't so useful; they are designs, rationales, notes, and proposals.
It'd be a little different if we generated the docs somewhere for people to read, but even then I bet quite a few of them would end up looking at the version on GitHub anyway.

My number 1 pet peeve with ReST is not being able to nest markup easily.

That is annoying, but honestly the need for it is super-rare, and where I need it the most (markup within code, to emphasize certain parts), ReST is capable while Markdown is incapable.

Number 2 is that Sphinx exits early if you have any errors in your syntax.

That is a tunable behavior if I’m not mistaken.  We used to have it continue, but IMO that was worse, because silent errors crept into our docs.
IMO the main argument for Markdown is that it’s more broadly known and adopted.
-Dave

it’s sad to see semantic information being sacrificed.
i think hosting the docs somewhere different and linking to them from the repo’s readme and all the blog posts and whatever that will undoubtedly refer to them will serve well to make the official location pop up early on google.
about rST being hard to write: i only have problems with the inline link syntax, which matter more for things like forums/issue trackers, where you don’t have bigger sections of text with many link targets that are well-suited for the non-inline syntax. and the rest of the syntax is pretty nice, and, like markdown, learnable in a few minutes (“learnable” as in: you grasp enough to make meaningful changes)

authors: alexwlchan dabrahams flying-sheep jrose-apple kashRaja lattner paulyoung


text:
[CastOptimizer] Set the correct debug scope for the SILBuilder.

This is a recommit with a change to only run the test for
optimized stdlib [as the bug reproduces only there [as the bug reproduces only there]

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

Resolves SR-NNNN.

@swift-ci test and merge


text:
[CodeCompletion] Suggest the property name in its didSet clause

Previously, property names are hidden in the whole range of the declarations. Now, it's only hidden in its own initializer range.
Also, mark them as "NotRecommended" in their get accessors.
rdar://problem/49697202

@swift-ci Please smoke test

@swift-ci Please smoke test


text:
[AutoDiff] inline diff witnesses

Adds an optimization pass that inlines differentiability witnesses into functions that reference them, replacing differentiability_witness_functions with function_refs.
I named this "inliner" instead of "devirtualizer" because there is no runtime dynamism involved, which makes this seem more like inlining than devirtualization.
Unblocks https://github.com/apple/swift/pull/28451 by fixing the performance regression.
Resolves TF-919 and TF-994.

@swift-ci please test tensorflow

Could you please comment on how this patch impacts -O runtime performance?
Does it eliminate performance differences with current tensorflow HEAD?

I named this "inliner" instead of "devirtualizer" because there is no runtime dynamism involved, which makes this seem more like inlining than devirtualization.

There is runtime dynamism. The way it works is like protocol witness methods: there's no virtual dispatch, but there is dispatch -- the derivative is fetched at runtime. SIL devirtualizer applies to witness methods even though there's no virtual dispatch, so I think "devirtualizer" totally applies to differentiability witness functions.

The way it works is like protocol witness methods: there's no virtual dispatch, but there is dispatch -- the derivative is fetched at runtime. SIL devirtualizer applies to witness methods even though there's no virtual dispatch, so I think "devirtualizer" totally applies to differentiability witness functions.

This sounds good, I will rename it to devirtualizer

Given the similarity to the SIL devirtualizer, maybe it's easier to just add some logic in swift::tryDevirtualizeApply that handles DifferentiabilityWitnessFunction instructions.

Currently this would be pretty involved because the SIL devirtualizer starts at apply methods and looks for the callee. A lot of the callees in differentiation cases are hidden behind differentiable_function and differentiable_function_extracts.
The pass as written handles the devirtualization at the reference sites, avoiding this difficulty.

Could you please comment on how this patch impacts -O runtime performance?
Does it eliminate performance differences with current tensorflow HEAD?

In combination with #28451, -O performance is the same as tensorflow HEAD in the cases that I tested. Will add comment to PR description about this.

Currently this would be pretty involved because the SIL devirtualizer starts at apply methods and looks for the callee. A lot of the callees in differentiation cases are hidden behind differentiable_function and differentiable_function_extracts.

Makes sense. We need to to a proper differentiable_function-differentiable_function_extract folding pass at some point, after which we can revisit making tryDevirtualizeApply handle differentiability witness functions.

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow macos

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow macos

@swift-ci please test tensorflow macos

authors: dan-zheng marcrasi rxwei


text:
[stdlib] Silence a few assert related warnings

Silences warnings on variables that used only to check asserts. These variables appear unused to the compiler in no-assert builds.

@swift-ci please smoke test

The windows failure looks unrelated.

The Windows build error is fixed by https://github.com/apple/llvm-project/pull/1768

macOS failure is a LLDB test that was previously XFAIL-ed but is now passing.

Going to rebase and rerun tests, let me know if that's not the way to handle build failures.

The CI bots merge your tests with current master, so you don't technically need to rebase (but it doesn't hurt).

@swift-ci Please smoke test

Thanks, I wondered about that. Good to know.

@swift-ci please test Windows platform

authors: compnerd kastiglione tbkka theblixguy


text:
[5.4][android] Move to the NDK's unified sysroot

Explanation

Since the NDK removes the platforms/ and sysroot/ directories in the latest NDK 22, switch to the unified sysroot in toolchains/llvm/ and take advantage of a bunch of simplification that's now possible.
This is a cherry-pick of #34491 from trunk, only modifying the build-script-impl change slightly because of different source indentation than trunk and removing the single C++ Interop test change (that means that test will fail on this branch when tried for Android, but nobody is really running those tests for Android with the release branch).
It is needed because the latest Android NDK 22 finally deprecated the old organization of the Android cross-compilation sysroot, so the 5.4 releases won't build with NDK 22 and future NDKs without this pull.

Scope

Only affects building for Android, except for one Driver test change, which was approved by its author.

SR issue

None

Risk

Essentially none, as everything is scoped to Android only, except for the single, simple Driver test change.

Testing

I've run the tests natively on Android from the Jan. 11 source snapshot of this 5.4 branch with this pull applied, no problem.

Reviewer

@drodriguez

@swift-ci test

Windows CI failure appears spurious, probably just needs to be re-run:
ERROR: [WS-CLEANUP] Cannot delete workspace:
Unable to delete 'S:\jenkins\workspace\swift-PR-windows'.
Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.

@swift-ci test Windows

Windows CI failure appears spurious, probably just needs to be re-run:
ERROR: [WS-CLEANUP] Cannot delete workspace:
Unable to delete 'S:\jenkins\workspace\swift-PR-windows'.
Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.

cc: @compnerd

@drodriguez, since you merged this into trunk, put you down here as reviewer too. I think if you approve, this is ready to merge into this branch too.

Sorry, I didn't understand I had to say something.
This is OK to be merged. The scope is pretty limited to Android. This will allow the 5.4 branch to be more future-proof by allowing using more newer Android NDK if necessary.

seems okay given this is a cherry-pick of https://github.com/apple/swift/pull/34491

@compnerd @gottesmm: WDYT?

Ping, do one of the Swift 5.4 branch managers need to sign off on this? This is ready to go in.

Thanks, that's the largest patch I apply to the 5.4 branch when building it for Android, ten more to get into trunk (some of those are already in and others are specific to that app).

authors: buttaface drodriguez shahmishal tkremenek tomerd


text:
[test] Add variant name to test suite name

What's in this pull request?
To make it clear which platform are we testing.
...
PASS: Swift(linux-x86_64) :: Constraints/existential_metatypes.swift (272 of 2725)
UNSUPPORTED: Swift(linux-x86_64) :: Constraints/dynamic_lookup.swift (271 of 2725)
PASS: Swift(linux-x86_64) :: Constraints/existential_metatypes.swift (272 of 2725)
PASS: Swift(linux-x86_64) :: Constraints/dictionary_literal.swift (273 of 2725)
PASS: Swift(linux-x86_64) :: Constraints/function.swift (274 of 2725)
...

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.

@swift-ci Please test

😕 It seems, CI was not responding.
@swift-ci Please test

Linux: https://ci.swift.org/job/swift-PR-Linux/2943/console
macOS: https://ci.swift.org/job/swift-PR-osx/2669/console

authors: gribozavr rintaro


text:
[Demangler] Make isSpecialized() more robust.

We've had a couple of instances where Demangle::isSpecialized() crashed while while trying to use remote mirror to inspect a process that had itself crashed.  I can't see any obvious mechanism for that to happen, so for now I decided to make Demangle::isSpecialized() more robust in the hope that if it happens again we'll get more information and might be able to work out how it happened.
rdar://74394596

@swift-ci Please smoke test

@swift-ci Please clean smoke test Linux platform

@swift-ci Please clean smoke test Windows platform


text:
[Gardening] Update reference to SILProgrammersManual in docs

Caught an outdated reference to ProgrammersGuide.md which is now SILProgrammersManual.md.

@maustinstar May I ask that you resolve the conflict so that we can merge?

authors: AnthonyLatsis maustinstar


text:
Make the actor transport an associated type of the DistributedActor protocol

Eliminate the required use of existentials in distributed actors by
introducing the Transport associated type into the
DistributedActor protocol. Each distributed actor has a known
(concrete) actor transport type, reducing storage requirements and
transport dynamism when it isn't needed.
Distributed actors can manually specify their Transport associated
type or pick up a default by looking for a type named
DefaultActorTransport. A library that vends an actor transport can
make create a public typealias DefaultActorTransport referring to
its transport, so importing that library and defining a distributed
actor will use that library's transport.
Introduce a type-erased AnyActorTransport type to provide an
explicitly dynamic actor transport. This is still an important option,
e.g., for cases where one wants to be able to dynamically change the
transport for testing or different kinds of deployment. For now, we
default to this transport in the library (via DefaultActorTransport),
but we may very well want to eliminate this because it will be
ambiguous with client libraries that vend their own
DefaultActorTransport.

@swift-ci please test

@swift-ci please build toolchain

Build failed
Swift Test Linux Platform
Git Sha - c2ba06c3d27a21ecd9a65e41e798a4bc12aa8cba

Linux Toolchain (Ubuntu 16.04)
Download Toolchain
Git Sha - c2ba06c3d27a21ecd9a65e41e798a4bc12aa8cba
Install command
tar zxf  swift-PR-39985-723-ubuntu16.04.tar.gz
More info

Build failed
Swift Test OS X Platform
Git Sha - c2ba06c3d27a21ecd9a65e41e798a4bc12aa8cba

Could be real issues?

@swift-ci please test

I have a generalization of this PR that also de-existential-ifies the actor identity. I assume we want that on top of this, but didn't want to mess with this directly, so it's over at https://github.com/apple/swift/pull/40033.

authors: DougGregor ktoso swift-ci


text:
[Distributed] Unlock test which was ASAN failures in the past

This was very very likely solved by our ID/ActorSystem property ordering, this would have indeed triggered ASAN.
Resolves rdar://92277271

@swift-ci please asan test

@swift-ci Please ASAN test

ASAN not triggering hm :-\

@swift-ci please test

preset=buildbot_incremental_asan,tools=RDA,stdlib=RDA
@swift-ci Please test with preset macOS platform

authors: ktoso shahmishal


text:
[cxx-interop] Add conversions between std::u16string and Swift.String

This change adds a few extensions to the C++ stdlib overlay to allow convenient conversions between C++ UTF-16 strings and Swift strings.

@swift-ci please smoke test


text:
[Explicit Module Builds] Ensure IRGen uses Swift compiler's target triple when -clang-target is set.

The Clang importer's Clang instance may be configured with a different (higher) OS version than the compilation target itself in order to be able to load pre-compiled Clang modules that are aligned with the broader SDK, and match the SDK deployment target against which Swift modules are also built. In this case, we must use the Swift compiler's OS version triple in order to generate the binary as-requested.
The notion of using a different triple for loading Clang modules arises for the following reason:

Swift is able to load Swift modules built against a different target triple than the source module that is being built. Swift relies on availability annotations on the API within the loaded modules to ensure that compilation for the current target only uses appropriately-available API from its dependencies.
Clang, in contrast, requires that compilation only ever load modules (.pcm) that are precisely aligned to the current source compilation. Because the target triple (OS version in particular) between Swift source compilation and Swift dependency module compilation may differ, this would otherwise result in builtin multiple copies of the same Clang module, against different OS versions, once for each different triple in the build graph. Instead, with Explicitly-Built Modules, Swift sets a -clang-target argument that ensures that all Clang modules participating in the build are built against the SDK deployment target, matching the Swift modules in the SDK, which allows them to expose a maximally-available API surface as required by potentially-depending Swift modules' target OS version.

For example:
Suppose we are building a source module Foo, targeting macosx10.0, using an SDK with a deployment target of macosx12.0. Swift modules in said SDK will be built for macosx12.0 (as hard-coded in their textual interfaces), meaning they may reference symbols expected to be present in dependency Clang modules at that target OS version.
Suppose the source module Foo depends on Swift module Bar, which then depends on Clang module Baz. Bar must be built targeting macosx12.0 (SDK-matching deployment target is hard-coded into its textual interface). Which means that Bar expects Baz to expose symbols that may only be available when targeting at least macosx12.0. e.g. Baz may have symbols guarded with __MAC_OS_X_VERSION_MIN_REQUIRED >= __MAC_12_0. For this reason, we use -clang-target to ensure Baz is built targeting macosx12.0, and can be loaded by both Foo and Bar.
As a result, we cannot direclty use the Clang instance's target triple here and must check if we need to instead use the triple of the Swift compiler instance.

@swift-ci test


text:
[Linux] Make sure we install libexec.

We weren't installing the libexec component for Linux.
rdar://112662487

@swift-ci Please smoke test

@swift-ci Please smoke test Windows platform

I'm not confident that this has actually fixed the problem; it should have, but testing locally I still don't see the installed content. Going to keep looking at this.

Looks like there's a typo in stdlib/cmake/modules/AddSwiftStdlib.cmake. Testing now to make sure that's the final piece of the puzzle. Will raise a separate PR to fix that as well.

See also #67505


text:
Update release/5.10 for update-checkout

The release/5.10 specification of update-checkout on the main branch was out-of-date and didn’t clone e.g. zlib. This caused CI testing for the release/5.10 branch of swift-syntax to fail.

@swift-ci Please smoke test


text:
Add a test for the SIL type equality assert failures due to opaque re…

…turn types.
This is the test part of https://github.com/apple/swift/pull/70865 which was fixed by the commit
https://github.com/apple/swift/commit/8d649a252505d3132ffae47985d005cc2e1d070e

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test Windows platform

@swift-ci Please test Windows platform

@swift-ci please test Windows platform

@slavapestov I think this is what you requested here. Can you take a look?

authors: compnerd hjyamauchi


text:
[region-isolation] When inferring isolation for an argument, handle non-self isolated parameters as well as self parameters that are actor isolated.

[region-isolation] When inferring isolation for an argument, handle non-self isolated parameters as well as self parameters that are actor isolated.
As part of this I went through how we handled inference and rather than using a
grab-bag getActorIsolation that was confusing to use, I created split APIs for
specific use cases (actor instance, global actor, just an apply expr crossing)
that makes it clearer inside the SILIsolationInfo::get* APIs what we are
actually trying to model. I found a few issues as a result and fixed most of
them if they were small. I also fixed one bigger one around computed property
initializers in the next commit. There is a larger change I didn't fix around allowing function
ref/partial_apply with isolated self parameters have a delayed flow sensitive
actor isolation... this will be fixed in a subsequent commit.
This also fixes a bunch of cases where we were printing actor-isolated instead
of 'self' isolated.
rdar://127295657

NOTE: The third commit is the commit that fixes inferred isolation in property initializers in actors.
rdar://127844737

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test


text:
[6.0][ScanDependencies] Make sure canImport resolution agrees with import

Explanation: Fix a problem where the error of cannot import module can be confusing when the only module can be found is an invalid/out-of-date swift binary module because canImport and import can have different views on if the module can be import or not.
Scope: Provide a better error message to help user understand the failure in such case and canImport will be evaluated to false when the "module" found is invalid.
Issue: rdar://128876895
Original PR: https://github.com/apple/swift/pull/74199
Risk: Low
Test: Unit Test
Reviewer: @artemcm

@swift-ci please test

@swift-ci please test


text:
Revert "Index: Expose the logic for deciding whether to index a symbol. NFC. (#8438)"

We currently don't need this logic elsewhere, thus it's good to give
indexer some privacy.

@swift-ci please smoke test and merge


text:
WIP - feat: スケジュールイベントの通知機能を追加

Type of Change:
追加
Details of implementation (実施内容)
スケジュールイベントが追加されたり、削除されたりしたら #無法地帯 で通知する機能を追加します。

めんどくさくなっちゃった

license: MIT


text:
Update incorrect Cloud66 documentation

The suggested code doesn't work for cloud 66, as the environment variable in the example doesn't seem to exist. I also believe having it as a root-level item in the yaml file doesn't work.
I've replaced it with code that we use within our stack.

Thank you for sharing that, if the configuration for revision on cloud66 is the same as defined under ruby docs then there is no point in having the same instructions in 2 different places so I am going to close it.
https://github.com/appsignal/appsignal-docs/pull/448

authors: LimeBlast shairyar

repo: appsignal/appsignal-docs

license: mit

license_source: bigquery


text:
Fix: Custom Authentication page rehaul

Rehauls the Custom Authentication page.

Turns "Custom Authentication" sidebar item into a category with 1 sub-page

sub-page: Third-Party OAuth

Holds service-specific video tutorials for Xano (17min) and Supabase (44min)

Rewrote instructions for setting up custom auth login

Notion
Ticket
Resolves #879

Waiting for info on refreshing tokens

authors: danciaclara spark-c

repo: appsmithorg/appsmith-docs


text:
[Feature]: Make Map functions easier for select and select like widgets

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
Some users find it confusing to use the Map function to connect data to the select function. It is currently needlessly confusing for new users.
To solve this, a simple set of dropdown would help to solve this issue.
Creating a dropdown like this will allow users to select the Data source (if that is a query, API, Local store, or JS function/variable from which they would like to pick the Value and label.
A wireframe can be seen here:

Why should this be worked on?
This will greatly help new users grasp how to connect their data to select commands. it will allow existing users who are uncertain about the Map function to quickly create select and select like widgets.

Stats

Stat
Values

Reach
4000

Effort (months)
0.5

4000 since the number of users who use select like widgets are:

Widget name
users in 6 months

SELECT_WIDGET
1,117

SINGLE_SELECT_TREE_WIDGET
1,007

MULTI_SELECT_TREE_WIDGET
855

MULTI_SELECT_WIDGET_V2
660

MULTI_SELECT_WIDGET
339

source: gharchive/issue

repo: appsmithorg/appsmith


text:
[Bug]-[42000]:Welcome tutorial 5th Step, binding image to table data errors out as the backend seems to have changed.

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Signup as a new user, login and go through the Welcome Tutorial - reach the step 5 of 9, and try to bind the image widget with - {{CustomersTable.selectedRow.image}}, an error pops up - "This value does not evaluate to type: base64 encoded image | data uri | image url"
Steps To Reproduce

Go through the welcome tutorial and reach step 5 of 9
On binding the image to {{CustomersTable.selectedRow.image}}, an error pops up

This value does not evaluate to type: base64 encoded image | data uri | image url
On checking the table for image column value, there are no images there, and just a text T1C.
Looks like the database has got changed/updated. For welcome tutorial, this is not a great experience for the user.
Public Sample App
No response
Version
Production

Stats

Stat
Values

Reach
7000

Effort (months)
0.5

The mock users db does not seem to have a valid image url. The db needs to be reset to default data.
@kocharrahul7 @sum35h

@akash-codemonk  could you use the users table in the fakeapi db.

Closing this till we can reproduce it

Able to repro on both release and prod

@yaldram can you syncup with @vivekverma2312 on this issue.

It seems to work for me now but this is bound to happen when the image value isn't a valid url. Maybe we should just remove the image field step as it is required that it to be a valid url else it will fail which is not the case for the other text fields.

@akash-codemonk yeah that makes sense. We can autobind the image and not keep it as a mandatory step in the onboarding

If the image URL is invalid, then it won't work even if it is auto-bound. The issue is the image value itself, not really the binding process as far as I can tell right @akash-codemonk

Currently the user will not be able to proceed further if the image field is not a valid url. So if we remove that step then the user can proceed further whether it is invalid or not. We autobind the image widget so that the image widget is still there and it will show the image if the image url is valid else it will show the default image.

Okay, got it. can we fix this on Priority

This is resolved, closing it off.


text:
[Bug]: Menu button dropdown width is inconsistent

Is there an existing issue for this?

[X] I have searched the existing issues

Description
When I place a menu button and make it small I expect the dropdown to adjust its width based on the items in the menu. When you do this on the canvas it seems to work fine.
When you make a small menu button inside of a container the dropdown is skinnier and truncates the options.
Steps To Reproduce

Create a new app
Drag a container onto the canvas
Drag a menu button onto the canvas and reduce its width to make a small button
Click the button and observe that the dropdown is wide enough to read all of the text
Drag another menu button into the container, also reducing it's width
Click the new button and observer that the dropdown is skinny and the text is truncated

Public Sample App
No response
Version
Cloud 1.7.8

The width of the component is too wide, and it looks odd.
It's not direly important in terms of functionality but I'll look better if there wasn't so much white space.

If I place it inside a container it works better but it is still not perfect because it's width is being inherited from the width of the button.
![Image 2022-10-03 at 11 55 59 PM](https://user-images.githubusercontent.com/163

7462/193673110-1f4ea7e9-b644-41a4-82e4-8ba7317926f8.jpg)
As you can see in the two pictures I'm not able to use an icon only button at the smallest size.

authors: AS-Laguna vishaldfreak


text:
[Bug]: Placeholder on input widget property pane overlaps

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Placeholder for regex field on input widget property pane overlaps
Steps To Reproduce

Public Sample App
No response
Environment
Deploy Preview
Severity
Low (Inconsistent UI/UX)
Issue video log
No response
Version
cloud

Please pick an issue marked Good first issue or hacktober @akshat8605


text:
Task: remove the start from tempaltes and generate crud page prompts that we get on the first page of any new app

Reopening due to failing related cypress specs, will be fixed completely in #34037


text:
[Feature]: Remove isFocus and isDirty prop from evaluations in InputField

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
I have noticed that for an onFocus event which sets isFocussed meta value to true of an inputField triggers an evaluation. What is the necessity for triggering an evaluation here, I thought another widget could tap this widget's focussed state but that property does not appear to be accessible there. Is it necessary an evaluation needs to be triggered here can we remove it? If there are multiple input widgets in a page i can imagine evaluations to be frequently triggered just by the user moving his cursor around.
Why should this be worked on?
Reducing the number of evaluations run on a page will greatly improve the performance of the application.

hey @jacquesikot could you please explain a little more about this issue?


text:
[Feature] Allow users to copy evaluated values

Summary
Evaluated value popup should have a copy button to copy the evaluated value.

@mohanarpit @ayushpahwa Hey team! Can you please add your planning poker estimates with ZenHub

authors: ajinkyakulkarni riodeuno


text:
[Feature] Appsmith can ship with a DB

Description
Appsmith can ship with a lightweight database that users can use for their apps. The database can contain mock data as well as allow users to store any intermediate data they want to save. The database could be a lightweight JSON DB as well.
Motivation
Not all users have a database and would like to explore the possibilities of creating apps on appsmith.
This improves the experience of mock data on appsmith.
Sometimes configs can be stored on a separate database instead of the core prod DB

Duplicate of #2506


text:
feat: Autoassigns column datatype in table widget

Description
Picks up the first non-null value for every column in tableData and assigns datatype to the column to that value
Limited to checking for non-null values till maxRowsToCheck rows
Fixes #12831
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Jest tests

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] 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

/ok-to-test sha=e775589

@souma-ghosh On changing the type of a value, it isn’t reflecting on the table (In this case, I changed a boolean value to string). Not sure if this pertains to this PR. Could you have a look and confirm please?
https://www.loom.com/share/a5afac6d7b3e4a419dcbc57d77e94b62

@souma-ghosh On changing the type of a value, it isn’t reflecting on the table (In this case, I changed a boolean value to string). Not sure if this pertains to this PR. Could you have a look and confirm please?
https://www.loom.com/share/a5afac6d7b3e4a419dcbc57d77e94b62

@sbalaji1192 @dilippitchika Should we try to switch the data type if the user changes the table data manually as shown in the above video?

@souma-ghosh We don't have to. We're only going to guess the type when a column is generated. we don't have to keep guessing every time the table data changes.
CC @dilippitchika

If everything else is working fine we can go ahead with the current solution then @laveena-en

Agreed with balaji, we only guess the first time. After that, it's the users responsibility to manage them.

Yes, we can go ahead with this.
Tested and verified for data that consists of:

String
Number
Boolean values

@laveena-en what about dates?

@dilippitchika Dates have not been handled yet. For us to confirm whether a column data is date type or not it has to be a valid ISO or UTC format or another format we explicitly specify. So should we cannot guess a column to be of type date unless we know what format/formats we are expecting

/ok-to-test sha=fd70e6b

/ok-to-test sha=fd70e6b

/ok-to-test sha=8d07cdf

/ok-to-test sha=e42ee65

/ok-to-test sha=e42ee65

/ok-to-test sha=518bf59

/ok-to-test sha=95dd1f0

@souma-ghosh As discussed, it seems like for a specific date format (22/09/2022 18:30), the date seems to be seen as a number instead. Please do have a look.

https://docs.google.com/spreadsheets/d/1H-IEkVGRlD4W37TRq9bQ3j63YFAbvAYKSSomTp-zurA/edit?usp=sharing

@souma-ghosh As discussed, it seems like for a specific date format (22/09/2022 18:30), the date seems to be seen as a number instead. Please do have a look.  https://docs.google.com/spreadsheets/d/1H-IEkVGRlD4W37TRq9bQ3j63YFAbvAYKSSomTp-zurA/edit?usp=sharing

As we saw in the computed value for the api we are using here, we get a number not a string for Date9 column. Since any number can be considered as a millisecond date format, whenever we get a number in the data we assign the column as number type column first. If the and only if we get a string type data we will assign the column as Date type or String type accordingly. So this behaviour is correct

LGTM!

/ok-to-test sha=59ef853

/ok-to-test sha=3b95e5b

authors: dilippitchika laveena-en sbalaji1192 souma-ghosh


text:
fix: Null check before accessing the column sticky property in Table Widget

Description
Fixes #22207
The sentry issue occurred because the code was trying to access the sticky property of a column that did not exist in the table widget. Hence to mitigate this I have added an optional chaining check.
Type of change

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

How Has This Been Tested?

Manual

Check that the console error is not thrown similar to the above sentry issue.

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
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

/ok-to-test sha=24466e2

/build-deploy-preview env=release


text:
Fix Account.swift after parameters rename

What does this PR do?
Fixes incorrectly renamed parameters in Account.swift file, which prevents projects using Appwrite SDK from building.
Test Plan
Project started building after fixing compiler errors.
Related PRs and Issues
—
Have you read the Contributing Guidelines on issues?
Yes.

Unfortunately, this is a read-only repo as the code is generated by our SDK Generator, and changes made only here would be wiped in the next release.

repo: appwrite/sdk-for-apple


text:
fix(LGUG2Z/komorebi) fix executable files on Windows

as discussed here https://github.com/aquaproj/aqua-registry/pull/16629#issuecomment-1778714021

Thank you!

v4.75.0 is out 🎉
https://github.com/aquaproj/aqua-registry/releases/tag/v4.75.0

authors: CrystalMethod suzuki-shunsuke

repo: aquaproj/aqua-registry


text:
feat: add a8m/envsubst

https://github.com/aquaproj/aqua-registry/pull/5639 a8m/envsubst: Environment variables substitution for Go
$ aqua g -i a8m/envsubst

Thanks.

Released. https://github.com/aquaproj/aqua-registry/releases/tag/v3.34.0

authors: ponkio-o suzuki-shunsuke


text:
Add BPF map reuse function

Wrap bpf_map__reuse_fd to reuse a BPF map accross BPF programs. This
is useful in complex programs that long chains of calls, for example,
via bpf_tail_call that may be loaded in different programs and share
state via reused maps.
Why is this useful
Our global state map, called heap is shared by multiple programs.
Map reuse will soon become a load loading functionality for Parca Agent.
Test Plan
Added selftest +
[javierhonduco@fedora parca-agent]$ sudo bpftool map  | grep heap
3403: percpu_array  name heap  flags 0x0

2812: perf_event  name walk_user_stacktrace_impl  tag 25cb7e352f197144  gpl
        loaded_at 2023-08-01T16:06:01+0100  uid 0
        xlated 7984B  jited 4827B  memlock 12288B  map_ids 3399,3411,3401,3407,3400,3408,3409,3402,3406,3405,3403
        btf_id 1993
        pids parca-agent(1049424)
        metadata:
                name = "parca-agent (https://github.com/parca-dev/parca-agent)"
2814: perf_event  name profile_cpu  tag 3f2053ff90208ef1  gpl
        loaded_at 2023-08-01T16:06:02+0100  uid 0
        xlated 4368B  jited 2850B  memlock 8192B  map_ids 3411,3404,3399,3401,3408,3409,3405,3407,3403,3402
        btf_id 1993
        pids parca-agent(1049424)
        metadata:
                name = "parca-agent (https://github.com/parca-dev/parca-agent)"
2816: perf_event  name walk_ruby_stack  tag 97bb3ee23c47e22d  gpl
        loaded_at 2023-08-01T16:06:02+0100  uid 0
        xlated 87600B  jited 56572B  memlock 98304B  map_ids 3413,3414,3419,3415,3399,3403,3420,3417,3418
        btf_id 1994
        pids parca-agent(1049424)

We are thoroughly testing it, across multiple kernels and with ASAN
enabled, too.
If there were any problems in the future we will quickly notice them and
will be happy to submit bugfixes.

@javierhonduco thank your for your changes. As I commented I'll cherry-pick this and line it in with the on going changes.

Done: https://github.com/aquasecurity/libbpfgo/pull/356/commits/6883fbb33963a7f7748205dc689d90b9e44e80b7
Thanks again @javierhonduco. 🚀

authors: geyslan javierhonduco

repo: aquasecurity/libbpfgo


text:
update description

update starboard operation description
Signed-off-by: chenk hen.keinan@gmail.com

I agree documentation changes can be done incrementally to be targeted to v0.16.0.

closing, will create a separate PR for updateding description on straboard operation.

What do you think about listing installation options in the README? Half of the people will look in the README for installation and will only later consider opening the docs and the other half goes straight to the docs

What do you think about listing installation options in the README? Half of the people will look in the README for installation and will only later consider opening the docs and the other half goes straight to the docs

One big problem with installation steps in README is that they're not versioned. Compare how we install Starboard v0.14.1 and v0.15.0. We can do our best to maintain documentation with installation steps and links pinned to particular version, but I'm not sure about README.

authors: AnaisUrlichs chen-keinan danielpacak

repo: aquasecurity/starboard