text:
Can't call api of GraphQL HOC wrapped component

Steps to Reproduce
Describe how to reproduce this issue.

Wrap a component in the graphql HOC
When rendering the HOC component, define a ref
Use the ref to attempt to call a function on the wrapped component
Function not found, because ref refers to the HOC, not the wrapped component

Expected Behavior
I should be able to call methods of GraphQL wrapped components?
Version

apollo-client@0.5.23
react-apollo@0.5.13

Use case specific detail:

I have a user signup component (USC) that is designed as a wizard using http://www.material-ui.com/#/components/stepper.
USC controls the flow between steps.
Each step, renders a GQL wrapped component.
I need each step component to implement an api (i.e. isValid(), saveStep())
I need the USC to call this api, hence my issue.

Apologies, I've just found http://dev.apollodata.com/react/higher-order-components.html#with-ref

@dcworldwide Thanks for documenting the solution. I hope it's okay if I close the issue since there's nothing we can do about it. The issue will still be searchable by others who have the same problem.

authors: dcworldwide helfer

repo: apollostack/react-apollo


text:
[MH] added maintainers.md file

Signed-off-by: Matthias Holzer matthias.holzer@allianz.at

added a list of maintainers in the project root

Type of request

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Refactoring
[x] Documentation or documentation changes

Related Issue(s)

Concept

Description of the change

Description of current state
Description of target state
Estimated investment / approximate investment

20mins
Initiator
Matthias Holzer / Allianz Technology GmbH / Projectlead
Technical information
Platform / target area

known side-effects
other
DB Changes (if so: incl. scripts with definitions and testdata)
How has this Tested?

Screenshots, Uploads, other documents (if appropriate):

Checklist:

[x] All the commits are signed.
[x] My code follows the code style of this project.
[x] I agree with die CLA.
[x] I have read the CONTRIBUTING docs.
[x] I have added/updated necessary documentation (if appropriate).

Have a look to fix the codacy issues.

fixed ;)

source: gharchive/pull-request

repo: aposin/MergeProcessor

license_type: permissive

license_source: github-api


text:
Make function workers deploy globally on worker nodes

How to test
ampmake clean build
alias amp='amp -s localhost'
amp -cluster create --tag=local
. ./hack/ampenv
amp fn create banner bquenin/banner-function
echo 'ATOMIQ rocks!' | curl -k https://faas.local.atomiq.io/banner --data-binary @-
echo 'ATOMIQ rocks!' | curl -k https://faas.local.atomiq.io/banner --data-binary @-
echo 'ATOMIQ rocks!' | curl -k https://faas.local.atomiq.io/banner --data-binary @-
amps service logs amp_funcexec

Make sure from the logs that the functions are executed alternatively on workers, such as this:
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:38 Container created: ddeb1f7c81e82421e97091b4a78396506e85451bbb027549c4397f54d18f2359
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:38 Container started
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:38 Container attached
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:38 Transferred standard input (14 bytes)
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:38 Transferred standard output (378 bytes)
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:38 Function call executed
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:38 Function return successfuly submitted, call Id: 5abd0565c1f36f128ba1f7cc8087bd0ff7520394c5af8e692bf65af25f73aa2b
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:39 Function call received, call id: 31ec095a5a4efb5b7cf520adfa30db2430c76c73d1d5a90a7689fc48a82c1c5a
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:40 Container created: f8b7f5c15541ef3c98a6326bff4ca015c24cdec0c697b371033ffd4fb8f53a3e
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:40 Container started
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:40 Container attached
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:40 Transferred standard input (14 bytes)
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:41 Transferred standard output (378 bytes)
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:41 Function call executed
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:41 Function return successfuly submitted, call Id: 31ec095a5a4efb5b7cf520adfa30db2430c76c73d1d5a90a7689fc48a82c1c5a
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:42 Function call received, call id: 98438cf07e965d2c62130b90dd1139196eaf24fc3f8d2f7cdf7b61806a65dc5e
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:42 Container created: f8a6c86fe22c5d607221bd5df118194fa5f5c48da3278f1ae19bafb77bbea6f7
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:42 Container started
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:42 Container attached
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:42 Transferred standard input (14 bytes)
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:43 Transferred standard output (378 bytes)
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:43 Function call executed
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:43 Function return successfuly submitted, call Id: 98438cf07e965d2c62130b90dd1139196eaf24fc3f8d2f7cdf7b61806a65dc5e
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:44 Function call received, call id: 16a57ad90b2d7616f9a2f391fb3444553978dc4d2e2cd76b49f96d0fe4738207
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:44 Container created: 46b83daec771f8559b27a936bdc04a309b9996a1d4ee2702200d4a05397ccb69
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:44 Container started
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:44 Container attached
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:44 Transferred standard input (14 bytes)
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:45 Transferred standard output (378 bytes)
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:45 Function call executed
amp_funcexec.0.2x9vqgi1smbb@75717d43aff3    | 2017/04/25 23:50:45 Function return successfuly submitted, call Id: 16a57ad90b2d7616f9a2f391fb3444553978dc4d2e2cd76b49f96d0fe4738207
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:46 Function call received, call id: 66d748fb39cb3d2b7fd6a7e840b4467f1a6c3f2ded31ac3fcab28e14e38b1523
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:46 Container created: 2da187c35940482192e17f7605e7ea6734eee49560f85227f1e1b7f04a85a40c
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:47 Container started
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:47 Container attached
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:47 Transferred standard input (14 bytes)
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:47 Transferred standard output (378 bytes)
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:47 Function call executed
amp_funcexec.0.ukojzpf8usdw@a92191f714b0    | 2017/04/25 23:50:47 Function return successfuly submitted, call Id: 66d748fb39cb3d2b7fd6a7e840b4467f1a6c3f2ded31ac3fcab28e14e38b1523

obsoleted by #1138

repo: appcelerator/amp


text:
Use a Fragment to host the embed view to fix issues with Compose interop

Relates to various discussion in https://github.com/react-native-community/discussions-and-proposals/issues/446
Nesting our view inside of a Fragment is the only way I've found so far to get the desired behavior without destroying the underlying composition when it's removed from the window. This also requires the accompanying Android change https://github.com/appcues/appcues-android-sdk/pull/476

example: an embed targeted to every screen, but the frame only exists on the embeds tab
https://github.com/appcues/appcues-react-native-module/assets/19266448/a913ffed-2c87-4787-87bc-a8182fd952c7

example: embed targeted only to screen "Embed Container"
https://github.com/appcues/appcues-react-native-module/assets/19266448/c261edda-a22b-471d-8af6-9fba14fc9adc

example: embed targeted only to "Update Profile" (not the tab the frame is on)
https://github.com/appcues/appcues-react-native-module/assets/19266448/aeb5b524-f332-4406-a1d7-13afee2e3715

example: three embeds targeted to every screen (using all frames) + another flow on event1
https://github.com/appcues/appcues-react-native-module/assets/19266448/1a386dea-979f-4a9d-b75b-f84237a3471c

repo: appcues/appcues-react-native-module

license: MIT


text:
🛑 Registro Appio is down

In 716850d, Registro Appio (https://registro.appio.com.mx) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Registro Appio is back up in c17628c.

source: gharchive/issue

repo: appio-smart-kitchen/upptime


text:
Message component

fixes #40

+1

repo: appitierre/aptr-uikit


text:
[HashTreeCollections] Add TreeDictionary.combining(_:by:)

This adds an elaborate new entry point for structurally combining two TreeDictionary instances, complete with a deeply customizable element-wise combining strategy.
This PR is a proof of concept that may turn into a shipping feature. It currently builds, but it has not yet seen any testing whatsoever. The new APIs currently require Swift 5.7 or better, as they use primary associated types.
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).
[ ] I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions.
[ ] I've updated the documentation if necessary.

Rescheduling to 1.2.

repo: apple/swift-collections


text:
[CF] Add TARGET_OS_BSD in some places.

These particular uses should hopefully be uncontroversial.

CFPlatform.c: to use the _CFIsMainThread pthread implementation; to
properly implement __CFTSDSetSpecific and __CFTSDGetSpecific with the
same pthread implementation as Linux (and Mac)

CoreFoundation_Prefix.h: to exclude strlcpy and issetugid which is
normally available in the system; to include sys/param.h for the
MIN macro

CFData.c: for the __CFPageSize implementation

CFBundle_Resources.c: to include dirent.h symbols

CFXMLPreferencesDomain.c: to define sleep for the platform

CFBurstTrie.c: for mmap.

@swift-ci test and merge

repo: apple/swift-corelibs-foundation


text:
Add a sidenav navigator to the documentation pages (WIP behind a feature flag, off by default)

Bug/issue #, if applicable: 89031049
Summary
This PR introduces a few new UI changes, that are scoped only to the documentation pages. The features are all DISABLED, by default, but can be enabled by a feature flag in the theme-settings.json file, under features.docs.navigator.enable:

New adjustable layout
A sidebar tree navigator
Updated nav layout and breadcrumbs logic

This work covers both of the proposals:
https://forums.swift.org/t/new-swift-docc-content-styling/55326
https://forums.swift.org/t/swift-docc-sidebar/55250
Dependencies
https://github.com/apple/swift-docc/pull/84
Testing
Make sure you download and unzip the .doccarchive - SlothCreator.doccarchive.zip
Steps:

run VUE_APP_DEV_SERVER_PROXY=/path/to/SlothCreator.doccarchive npm run serve
Visit http://localhost:8080/documentation/slothcreator
Assert that a sidebar tree navigator is rendered.
Assert that you can open/close items and click on the links to navigate to a page
Assert that navigating across pages does not loose open/closed state. Even on refresh.
Assert that going back/forward works and re-highlights the current item you are on, opening all parents so its visible.
Assert you can filter on items and its not slowing down the browser even for very broad queries.
Assert that the navigation layout does not go outside of the content container
Assert that the navigation breadcrumbs reduce in size and collapse, based on screen size.
Assert that the content has a maximum width, after which it gets centered (around 1800px)

Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.

[x] Added tests
[x] Ran npm test, and it succeeded
[x] Updated documentation if necessary

@mportiz08

I also have one very high level concern that we should think about for this: what should the UX for this be when rendering older content (content with no index data yet). I realize that we won't be able to display any useful content in the sidebar in this situation, so maybe we should consider disabling/hiding the sidebar when that happens. Also, is there anything in the render JSON for the page itself that we can check that gives us an indicator that the index exists? If not, we could get into a situation where we get a 404 for the index on every page of older content where it hasn't been generated yet.

Very good question. Currently it just says there are no children available. We could hide the entire navigator in such cases, like we do for IDE targets, but then we might need to tune the css for content a bit.
As for the RenderJSON, apart from the schema version, I dont think there is anything else, right @ethan-kusters?

As for the RenderJSON, apart from the schema version, I dont think there is anything else, right @ethan-kusters?

Correct- we could consider bumping the patch version of the RenderNodeJSON when we enable emitting a RenderIndexJSON by default. That would be less than ideal since this isn't actually a change in the RenderNode schema though.
Is it possible to just check for the existence of the index file or would that cause a page flicker?

Is it possible to just check for the existence of the index file or would that cause a page flicker?

Well unless we delay the entire page until we have the sidebar stuff, it would flicker, yes.

@swift-ci test

@swift-ci test

@swift-ci test

We have hidden this new navigator UX by default for now and have provided a feature flag to enable it and opt-in to the new experience.
This will allow us to merge this PR as-is for now, and we can continue to iterate on the feedback that has been brought up in the forums and the PR.
Thanks everyone!

repo: apple/swift-docc-render


text:
Verify emitted module interfaces by default (Take 2)

Verifying swiftinterface files after they are emitted will detect framework breaking issues much earlier. It can be turned off in offending projects with -no-verify-emitted-module-interface.
Only swiftinterfaces emitted from non-merge-module builds at verified by default. Merge-module builds are more likely to generate broken swiftinterfaces even when a whole-module or emit-module-separately build generates a valid one.
rdar://77534863

@swift-ci Please test

@swift-ci Please test Apple Silicon

@swift-ci test Apple Silicon

@swift-ci test Apple Silicon

Sorry, I misunderstood. This does not work on this repo, it needs to be invoked as a cross-repository test with this PR from the swift repo.

@swift-ci Please test

The broken swiftinterface in the Swift repo has been fixed and the tests are looking good (except maybe for one that I'm testing again). https://github.com/apple/swift/pull/38454
@artemcm Can you give this another review?

Related to the discussion in a Swift-side PR: https://github.com/apple/swift/pull/38465
Can we sanitize -disable-availability-checking when verifying module interfaces?

@nkcsgexi What do you mean by "sanitize"? I don't think -disable-availability-checking is printed in the swiftinterface at this time.

ah, sorry for missing explanation. verifyModuleInterfaceJob calls addCommonFrontendOptions which adds all -Xfronend options. If the framework authors specified -Xfrontend -disable-availability-checking in the build setting, interface verification job will succeed even if there are availability violations in the interface, resulting in the escape of broken interfaces. By sanitizing, I meant after calling addCommonFrontendOptions, we specifically remove -disable-availability-checking to avoid situations like this.

Ah ok, good point. We could use that phase as an early sanity check for all kind of library issues.

I think we can merge this now. The remaining failure on Apple Silicon is unrelated to this change.
We should add extra verifications once this lands properly and we have a reliable verification in place.

authors: artemcm nkcsgexi xymus

repo: apple/swift-driver

license_source: bigquery


text:
[WIP] Protocol oriented integers

This is not the final proposal yet. Still working on some details.

Overall this is looking fantastic, Max.  Please accept my PR into your branch and address the two items above.  Then, as far as I’m concerned, it’s ready to go.

@moiseev Please email me (off list) when you're ready for this to be merged.  I'll take care of kicking off the review from there.

Should this proposal describe how the new floating point system and extant numeric protocols fit in? As far as I can tell, FloatingPoint could inherit from SignedArithmetic. Do SignedNumber and AbsoluteValuable still exist after this has been implemented?

@natecook1000 it was designed with floating point in mind, it's just that floating point landed earlier. There are several places in the current implementation of floating point numbers where the code is commented out because there are no corresponding protocols yet. Answering your questions: yes, the SignedArithmetic should be adopted by floats and SignedNumber should disappear, as well as the AbsoluteValuable and the ~> operator.

authors: dabrahams lattner moiseev natecook1000

repo: apple/swift-evolution


text:
Order package manifest to start with the package declaration

Instead of starting with environment variable parsing, start with the actual package manifest, which is most likely the most interesting to most users.
As suggested in https://github.com/apple/swift-format/pull/680#discussion_r1463458831.

That’s why all the variables are computed instead of stored, to work around the limitations of https://forums.swift.org/t/on-the-behavior-of-variables-in-top-level-code/52230.

repo: apple/swift-format


text:
FoundationEssentials: do not strip non-absolute paths

We would strip the first characters of a path if it were non-absolute. For special files like CON we would end up stripping the name to N.

@swift-ci please test

repo: apple/swift-foundation


text:
Set Swift ABI bit variable when creating a SwiftRuntime

The Swift metadata for classes uses a different bit to identify themselves in the pre-
and post-stable ABI eras. We need to be able to debug both, so the code in the MetadataReader
needs to be configured at runtime.
Companion to https://github.com/apple/swift/pull/23064.
rdar://problem/47935062

https://github.com/apple/swift/pull/23064
@swift-ci please test

apple/swift#23064
@swift-ci please test

repo: apple/swift-lldb


text:
RecordLayout.h: avoid spurious copies of values to be emitted

This was causing significant slowdowns for Swift AST serialization.
Oops.

@swift-ci Please smoke test

Hm. Maybe this?
@swift-ci Please test

@swift-ci Please test macOS

Shouldn't this be committed to LLVM org?

@swift-ci Please test

apple/swift#19167
@swift-ci Please test macOS

apple/swift#19167
@swift-ci Please test macOS

I'm giving up and just merging these.

authors: hyp jrose-apple

repo: apple/swift-llvm


text:
Show in-order processing patterns, equivalent to queue.async {}

And that's not even half the story to be honest... there's even more advanced patterns which_do_ handle structured concurrency better... I'll leave at this example for now.
Future work here:

We could show the the AsyncProcessor that uses a "chain" of withCheckedThrowingContinuation and is more powerful than the async sequence approach but more complicated...
We could point at the upcoming language proposal of Task { [isolated self] in } but only once it's been accepted. https://github.com/sophiapoirier/swift-evolution/blob/closure-isolation/proposals/nnnn-closure-isolation-control.md

Overall I'd definitely like to include this somewhere here because it comes up all the time, but unsure about where exactly to put it. Open to opinions @mattmassicotte @hborla @xedin
resolves https://github.com/apple/swift-migration-guide/issues/22

Huh seems I didn't follow up here, will do :)

Can we resolve conflicts for this branch?

Hi,
Any update on this PR?

authors: ankushkushwaha ktoso

repo: apple/swift-migration-guide


text:
Meaning of pre‐semantic versioning?

I’m curious what is meant by the version numbers of releases. Specifically, what version constraints should clients be specifying in the manifest?
The read‐me recommends from: "0.0.7". Does that mean everything < 1.0.0 is supposed to be source‐compatible with 0.0.7, or is that a typo?
Releases recently switched from 0.0.x to 0.x.x. Does that indicate an intent to have all 0.1.x releases source‐compatible?
Which constraint should clients use? .exact("0.0.7"), .upToNextMinor(from: "0.1.0"), or from: "0.1.0"?

Don't read too much into it. The readme simply hasn't been updated. I'll be using 0.x.0 for normal tags from now on, and 0.x.y for any bug fixes.

(Readme is now updated.)

But is from: "0.1.0" actually advisable? It implies that 0.999.999 will still be source compatible.

That depends strongly on what someone's needs are. If you need a hard source compatibility guarantee, no matter what, you should pin to a version (this is true of almost every project, though, regardless of semver. Semver is a convenient fiction that we allow ourselves to believe.)

This is not about the frequency of changes or the length of the migration window.
from: "0.1.0" instructs SwiftPM to select any (in practice the greatest) version which satisfies 0.1.0 ≤ v < 1.0.0; it is a declaration of simultaneous compatibility with all such versions. A client who does that will break as soon as swift‐numerics releases a version satisfying that constraint but not attempting to be source compatible. (This is not a job for pins either; they are deliberately not inherited.)
from: makes sense when the major version is 1 or greater, because source compatibility is inherent to the semver contract. However, major version 0 is semantically void in the semver standard, and so it can be used in a free‐for‐all fashion. Normally, only .exact() makes any sense when depending on a 0 version.
However, because 0 has no formal meaning, a vendor is free to assign its own meaning and communicate it to clients. Many vendors choose to treat the version components as shifted one slot to the right, guaranteeing that patches are source‐compatible. Part of that communication involves the instructions for declaring the dependency, and Swift packages doing this usually tell clients to declare .upToNextMinor(from: "0.1.0"). In swift‐numerics’ read‐me, the from: "0.1.0" comes across as an indicator that future 0 versions will all be compatible.
But from your description in this thread, it sounds like clients should never use from: "0.1.0", because source compatibility isn’t really being considered in swift‐numerics’ versioning. I strongly recommend changing the read‐me to say .exact("0.1.0") instead, otherwise you are instructing clients to shoot themselves in the foot.

However, major version 0 is semantically void in the semver standard, and so it can be used in a free‐for‐all fashion.

Can be, but is not. The fundamental problem here is that Swift Numerics is still gaining significant API surface area. Individual API are stable within a tag or two of release, but because we keep adding new API (and will continue to be doing so for a long while to come), the project as a whole is not (hence 0.x.y). Semver is too blunt of a hammer to handle this situation well.
We could, I suppose, work around this by introducing new features in a.x.y and bumping to (a+1).0.0 once stabilized, but that's fairly weird (and implies the possibility of breaking changes in stabilized modules, which doesn't actually help anyone).
We could also work around it by splitting SN into lots of little projects, but that has its own complications (that said, this might actually be the best solution long-term--certainly it would align things more with the aspirations of semver).
In the meantime, from: is the most appropriate choice. In practice, no one has yet been shot in the foot, and I don't expect anyone will be.

We’ll have to agree to disagree. I assume the issue can be closed?

authors: SDGGiesbrecht stephentyrone

repo: apple/swift-numerics


text:
[Explicit Module Builds] Skip over binary and systemLirary targets when generating explicit target build jobs

System modules will consist of a .modulemap somewhere in the filesystem, with the path to that module being either manually-specified on the build command or computed based on the system module type (apt, brew).
Similarly, binary targets will bring in an .xcframework, the contents of which will be exposed via search paths.
In both cases, the dependency scanning action in the driver will be automatically be able to detect such targets' modules.

@swift-ci please smoke test

@swift-ci please smoke test

repo: apple/swift-package-manager


text:
Revert "initial implmentation of dependencies coming from registry"

Reverts apple/swift-package-manager#3635

@swift-ci please test

#3646 is preferable to this - better to fix forward


text:
Remove the empty check since it was the only one.

The generated traverse methods should never call on a repeated field
that is empty.
Fixes #988

@tbkka we could add assert(!value.isEmpty) to every visitRepeated*/visitPacked* method as added safety so there is no impact in release builds, but I'm not sure if it is worth it.  Thoughts?

Thanks! Sorry about the repetitive boilerplate there.

No worries, better safe than sorry.
(although I've been wondering about gyb or something lately for some of this code/tests...)

repo: apple/swift-protobuf


text:
Compiler gets Signal 11 when using types as keys in dictionary

Describe the bug
Compiler crashes and informs me to go here and open bug report.
I searched for "useConformancesFromType" among open bugs and found nothing.
To Reproduce
Steps to reproduce the behavior:

Place attached 26 lines of code into file named compilercrash.swift in present working directory.
Run swiftc compilercrash.swift
Signal 11.

Expected behavior
swift creates object file instead.
Screenshots
2022-04-30T09:03:11 ~/Code
‹pliny› 🐵 swiftc compilercrash.swift
error: compile command failed due to signal 11 (use -v to see invocation)
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the project and the crash backtrace.
Stack dump:
0.	Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-frontend -frontend -c -primary-file compilercrash.swift -target x86_64-apple-macosx12.0 -enable-objc-interop -stack-check -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -color-diagnostics -new-driver-path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-driver -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift -module-name compilercrash -target-sdk-version 12.3 -o /var/folders/gv/cjrdp6v5317djql1cf6185dw0000gn/T/TemporaryDirectory.KZfgFE/compilercrash-1.o
1.	Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)
2.	Compiling with the current language version
3.	While evaluating request ASTLoweringRequest(Lowering AST to SIL for file "compilercrash.swift")
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  swift-frontend           0x00000001081e3de7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 39
1  swift-frontend           0x00000001081e2e38 llvm::sys::RunSignalHandlers() + 248
2  swift-frontend           0x00000001081e4440 SignalHandler(int) + 288
3  libsystem_platform.dylib 0x00007ff8093c9dfd _sigtramp + 29
4  libsystem_platform.dylib 0x00007ff7bd082e90 _sigtramp + 18446744072431046832
5  swift-frontend           0x00000001036ce3cc void llvm::function_ref<void (swift::CanType)>::callback_fn<swift::Lowering::SILGenModule::useConformancesFromType(swift::CanType)::$_0>(long, swift::CanType) + 204
6  swift-frontend           0x000000010314814d bool llvm::function_ref<bool (swift::CanType)>::callback_fn<swift::CanType::visit(llvm::function_ref<void (swift::CanType)>) const::'lambda'(swift::Type)>(long, swift::CanType) + 13
7  swift-frontend           0x000000010445ba4e swift::Type::findIf(llvm::function_ref<bool (swift::Type)>) const::Walker::walkToTypePre(swift::Type) + 14
8  swift-frontend           0x00000001036ccde2 swift::Lowering::SILGenModule::useConformancesFromType(swift::CanType) + 274
9  swift-frontend           0x000000010362847b swift::ASTLoweringRequest::evaluate(swift::Evaluator&, swift::ASTLoweringDescriptor) const + 7803
10 swift-frontend           0x0000000103716513 swift::SimpleRequest<swift::ASTLoweringRequest, std::__1::unique_ptr<swift::SILModule, std::__1::default_delete<swift::SILModule> > (swift::ASTLoweringDescriptor), (swift::RequestFlags)9>::evaluateRequest(swift::ASTLoweringRequest const&, swift::Evaluator&) + 195
11 swift-frontend           0x000000010362bdb9 llvm::Expected<swift::ASTLoweringRequest::OutputType> swift::Evaluator::getResultUncached<swift::ASTLoweringRequest>(swift::ASTLoweringRequest const&) + 649
12 swift-frontend           0x0000000102f0c1fb swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 15131
13 swift-frontend           0x0000000102ecb5d4 swift::mainEntry(int, char const**) + 1108
14 dyld                     0x0000000110a4d51e start + 462
2022-04-30T09:05:51 ~/Code
‹pliny› 🐵 swiftc --version                                                                                1 ↵
swift-driver version: 1.45.2 Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)
Target: x86_64-apple-macosx12.0

Environment (please complete the following information):

OS: macOS 12.3.1
Xcode Version/Tag/Branch: Version 13.3.1 (13E500a)

Additional context
Contents of compilercrash.swift:
class Lumber { }
class Fruit { }

enum Size {
    case small
    case medium
    case large
}

let lumberSize = [
    Size.small: "2x4",
    Size.medium: "4x6",
    Size.large: "6x10"
]

let fruitSize = [
    Size.small: "grape",
    Size.medium: "apple",
    Size.large: "watermelon"
]

let size:[AnyObject.Type:Dictionary] = [
    Lumber.self: lumberSize,
    Fruit.self: fruitSize
]
print(size)

Reduced
class Lumber { }

let size:[AnyObject.Type:Dictionary] = [
   Lumber.self: ["":""]
]

We're skipping validating the Hashable conformance - or lack thereof - of AnyObject.Type in key position because of the unbound Dictionary in the type.

authors: CodaFi funcJeff

repo: apple/swift


text:
Add experimental support for tracking the invocations of runtime functions

It allows for collecting the state of runtime function counters, which are used to determine how many times a given runtime function was called.
It is possible to get the global counters, which represent the total number of invocations, or per-object counters, which represent the number of runtime functions calls for a specific object.
The APIs are implemented in the runtime library and are exposed as Swift APIs via the standard library. This way it is possible to write tests and benchmarks which collect very precise data about the amount of runtime functions invocations (e.g. swift_retain/swift_release) for an object or for a given code snippet.

@swift-ci please smoke test

@moiseev Max, could you have a look at the stdlib part?

@aschwaighofer Oh, I see, you are right!

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 824c085a537e30d57a15765a8513ed4b6fcc2280

@swift-ci please test

@gottesmm Michael, do you want to have a look at this attempt to provide runtime function counters?

Build failed
Swift Test OS X Platform
Git Sha - 4b2c6c017e1554deb25ea715873dcebd26a7a3aa

@swift-ci please smoke test OS X

@swift-ci please smoke test OS X

@swift-ci please test OS X

@swift-ci please test OS X

Build failed
Swift Test OS X Platform
Git Sha - a4d5cad3a5da40b4b697e90d2dcd5cc7f14fe42a

@swift-ci please test OS X

Build failed
Swift Test OS X Platform
Git Sha - a4d5cad3a5da40b4b697e90d2dcd5cc7f14fe42a

@swift-ci please test OS X

@swift-ci please test OS X

@swift-ci please smoke test linux

@swift-ci please smoke test

@moiseev Max, thanks a lot for your review! I addressed all of your comments and pushed a new version. Waiting for @gottesmm to review the C++ part of the PR.

@swift-ci please smoke test

I don't see any thread-safety here. Are these counters supposed to be atomic?

@gparker42 I've put into the comments that we may want to make those counters atomic. But in principle, the main motivation for them is to write some tests and perform some performance investigations to track e.g. the number of ARC operations being performed during the execution of a given stdlib call like Array.append,Dictionary.get or something like this. For this kind of use-cases, we don't need to be thread-safe IMHO. WDYT?

@gottesmm Thanks for the review, Michael! I pushed a new version where I addressed most of your comments.

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@gottesmm Michael, is there anything still missing before I merge it?
The atomicity handling can be  added later if we'd really need it (see my comments above).

I am re-reading now.

@swift-ci please smoke test

LGTM

Big thanks to @gottesmm for his thorough review!

@swift-ci please test

@swift-ci please test

authors: gottesmm gparker42 swift-ci swiftix


text:
[5.0] Tweak _SwiftDispatchOverlayShims for use by swift-corelibs-libdispatch

Cherry-pick of #6033 to the 5.0 branch because we don't have a separate 5.0 branch of swift-corelibs-libdispatch at the moment. Should not have any effect on the Apple platform builds.

cc @moiseev
@swift-ci Please smoke test

also cc @xedin, for when he sees the failure


text:
DI: Remove unnecessary assertion [4.2]

It's totally fine to have a conditional destroy of 'self' because
we now uniformly treat assignment to self and self.init delegation,
both of which can appear multiple times in a value type
initializer.
This change removes the assertion and adds some tFileCheck tests to
ensure that DI was already capable of inserting the correct memory
management operations in this scenario.
Fixes rdar://problem/40417944, https://bugs.swift.org/browse/SR-7727.

@swift-ci Please test


text:
test: enable IRGen.generic_casts on all targets

Adjust the test for ELF and COFF targets as well.  This allows us to get
additional test coverage and reduces the number of failing tests on Windows.

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

Resolves SR-NNNN.

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - b607f2d02d973ecd5416751ce0ed336b7642345b

@jrose-apple I don't think that the changes required here are particularly onerous to maintain, and they are easy to verify against what clang does already.

Sure, but there's no point in enabling it either. It's not "additional test coverage" if it's testing an environment that can't happen.

(To me, it's a little different from the other tests you've turned on with -enable-objc-interop. It's good to make it easier for someone on non-macOS to check if they've broken ObjC interop. But that's only worth a certain amount of maintenance effort.)

authors: compnerd jrose-apple swift-ci


text:
[AST] Ill-formed @objc protocols might have associated types.

As an optimization, we don't even look for associated types in @objc
protocols. However, this could lead to broken invariants like "every
associated type has a witness" in ill-formed @objc protocols that do
have associated types.
Implement this optimization by checking whether the protocol has a
Clang node. Fixes rdar://problem/41425828 / SR-8094.

@swift-ci please smoke test and merge

Didn’t we add this to minimize deserialization?

@swift-ci Please test compiler performance

@slavapestov I thought it was to avoid Clang importer work, but... you are right that it would affect deserialization, too. Sounds like I have a predicate to change!
It also fixed a second existing crasher, so that's good.

@swift-ci please smoke test and merge

@swift-ci please smoke test and merge

@swift-ci please smoke test and merge

Build comment file:
Summary for master full
Unexpected test results, excluded stats for RxSwift, Fluent, Wordy, ReactiveSwift
No regressions above thresholds

Debug-batch

debug-batch brief
debug-batch detailed

Release

release brief
release detailed

Debug-batch

debug-batch brief

Regressed (0)

name
old
new
delta
delta_pct

Improved (0)

name
old
new
delta
delta_pct

Unchanged (delta < 1.0% or delta < 100.0ms) (3)

name
old
new
delta
delta_pct

Frontend.NumInstructionsExecuted
14,435,759,514,236
14,450,274,177,283
14,514,663,047
0.1%

LLVM.NumLLVMBytesOutput
669,772,954
669,772,914
-40
-0.0%

time.swift-driver.wall
1665.7s
1672.8s
7.1s
0.43%

debug-batch detailed

Regressed (0)

name
old
new
delta
delta_pct

Improved (2)

name
old
new
delta
delta_pct

Driver.NumDriverPipePolls
206,729
201,811
-4,918
-2.38% :white_check_mark:

Driver.NumDriverPipeReads
227,589
223,954
-3,635
-1.6% :white_check_mark:

Unchanged (delta < 1.0% or delta < 100.0ms) (92)

name
old
new
delta
delta_pct

AST.NumASTBytesAllocated
19,660,291,580
19,660,216,684
-74,896
-0.0%

AST.NumDecls
46,276
46,276
0
0.0%

AST.NumDependencies
132,822
132,828
6
0.0%

AST.NumImportedExternalDefinitions
918,497
918,497
0
0.0%

AST.NumInfixOperators
19,744
19,744
0
0.0%

AST.NumLinkLibraries
0
0
0
0.0%

AST.NumLoadedModules
155,889
155,889
0
0.0%

AST.NumLocalTypeDecls
111
111
0
0.0%

AST.NumObjCMethods
13,059
13,059
0
0.0%

AST.NumPostfixOperators
14
14
0
0.0%

AST.NumPrecedenceGroups
9,238
9,238
0
0.0%

AST.NumPrefixOperators
61
61
0
0.0%

AST.NumReferencedDynamicNames
101
101
0
0.0%

AST.NumReferencedMemberNames
2,546,092
2,546,092
0
0.0%

AST.NumReferencedTopLevelNames
164,914
164,914
0
0.0%

AST.NumSourceBuffers
202,723
202,721
-2
-0.0%

AST.NumSourceLines
1,543,329
1,543,329
0
0.0%

AST.NumSourceLinesPerSecond
908,577
905,554
-3,023
-0.33%

AST.NumTotalClangImportedEntities
3,166,228
3,166,228
0
0.0%

AST.NumUsedConformances
145,082
145,082
0
0.0%

Driver.ChildrenMaxRSS
51,294,433,280
51,377,905,664
83,472,384
0.16%

Driver.DriverDepCascadingDynamic
0
0
0
0.0%

Driver.DriverDepCascadingExternal
0
0
0
0.0%

Driver.DriverDepCascadingMember
0
0
0
0.0%

Driver.DriverDepCascadingNominal
0
0
0
0.0%

Driver.DriverDepCascadingTopLevel
0
0
0
0.0%

Driver.DriverDepDynamic
0
0
0
0.0%

Driver.DriverDepExternal
0
0
0
0.0%

Driver.DriverDepMember
0
0
0
0.0%

Driver.DriverDepNominal
0
0
0
0.0%

Driver.DriverDepTopLevel
0
0
0
0.0%

Driver.NumDriverJobsRun
9,752
9,752
0
0.0%

Driver.NumDriverJobsSkipped
0
0
0
0.0%

Driver.NumProcessFailures
0
0
0
0.0%

Frontend.MaxMallocUsage
247,427,012,336
247,285,499,104
-141,513,232
-0.06%

Frontend.NumInstructionsExecuted
14,435,759,514,236
14,450,274,177,283
14,514,663,047
0.1%

Frontend.NumProcessFailures
0
0
0
0.0%

IRModule.NumIRAliases
74,661
74,661
0
0.0%

IRModule.NumIRBasicBlocks
2,505,654
2,505,654
0
0.0%

IRModule.NumIRComdatSymbols
0
0
0
0.0%

IRModule.NumIRFunctions
1,269,701
1,269,701
0
0.0%

IRModule.NumIRGlobals
1,474,461
1,474,461
0
0.0%

IRModule.NumIRIFuncs
0
0
0
0.0%

IRModule.NumIRInsts
27,134,336
27,134,336
0
0.0%

IRModule.NumIRNamedMetaData
47,563
47,563
0
0.0%

IRModule.NumIRValueSymbols
2,447,116
2,447,116
0
0.0%

LLVM.NumLLVMBytesOutput
669,772,954
669,772,914
-40
-0.0%

Parse.NumFunctionsParsed
1,514,438
1,514,438
0
0.0%

Parse.NumIterableDeclContextParsed
535,490
535,490
0
0.0%

SILModule.NumSILGenDefaultWitnessTables
0
0
0
0.0%

SILModule.NumSILGenFunctions
1,081,697
1,081,697
0
0.0%

SILModule.NumSILGenGlobalVariables
24,671
24,671
0
0.0%

SILModule.NumSILGenVtables
4,636
4,636
0
0.0%

SILModule.NumSILGenWitnessTables
27,520
27,520
0
0.0%

SILModule.NumSILOptDefaultWitnessTables
0
0
0
0.0%

SILModule.NumSILOptFunctions
921,798
921,798
0
0.0%

SILModule.NumSILOptGlobalVariables
25,136
25,136
0
0.0%

SILModule.NumSILOptVtables
8,850
8,850
0
0.0%

SILModule.NumSILOptWitnessTables
55,813
55,813
0
0.0%

Sema.AccessLevelRequest
1,294,909
1,294,909
0
0.0%

Sema.DefaultAndMaxAccessLevelRequest
31,175
31,175
0
0.0%

Sema.EnumRawTypeRequest
10,424
10,424
0
0.0%

Sema.ExtendedNominalRequest
1,943,883
1,943,883
0
0.0%

Sema.InheritedDeclsReferencedRequest
64,388,203
64,388,203
0
0.0%

Sema.InheritedTypeRequest
354,755
354,755
0
0.0%

Sema.IsDynamicRequest
1,192,509
1,192,509
0
0.0%

Sema.IsObjCRequest
997,887
997,887
0
0.0%

Sema.NamedLazyMemberLoadFailureCount
17,527
17,527
0
0.0%

Sema.NamedLazyMemberLoadSuccessCount
14,277,286
14,277,144
-142
-0.0%

Sema.NominalTypeLookupDirectCount
22,708,101
22,708,090
-11
-0.0%

Sema.NumConformancesDeserialized
1,983,977
1,983,977
0
0.0%

Sema.NumConstraintScopes
10,293,642
10,293,642
0
0.0%

Sema.NumConstraintsConsideredForEdgeContraction
19,310,086
19,310,086
0
0.0%

Sema.NumDeclsDeserialized
18,950,884
18,950,886
2
0.0%

Sema.NumDeclsValidated
1,202,422
1,202,422
0
0.0%

Sema.NumFunctionsTypechecked
793,598
793,598
0
0.0%

Sema.NumGenericSignatureBuilders
659,635
659,635
0
0.0%

Sema.NumLazyGenericEnvironments
4,101,780
4,101,781
1
0.0%

Sema.NumLazyGenericEnvironmentsLoaded
94,021
94,021
0
0.0%

Sema.NumLazyIterableDeclContexts
3,907,966
3,907,966
0
0.0%

Sema.NumTypesDeserialized
7,857,342
7,857,342
0
0.0%

Sema.NumTypesValidated
779,440
779,440
0
0.0%

Sema.NumUnloadedLazyIterableDeclContexts
3,151,681
3,151,680
-1
-0.0%

Sema.OverriddenDeclsRequest
1,051,487
1,051,487
0
0.0%

Sema.RequirementRequest
22,731
22,731
0
0.0%

Sema.SelfBoundsFromWhereClauseRequest
63,119
63,119
0
0.0%

Sema.SetterAccessLevelRequest
77,899
77,899
0
0.0%

Sema.SuperclassDeclRequest
53,304,903
53,304,903
0
0.0%

Sema.SuperclassTypeRequest
17,762
17,762
0
0.0%

Sema.TypeDeclsFromWhereClauseRequest
14,456
14,456
0
0.0%

Sema.USRGenerationRequest
234,958
234,958
0
0.0%

Sema.UnderlyingTypeDeclsReferencedRequest
1,791,952
1,791,952
0
0.0%

Release

release brief

Regressed (0)

name
old
new
delta
delta_pct

Improved (0)

name
old
new
delta
delta_pct

Unchanged (delta < 1.0% or delta < 100.0ms) (3)

name
old
new
delta
delta_pct

Frontend.NumInstructionsExecuted
17,878,665,015,968
17,878,148,864,419
-516,151,549
-0.0%

LLVM.NumLLVMBytesOutput
567,739,218
567,740,914
1,696
0.0%

time.swift-driver.wall
3383.5s
3383.8s
319.5ms
0.01%

release detailed

Regressed (0)

name
old
new
delta
delta_pct

Improved (0)

name
old
new
delta
delta_pct

Unchanged (delta < 1.0% or delta < 100.0ms) (23)

name
old
new
delta
delta_pct

AST.NumImportedExternalDefinitions
170,137
170,137
0
0.0%

AST.NumLoadedModules
10,383
10,383
0
0.0%

AST.NumTotalClangImportedEntities
574,968
574,968
0
0.0%

AST.NumUsedConformances
148,202
148,202
0
0.0%

IRModule.NumIRBasicBlocks
2,454,613
2,454,613
0
0.0%

IRModule.NumIRFunctions
1,024,206
1,024,206
0
0.0%

IRModule.NumIRGlobals
1,145,625
1,145,625
0
0.0%

IRModule.NumIRInsts
19,813,748
19,813,748
0
0.0%

IRModule.NumIRValueSymbols
2,003,430
2,003,430
0
0.0%

LLVM.NumLLVMBytesOutput
567,739,218
567,740,914
1,696
0.0%

SILModule.NumSILGenFunctions
440,235
440,235
0
0.0%

SILModule.NumSILOptFunctions
630,729
630,729
0
0.0%

Sema.NumConformancesDeserialized
1,272,623
1,272,623
0
0.0%

Sema.NumConstraintScopes
10,041,431
10,041,431
0
0.0%

Sema.NumDeclsDeserialized
3,849,255
3,849,255
0
0.0%

Sema.NumDeclsValidated
565,369
565,369
0
0.0%

Sema.NumFunctionsTypechecked
341,855
341,855
0
0.0%

Sema.NumGenericSignatureBuilders
119,748
119,748
0
0.0%

Sema.NumLazyGenericEnvironments
811,187
811,187
0
0.0%

Sema.NumLazyGenericEnvironmentsLoaded
15,845
15,845
0
0.0%

Sema.NumLazyIterableDeclContexts
502,530
502,530
0
0.0%

Sema.NumTypesDeserialized
2,170,685
2,170,685
0
0.0%

Sema.NumTypesValidated
249,617
249,617
0
0.0%

authors: DougGregor slavapestov swift-ci


text:
[sil] Add a new CastConsumptionKind called BorrowAlways.

This means that:

SILGenPattern always borrows the object before it emits a case.
Any cast with this cast has a +0 result.

NOTE: That one can not use this with address only types (so we assert if you
pass this to any of the checked cast instructions).
This is an incremental commit towards fixing SILGenPattern for ownership.
rdar://29791263

Just to be clear this doesn't change anything to actually use BorrowAlways.

@swift-ci smoke test

Forgot to mention, I also changed all '==' queries on CastConsumptionKind to instead use covered switches.

The current precondition on using the scalar cast instructions isn't just that the types are address-only; they require the target value to be a directly-stored part of the source value, i.e. a class upcast/downcast or an existential value or something like that.  The general cast functions can do a lot of things that produce owned values that are unrelated, ownership-wise, to the source values; and they can do this even when the types involved are both loadable (e.g. if you're casting an NSArray to an Array).  So I'm concerned about what the semantics of this new CCK are w.r.t. those situations.

@rjmccall sorry I may have spoken too fast about the copy + take_always (I remember a piece of code that did something like that, but I can't seem to find it now).
That being said, I think if we know that we are going to need to go through memory to case then we can copy if we need to before, run it through as +1 and then borrow again. Or if we do not need to copy and the cast machinery will do the copy for us and return a +1 value, then we just borrow afterwards.

So is this not a valid alternative on checked_cast_addr_br?

Yes. I even put in an assert to make that clear.

Look at the constructor of CheckedCastAddrBranch.

Okay.  Well, please at least fix the comments to explain what I said, then.
Also, given that we're moving towards opaque values, is it a good idea to include a feature that can't be reliably lowered to addresses?

I haven't talked to Andy about this, but I imagine that all of the borrow stuff could become copy_on_success. But I haven't thought in depth (trying to finish that proposal to get to you). @atrick your thoughts?

I don't want to hold this PR up. I think that the overall simplest form of the cast is TakeAlways. As John is saying BorrowAlways is not a realizable operation since the new value may not be directly related to the old value. So, if we allow it as a SILGen strategy, then we need some pass to undo it later.

@atrick I am fine with that. I do think that SILGen needs to put in those copies initially. Like you said, I definitely think we are going to want to have an optimization that changes +0 pattern matching into +1 pattern matching if a value is consumed.

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci test linux platform

@swift-ci test linux platform

@rjmccall @atrick I was thinking about this last night and I remembered more. Basically I don't think we need this CastConsumptionKind long term. The reason I am adding this is to enable me to borrow inside SILGenPattern since SILGenPattern uses CastConsumptionKind via ConsumableManagedValue to control the ownership of what it emits.
Once I am finished changing SILGenPattern to emit code at +0 I think that we will be able to change SILGenPattern to just work with ManagedValues instead of ConsumableManagedValue and then get rid of this extra case.

👍

authors: atrick gottesmm rjmccall


text:
[android] Adapt POSIX test to Android

Android differs in subtle ways from Linux. For example sem_open is completely unimplemented, and always returns ENOSYS. None of the test using sem_open were going to work. The test was XFAIL for linux-androideabi, but that target doesn’t match Android AArch64 (aarch64-none-linux-android). Since only the sem_open tests will not work, I disabled those individually for Android, instead of disabling the full file.
Additionally the l_len field of the flock struct is typed as __kernel_off_t, which doesn't have the same size as off_t.
Finally, the current working directory is always /, so creating relative files will fail. We have to find the executable directory and create the file there. For some reason the chdir at the start might work for the parent process, and then doesn't work for the child processes (since CommandLine.arguments[1] is actually --stdlib-unittest-run-child), but doesn’t fail. The implemented solution should write the files side by side with the executable in Android.

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 5afe8b6e38bdd594775e46ed50f7ee8d699ffd22

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 5afe8b6e38bdd594775e46ed50f7ee8d699ffd22

Build failed
Swift Test Linux Platform
Git Sha - 5afe8b6e38bdd594775e46ed50f7ee8d699ffd22

Failure seems unrelated to the changes.

@swift-ci Please smoke test Linux platform

authors: drodriguez moiseev swift-ci


text:
[5.1 04-24-2019] Sema: don't consider opaque types distinct for overloading purposes.

This is necessary because:
func foo() -> some P
func foo() -> some P

theoretically defines two distinct return types, but there'd be no way to disambiguate them. Disallow overloading only by opaque return type.

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 359ea9eaaf274e86649a8b4f7bc8608b01efaca8

Build failed
Swift Test OS X Platform
Git Sha - 359ea9eaaf274e86649a8b4f7bc8608b01efaca8

@swift-ci Please test

I had to pull in @Jumhyn's fix in #23457 since, previously, we apparently didn't correctly handle overload checking on subscripts at all.

Build failed
Swift Test Linux Platform
Git Sha - 359ea9eaaf274e86649a8b4f7bc8608b01efaca8

Build failed
Swift Test OS X Platform
Git Sha - 359ea9eaaf274e86649a8b4f7bc8608b01efaca8

authors: jckarter swift-ci


text:
[TF] Remove all TensorFlow tests.

The TensorFlow module has been moved to tensorflow/swift-apis, and all tests have been copied. Tests here are not updated against library changes, and are currently blocking updating the checkout hash for tensorflow/swift-apis for v0.4 toolchain builds.
Failing Tests (8):
    Swift(macosx-x86_64) :: TensorFlowRuntime/dataset_1.swift
    Swift(macosx-x86_64) :: TensorFlowRuntime/dynamic_attributes.swift
    Swift(macosx-x86_64) :: TensorFlowRuntime/dynamic_compilation_tensor_group.swift
    Swift(macosx-x86_64) :: TensorFlowRuntime/tensor_array_protocol.swift
    Swift(macosx-x86_64) :: TensorFlowRuntime/tensor_autodiff_runtime.swift
    Swift(macosx-x86_64) :: TensorFlowRuntime/tensor_group.swift
    Swift(macosx-x86_64) :: TensorFlowRuntime/tracer.swift
    Swift(macosx-x86_64) :: TensorFlowRuntime/tracer_tffunc.swift

  Expected Passes    : 28
  Expected Failures  : 1
  Unexpected Failures: 8

This PR removes all TensorFlow tests and unblocks things.
Note:

TensorFlow is being well-tested in tensorflow/swift-apis. Removing tests is okay.
The only existing test that's not being removed by this PR is Sema/struct_key_path_iterable.swift. It should not depend on TensorFlow, so we should update it soon.

@swift-ci please test tensorflow

Dataset.map relies on the functionality tested by these tests:
    Swift(macosx-x86_64) :: TensorFlowRuntime/tracer.swift
    Swift(macosx-x86_64) :: TensorFlowRuntime/tracer_tffunc.swift

What are the failures in these tests?

They rely on the old TenosrArrayProtocol definition. I thought these were tested in swift-apis. If not, could you move them to swift-apis?
********************
Command Output (stderr):
--
/Users/rxwei/Development/Swift/swift-tf-source/swift/test/TensorFlowRuntime/tracer_tffunc.swift:20:8: error: type 'State' does not conform to protocol 'TensorArrayProtocol'
struct State : TensorGroup {
       ^
TensorFlow.TensorArrayProtocol:5:9: note: protocol requires property '_tensorHandles' with type '[_AnyTensorHandle]'; do you want to add a stub?
    var _tensorHandles: [_AnyTensorHandle] { get }
        ^

Command Output (stderr):
--
/Users/rxwei/Development/Swift/swift-tf-source/swift/test/TensorFlowRuntime/tracer.swift:162:10: error: type 'State' does not conform to protocol 'TensorArrayProtocol'
  struct State : _TensorArrayProtocolEnhanced {
         ^
TensorFlow.TensorArrayProtocol:7:5: note: protocol requires initializer 'init(_handles:)' with type '(_handles: C)'; do you want to add a stub?
    init<C>(_handles: C) where C : RandomAccessCollection, C.Element : _AnyTensorHandle
    ^

@bgogul Since this is blocking v0.4 release, I'm going to merge it now to make progress. I filed TF-548 for migrating tests to swift-apis.

@bgogul Since this is blocking v0.4 release, I'm going to merge it now to make progress. I filed TF-548 for migrating tests to swift-apis.

Sounds good.  I closed the new one as it duplicates https://bugs.swift.org/browse/TF-541, which already tracks migration of tests.

authors: bgogul rxwei


text:
[5.1] Sema: Protocol requirements cannot use opaque return types.

We could invent a meaning for this in the future (such as having it be sugar for an unnamed
associated type), but for now raise an error with a fixit. rdar://problem/50678247

@swift-ci Please test


text:
Platform: extend WinSDK further

This extends the WinSDK module definition further to better modularise
the headers.  This should improve the header organisation as well as
setup additional autolink rules.

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

Resolves SR-NNNN.

@swift-ci please test Windows platform

@swift-ci please smoke test


text:
[5.1] Replace all 9999 availability in non-stdlib tests. (#26109)

Replace all 9999 availability in non-stdlib tests with the appropriate platform availability.
https://github.com/apple/swift/pull/26109 cherry-picked for 5.1 branch.

@swift-ci please test

(Paradoxically, it's less important to get this on 5.1 than it is on master, since nothing with availability > 5.1-aligned SDK versions should ever land on this branch, so there's no need to disambiguate. Still, good to do this.)

@swift-ci nominate

@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - 9da27c2f805edc3ba599739a29cc2a86fc35ed23

Build failed
Swift Test OS X Platform
Git Sha - 9da27c2f805edc3ba599739a29cc2a86fc35ed23

"Unresolved" lang/swift/address_of/TestSwiftAddressOf.py test on linux. Re-running to see if it persists.

@swift-ci please test linux.

authors: stephentyrone swift-ci


text:
[CodeSynth] NFC: Simplify diagnostic output

This helps var->dump() not crash.

@swift-ci please smoke test

Thanks!

authors: davezarzycki jckarter


text:
Revert #26937, #27190, and #27132

Changes in the libSyntax parser seem to have caused parsing the standard library to break in Debug(Asserts) builds.  Revert this patchset.
Sorry y'all.
@rintaro @compnerd

@swift-ci please test

@rintaro I think the moveonly-fication here caused a dangling pointer dereference.  The stack is smashed pretty hard here.  It would definitely be worth spinning up an ASAN+UBSan build to investigate.

Build failed
Swift Test Linux Platform
Git Sha - d8aaf29617b474fe47bd55a3c3145af2566c044f

Build failed
Swift Test OS X Platform
Git Sha - d8aaf29617b474fe47bd55a3c3145af2566c044f

authors: CodaFi swift-ci


text:
TBDGen: don't emit $ld$previous$ symbols for added members to a moved decl

When a top-level decl is marked with @_originallyDefinedIn, some of its members
may also be newly added after the top-level decl has been moved to the current module.
For these members, we don't need emit $ld$previous$ symbols for them.
rdar://60478650

@swift-ci please smoke test

@swift-ci Please smoke test Linux platform


text:
[sil] add instruction copy_to_ref

Storing class properties as a tuple or struct can be beneficial because most optimization passes only work on non-class datatypes (struct, tuple, and enum). To get the best performance it's ideal to memcpy the entire object to the first element of the class reference (rather than emit a dozen ref_element_addr, tuple_extract, and store instructions). That's where this instruction comes into play (from SIL.rst):
copy_to_ref %0 to %1 : $C
  // %0 must be a pointer.
  // %1 must be class type.

Given an instance of a tuple or struct, copy_to_ref bitcasts the "from" value to a byte
pointer and emits a memcpy to the "to" operand which is a reference. The "from" value must have all stored properties of the "to" operand. Here's an example use:
   class Foo {
    var x: Int
    var y: Int
    var z: Int
    var cond: Bool
  }

   %f = alloc_ref $Foo
  %sa = alloc_stack $(Int, Int, Int, Bool)
  %t = tuple (%0 : $Int, %1 : Int, %2 : Int, %3 : Bool)
  store %t to %sa : $*(Int, Int, Int, Bool)

  copy_to_ref %sa to %f : $Foo

See #30736 for previous discussion/rational.

Some discussion points:
We need to think about ownership. This doesn't matter for trivial types, like Int, but it's important for all non-trivial types. It would make sense that copy_to_ref consumes the source operands, rather than to copy it. Because then the source would just be "moved" to the destination, which is much cheaper than copying. It can be done with memcpy (at least for most types).
In this case "copy_to_ref" is the wrong name - it should be "store_to_ref".
A "store_to_ref" is a shortcut for a series of
  %e = ref_element_addr %dest, field<n>
  %v = tuple_extract %src, <n>
  store %v to [init] %e

The question we have to answer is: what benefit would such a new instruction give us compared to using this series of instructions?
There are some optimizations, like LetPropertiesOpt, which rely on ref_element_addr to be there to check all possible accesses to a specific class property. Those optimizations would need to take "store_to_ref" into account.
I'd like to bring up two alternatives. I'm not sure by myself if they are better - just for brainstorming:

Split a "store_to_ref" into two instructions: a new ref_payload_addr and a regular store

  %a = ref_payload_addr %dest // projects the whole content of the class object (the implementation is equivalent to ref_element_addr of the first field)
  store %src to [init] %a

I assume an alloc_ref and a store_to_ref always come as a pair. We could add the source value as an additional operand to alloc_ref

  %ref = alloc_ref $Foo (%src)

@eeckstein thanks for those suggestions. I like that neither of your alternatives use addresses. This will make it easier to optimize all the allocations away.
The only downside is that in order to replace all ref_element_addrs with tuple_element_addrs we would have to have to create a load. It's rare that a class will have no uses other than initialization but, it's fairly common that a class's only use after initialization will be ref_element_addr instructions. If we can replace all those, we can remove the class and there's a good chance that mem2reg can get rid of the tuple alloc_stack. Anyway, I don't think that should be an issue at all, just a thing to keep in mind.
I tested some various implementations and found that both using the ref_element_addr/tuple_extract/store and copy_to_ref (or whatever equivilat instruction we come up with) genereate the **exact** same llvm-ir.

class XYZClass {
  var x : Int
  var y : Int
  var z : Int
}

sil @using_copy : $@convention(thin) () -> XYZClass {
bb0:
  %0 = integer_literal $Builtin.Int64, 1
  %1 = struct $Int (%0 : $Builtin.Int64)
  %2 = integer_literal $Builtin.Int64, 2
  %3 = struct $Int (%2 : $Builtin.Int64)
  %4 = tuple (%1 : $Int, %3 : $Int, %3 : $Int)

  %tsa = alloc_stack $(Int, Int, Int)
  %f = alloc_ref $XYZClass

  store %4 to %tsa : $*(Int, Int, Int)

  copy_to_ref %tsa : $*(Int, Int, Int) to %f : $XYZClass

  dealloc_stack %tsa : $*(Int, Int, Int)

  return %f : $XYZClass
}

sil @using_store : $@convention(thin) () -> XYZClass {
bb0:
  %0 = integer_literal $Builtin.Int64, 1
  %1 = struct $Int (%0 : $Builtin.Int64)
  %2 = integer_literal $Builtin.Int64, 2
  %3 = struct $Int (%2 : $Builtin.Int64)
  %4 = tuple (%1 : $Int, %3 : $Int, %3 : $Int)

  %f = alloc_ref $XYZClass

  %ex = ref_element_addr %f: $XYZClass, #XYZClass.x
  %x = tuple_extract %4 : $(Int, Int, Int), 0
  store %x to %ex : $*Int

  %ey = ref_element_addr %f: $XYZClass, #XYZClass.y
  %y = tuple_extract %4 : $(Int, Int, Int), 1
  store %y to %ey : $*Int

  %ez = ref_element_addr %f: $XYZClass, #XYZClass.z
  %z = tuple_extract %4 : $(Int, Int, Int), 2
  store %z to %ez : $*Int

  return %f : $XYZClass
}

sil_vtable XYZClass { }

Given that, it seems like the best course of action may be not to add any instructions. What do you think? Is it worth the sil code size/clarity improvements?

Given that, it seems like the best course of action may be not to add any instructions. What do you think?

I agree

Is it worth the sil code size/clarity improvements?

IMO, no

@eeckstein great, glad we're in agreement. See #30810.

authors: eeckstein zoecarver


text:
[CMake] Allow devs to disable implicit incremental testing

Lit's incremental mode is incompatible with read-only source filesystems which some CI setups use and there is no way to disable incremental mode in Swift without enabling --shuffle via LLVM_LIT_ARGS.

@swift-ci please smoke test

What do you think of changing this to something like:
set(SWIFT_LIT_ARGS "--incremental" CACHE STRING
  "arguments to pass to lit")
``

This will allow you to override the parameter without an option while allowing greater control over the arguments.

If you think that this is too much freedom, the option makes sense.

That seems better than what I proposed.
@swift-ci please smoke test

authors: compnerd davezarzycki


text:
[Typechecker] Emit a specialised diagnostic for redeclaration errors when the declaration is synthesised

At the moment, some redeclaration errors involving synthesised declarations can cause compiler crashes. For example:
@propertyWrapper
struct Wrapper {
  var wrappedValue: Int
}

struct S {
  @Wrapper var foo1 = 123
  var _foo1 = 123
}

This currently crashes in the AST verifier on master and in SILGen on 5.3. Upon investigation, this seems to be a regression caused by #31037.
To fix the problem, I have added a specialised diagnostic for situations where the current declaration is synthesised. This also fixes a problem where the redeclaration diagnostics did not have a valid source location.
Resolves SR-12839

@swift-ci please smoke test

@swift-ci please smoke test

@hborla Do you know if this can be cherry-picked to 5.3? I'd like to do that so we can fix the crash, alternatively we can revert #31037 on the 5.3 branch only (but that means we don't get the improved diagnostics).

@theblixguy yes, please prepare a PR for the 5.3 branch. Thank you!

authors: hborla theblixguy


text:
Add more file-level comments to MemAccessUtils.

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

Resolves SR-NNNN.

@swift-ci smoke test and merge


text:
[5.3] [Build System] Remove tvOS i386 slice from compiler-rt lib

rdar://problem/70754005

@swift-ci build toolchain macOS

@swift-ci test

macOS Toolchain
Download Toolchain
Git Sha - 611e59e527d2f02d9f397bf6b91e7d3fb8fe2348
Install command
tar -zxf  swift-PR-34474-739-osx.tar.gz --directory ~/

authors: shahmishal swift-ci


text:
Allow cross host compilation without stdlib build

This is to support certain build configuration which will provide the
stdlib/runtime for the cross target by a different mean.
Addresses rdar://74154062

@swift-ci please python lint

@swift-ci please smoke test

@swift-ci please test macOS

@swift-ci Please Build Toolchain

Linux Toolchain (Ubuntu 16.04)
Download Toolchain
Git Sha - 6c169e4e09da4065738c5d41321de9a51b70b53b
Install command
tar zxf  swift-PR-35858-550-ubuntu16.04.tar.gz
More info

macOS Toolchain
Download Toolchain
Git Sha - 6c169e4e09da4065738c5d41321de9a51b70b53b
Install command
tar -zxf  swift-PR-35858-871-osx.tar.gz --directory ~/

authors: edymtt swift-ci


text:
Spawn let

Introduce spawn let syntax as the preferred alias for async let, to track the proposal. While here, fix a bug with spawn let where we would reject string interpolations within a spawn let.
Fixes rdar://76020473

@swift-ci please smoke test and merge


text:
Documentation: Correct placement of doc comments in AsyncSequence

Correct placement of documentation comments for:

AsyncSequence.AsyncIterator
AsyncSequence.Element
AsyncSequence.makeAsyncIterator()

Also remove stray "\c" sequence in doc comments for Actor and MainActor.
This PR only affects documentation comments.

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test and merge

@swift-ci please smoke test and merge


text:
C++ Interop: add a test for std module interface

The test checks that the Swift module interface for std & its submodules can be generated & that it contains a couple of known declarations.
This is a follow-up after https://github.com/apple/swift/pull/37806.

@swift-ci please smoke test

Swift Test Linux Platform (smoke test)

Probably best to just disable this test on Linux until we support libstdc++ (very soon). But I don't feel strongly.

Probably best to just disable this test on Linux until we support libstdc++

Agreed, I disabled it on Linux for now.

@swift-ci please smoke test

@swift-ci please test Windows

@swift-ci please smoke test Linux

authors: egorzhdan zoecarver


text:
[Swift 3] ClangImporter: enable -fblocks on non-Darwin platforms

What's in this pull request?

This pull request is to nominate #3835 for inclusion in the Swift 3.0 branch.   Needed on Linux to allow Dispatch and Foundation to be imported without requiring the user to explicitly give -Xcc -fblocks to swiftc.
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.

We need to enable blocks support in the ClangImporter on
non-Darwin platforms for libdispatch (and transitively foundation).
The simplest way to do this is to just enable blocks unconditionally.
Also enable two Linux tests that are no longer XFAILS

@swift-ci Please test

authors: dgrove-oss jrose-apple


text:
Make the error for missing existential erasure coercions configurable.

Provides a cleaner fix for rdar://94177266

@swift-ci please smoke test

@swift-ci please smoke test macOS

@swift-ci please smoke test macOS


text:
[Parse] Do not parse generic arguments of a cast destination if the token is more than a "<"

Resolves #43053.

@swift-ci please smoke test macOS

@swift-ci please smoke test Linux

@swift-ci please smoke test macOS

@swift-ci please smoke test

Note
Reminder to squash

@swift-ci please test

As discussed in https://github.com/apple/swift/issues/43053, I don't mind if we use unbounded lookahead to diagnose this case, but to accept this production as a result of a lookahead is a much bigger change than I think you intend to make here.

to accept this production as a result of a lookahead is a much bigger change than I think you intend to make here.

I don't think a lookahead changes the behavior for currently accepted cases. Currently at this position, all < after a type identifier is unconditionally parsed as a generic parameter clause, and that won't change even if we lookahead and decide how to parse it as a result of a lookahead as long as it was successfully parsed as a generic argument clause.
I agree this might be strictly a change to the language, but I don't think this would break any existing code.

@CodaFi I agree with you in some sense, I was also afraid that that might be a bigger change than just a small bug fix. As we can see, this fix had already caused concern with <. But ultimately i was only trying to fix a bug. I was also thinking maybe we could rethink this and emit some helpful diagnostics like Rust does instead of the current approach.

I tend to agree with Robert we should be more principled and farsighted in approaching disambiguation problems that require unbounded lookahead in the general case. The ambiguity can easily be worked around, and I would not want this to ever hinder a hypothetical proposal on dependent types. For now though, we can learn from Rust and improve the diagnostic.
@simanerush WDYT?

@AnthonyLatsis I agree with you. Should I close this PR then and open an issue proposing new diagnostics rather that silencing the current diagnostics?

Sounds good.

authors: AnthonyLatsis CodaFi rintaro simanerush xedin


text:
[5.10] Optimizer: fix compiler crashes caused by certain types of statically initialized global variables

Explanation: This fixes three problems which can cause compiler crashes for certain rare cases of statically initialized global variables.

DeadFunctionElimination doesn't keep global variables alive which are referenced from another global, for example:

private var g1 = 27
let g2 = UnsafePointer(&g1)

When InitializeStaticGlobals merges stores in a global initializer, it's possible that the resulting store is inserted at the wrong location which causes a SIL verifier error. The resulting store must be inserted after all other stores. Instead it's inserted after the store of the last property. Now, if properties are not initialized in the order they are declared, this problem can show up.

IRGen has a wrong assert for global variable initialization: in case a global variable reference another global variable, it can be the case that the other variable is first generated as declaration and then "converted" to a definition by adding the constant initializer.

Issue: rdar://117189962

Risk: Low. The fixes are pretty trivial and only affect certain rare types of statically initialized global variables.

Testing: With regression tests

Reviewer: @atrick (to-do)

Main branch PR: https://github.com/apple/swift/pull/69271

@swift-ci test


text:
Deprecate the CommandLine.arguments setter

Accessing CommandLine.arguments is a sendability violation, since it's global mutable state. This marks the setter as deprecated, so that we can potentially make it unavailable in Swift 6 mode.
(I also wrote some docs for CommandLine.arguments.)

@swift-ci Please test

This starts to address #66213, which will take multiple steps due to ABI/source compatibility concerns.

@swift-ci Please test

@swift-ci please test macOS

@swift-ci please test

@swift-ci please test

authors: Azoy grynspan natecook1000


text:
[GenericSig] Properly drop all type parameters with concrete bindings.

When enumerating "paired" requirements, we were failing to drop some
generic type parameters that have concrete bindings. Drop all of them
consistently

@swift-ci please smoke test and merge


text:
Set widget width

Hi,
Thanks for select2 integration in django, It's great !
I'ld like to set the widget width (to use it in formset). For now, the width of the widget is based on the longest word in it, and forced by an element style:
<select ...>
    <option value="0">Foo</option>
    <option value="1">Bar/option>
    ...
</select>
<span class="select2 select2-container select2-container--default select2-container--focus" dir="ltr" style="width: 554px">
... [select2 machinery]
</span>

I've tryed to use the widget attrs parameter, but the width is set to the select (I can see it briefly), not the s2 widget.
How can I set this width ?
Thanks for your help !

Hi @frague59 I would recommend using a custom select2 theme. Anyhow this is something that is not specific to this implementation. I suggest you check out the select2 documeantion.
https://select2.org/getting-started/basic-usage
Enjoy!
-Joe

Hi,
My question is more about sending attrs to select2, because it's not about 1 field in a formset, but many fields in many formsets... and other forms.
Thanks !

All the more reason to go for a template if its about the style of the input. If it's about the form in general, sure you can pass attrs as you can with any widget in Django.


text:
mongoose issues

os - ubuntu 14.04
node version - 6.9.4
stack trace from error -
appoptics:warn ao.bind - no context Error: CLS NOT ACTIVE
at Object.exports.bind (//node_modules/appoptics-apm/lib/index.js:638:17)
at Query._wrapCallback (//node_modules/appoptics-apm/lib/probes/mongoose.js:91:37)
at Query.findOne (//node_modules/mquery/lib/mquery.js:1811:19)
at Query._findOne (//node_modules/mongoose/lib/query.js:1522:22)
at //node_modules/kareem/index.js:250:8
at //node_modules/kareem/index.js:23:7
at _combinedTickCallback (internal/process/next_tick.js:67:7)
at process._tickDomainCallback (internal/process/next_tick.js:122:9)

every mongoose call
we use mongodb 3.4 with following npm packages:
"mongodb": "2.2.34",
"mongodb-migrate": "2.0.2",
"mongoose": "4.13.14",
"mongoose-deep-populate": "2.0.3",
"mongoose-field-encryption": "0.0.5"
"appoptics-apm": "5.9.0"

thank you. i appreciate your help.
are you using mongoose with promises as opposed to callbacks?

thanks, I"ll try this version next week

still same issue :
2018-12-27T12:30:37.043Z appoptics:warn ao.bind() - no context Error: CLS NOT ACTIVE
at Object.exports.bind (/var/www/techsee-api/node_modules/appoptics-apm/lib/index.js:638:17)
at model.Query._wrapCallback (/var/www/techsee-api/node_modules/appoptics-apm/lib/probes/mongoose.js:112:37)
at model.Query.Query.findOne (/var/www/techsee-api/node_modules/mquery/lib/mquery.js:1811:19)
at model.Query.Query._findOne (/var/www/techsee-api/node_modules/mongoose/lib/query.js:1522:22)
at /var/www/techsee-api/node_modules/kareem/index.js:250:8
at /var/www/techsee-api/node_modules/kareem/index.js:23:7
at _combinedTickCallback (internal/process/next_tick.js:132:7)
at process._tickDomainCallback (internal/process/next_tick.js:219:9)
same error also on node v8.12 ...

I see warnings also on 'mongoose-deep-populate' related queries :
2018-12-27T12:45:10.468Z appoptics:warn ao.bind(anonymous) - no context Error: CLS NOT ACTIVE
at Object.exports.bind (/var/www/techsee-api/node_modules/appoptics-apm/lib/index.js:638:17)
at model.Query. (/var/www/techsee-api/node_modules/appoptics-apm/lib/probes/mongoose.js:102:42)
at model.Query.Query.exec (/var/www/techsee-api/node_modules/mongoose-deep-populate/lib/plugin.js:49:20)
at model.Query.Query.then (/var/www/techsee-api/node_modules/mongoose/lib/query.js:3147:15)
at Object.getById (/var/www/techsee-api/server/models/room.js:581:14)

@Igor-Techsee - thanks for checking this out and I'm sorry it didn't fix the issue for you. I have a couple questions:

/var/www/techsee-api/node_modules/kareem/index.js:250:8
could you expand a bit on how you're using kareem? we test findOne specifically and, at least in our tests, we manage to maintain context. So, based on the stack trace, it seems that context has been lost before Query.Query._findOne() is being called.

also, are you seeing these only on findOne() calls or are you seeing them on add() calls as well?

I see warnings also on 'mongoose-deep-populate' related queries
thanks for this. we currently don't test any plug-ins for mongoose. I'll add a test and see if I can find a problem. If you have any details on how you use it I'll try to test for that specific case.

it happens on every call

I just want to confirm that this is running in an http/https server context.

It happens on every findOne, in dashboard I can see find/update queries

authors: Igor-Techsee bmacnaughton

repo: appoptics/appoptics-apm-node


text:
MRPHS-3528: Provide support to create and delete images in GCP

JIRA Id
MRPHS-3528
Problem
Libretto currently does not provide functions to create and delete images in GCP.
Solution
One of the ways to create a custom image in Google Compute Engine is to upload a compressed (tar.gz format) raw disk image file (with name disk.raw) to Google Cloud Storage and create a Google Compute Engine compatible image from that raw disk. Please refer to the complete process at: https://cloud.google.com/compute/docs/images/import-existing-image
Through this PR, Libretto is going to provide a function with which a compressed raw disk available on Google Cloud Storage can be used to create a custom image in Google Compute Engine. This custom image can then be used to launch instances in Google Compute Engine. The input required is the path of the raw disk on Google Cloud Storage, the name you want to give to the image and your project ID.
A function is also being provided to delete a custom image from Google Compute Engine. The input required is your project ID and the image name.
Unit Testing
Unit testing has been done to create and delete an image. The output of a dummy client is given below:
Create Image:
time="2017-10-25T16:26:21+05:30" level=debug msg="[actions.go:29::github.com/jayant-izel/halo.glob..func1] Providing a gcp cloud-object instance"
time="2017-10-25T16:26:21+05:30" level=debug msg="[gcp.go:995::github.com/jayant-izel/halo/cloud/gcp.(*Cloud).CreateImage] Creating a new GCP image, input: {
  "AccountFile": "/root/gcp-libretto.json",
  "Project": "useful-song-179609",
  "SourceImage": "ubuntu-1604",
  "Description": "Ubuntu 16.04 image",
  "RawDiskSource": "https://storage.googleapis.com/aobucket/ubuntu1604-gce.tar.gz",
  "Scopes": [
    "https://www.googleapis.com/auth/compute",
    "https://www.googleapis.com/auth/devstorage.full_control"
  ]
}"
time="2017-10-25T16:26:21+05:30" level=debug msg="[gcp.go:1009::github.com/jayant-izel/halo/cloud/gcp.(*Cloud).CreateImage] Calling Libretto->vm.CreateImage()"
time="2017-10-25T16:28:48+05:30" level=debug msg="[gcp.go:1015::github.com/jayant-izel/halo/cloud/gcp.(*Cloud).CreateImage] Image ubuntu-1604 created successfully"

Delete Image:
time="2017-10-25T16:29:38+05:30" level=debug msg="[actions.go:29::github.com/jayant-izel/halo.glob..func1] Providing a gcp cloud-object instance"
time="2017-10-25T16:29:38+05:30" level=debug msg="[gcp.go:1022::github.com/jayant-izel/halo/cloud/gcp.(*Cloud).DeleteImage] Deleting GCP image, input: {
  "AccountFile": "/root/gcp-libretto.json",
  "Project": "useful-song-179609",
  "SourceImage": "ubuntu-1604",
  "Scopes": [
    "https://www.googleapis.com/auth/compute"
  ]
}"
time="2017-10-25T16:29:38+05:30" level=debug msg="[gcp.go:1036::github.com/jayant-izel/halo/cloud/gcp.(*Cloud).DeleteImage] Calling Libretto->vm.DeleteImage()"
time="2017-10-25T16:30:51+05:30" level=debug msg="[gcp.go:1042::github.com/jayant-izel/halo/cloud/gcp.(*Cloud).DeleteImage] Image ubuntu-1604 deleted successfully"

Addition Notes:
NA

Thanks @pankajtandon12.
The minor comment for typo has been addressed. Merging the PR.

repo: apporbit/libretto


text:
[Bug]: Unable to Install Appsmith When Kubernetes Namespace Is Not Default

Is there an existing issue for this?

[X] I have searched the existing issues

Description
When trying to install Appsmith using the K8s installation guide, it does not work if using a different namespace than default:  helm install appsmith appsmith/appsmith -n appsmith.
The error returned is MongoDB replica set is not enabled.
Front thread
Steps To Reproduce
Install Appsmith on Kubernetes, using a namespace that is not default: helm install appsmith appsmith/appsmith -n appsmith
Public Sample App
No response
Environment
Production
Issue video log
No response
Version
Self Hosted
 Front conversations

You probably have this information but I'll include the discord thread just in case.

So I have found a workaround but it includes deleting the local mongo PVC ...

k get pvc -n appsmith
k delete pvc -n appsmith datadir-appsmith-mongodb-x (for all instances)
Install as normal

Got same issue.
Error is service
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
{
  "success": true
100   193  100    21  100   172     62    513 --:--:-- --:--:-- --:--:--   577
}Initialize .env file
Load environment configuration
Checking environment configuration
Checking APPSMITH_MONGODB_URI
Checking initialized database
Checking Replica Set of external MongoDB
Error even from changeStream MongoServerError: The $changeStream stage is only supported on replica sets
    at Connection.onMessage (/opt/appsmith/utils/node_modules/mongodb/lib/cmap/connection.js:227:30)
    at MessageStream.<anonymous> (/opt/appsmith/utils/node_modules/mongodb/lib/cmap/connection.js:60:60)
    at MessageStream.emit (node:events:513:28)
    at processIncomingData (/opt/appsmith/utils/node_modules/mongodb/lib/cmap/message_stream.js:125:16)
    at MessageStream._write (/opt/appsmith/utils/node_modules/mongodb/lib/cmap/message_stream.js:33:9)
    at writeOrBuffer (node:internal/streams/writable:391:12)
    at _write (node:internal/streams/writable:332:10)
    at MessageStream.Writable.write (node:internal/streams/writable:336:10)
    at Socket.ondata (node:internal/streams/readable:754:22)
    at Socket.emit (node:events:513:28) {
  ok: 0,
  code: 40573,
  codeName: 'Location40573',
  [Symbol(errorLabels)]: Set(0) {}
}
***************************************************************************************
*      MongoDB Replica Set is not enabled                                             *
*      Please ensure the credentials provided for MongoDB, has 'readWrite' role.      *
***************************************************************************************

Helm command
helm install -f values.yaml -n appsmith appsmith stable-appsmith/appsmith

Values.yaml
## Redis parameters
redis:
  enabled: true
  auth:
    enabled: false
  master:
    nodeSelector:
      usage: appsmith
    tolerations:
      - effect: NoSchedule
        key: usage
        operator: Equal
        value: appsmith
  replica:
    replicaCount: 1
    nodeSelector:
      usage: appsmith
    tolerations:
      - effect: NoSchedule
        key: usage
        operator: Equal
        value: appsmith

mongodb:
  enabled: false

global:
  storageClass: "managed-csi-premium"

nodeSelector:
  usage: appsmith

tolerations:
  - effect: NoSchedule
    key: usage
    operator: Equal
    value: appsmith

ingress:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "8m"
    nginx.ingress.kubernetes.io/whitelist-source-range: 1.2.3.4/32
  hosts:
    - host: a.b.com
  secrets:
    - hosts:
      - "*.b.com"
  className: "nginx"

applicationConfig:
  APPSMITH_CLIENT_LOG_LEVEL: "debug"
  APPSMITH_MAIL_ENABLED: "true"
  APPSMITH_MAIL_HOST: "a.b.c"
  APPSMITH_MAIL_PORT: "587"
  APPSMITH_MAIL_USERNAME: "abcd"
  APPSMITH_MAIL_PASSWORD: "xyz"
  APPSMITH_MAIL_FROM: "x@a.com"
  APPSMITH_REPLY_TO: "x@a.com"
  APPSMITH_MAIL_SMTP_AUTH: "true"
  APPSMITH_MAIL_SMTP_TLS_ENABLED: "true"
  APPSMITH_MONGODB_URI: "mongodb://abcd:xyz@mongodb.mongodb.svc.cluster.local:27017/appsmith?retryWrites=true&authSource=admin"
  APPSMITH_ENCRYPTION_PASSWORD: "1234"
  APPSMITH_ENCRYPTION_SALT: "1234 "
  APPSMITH_DISABLE_IFRAME_WIDGET_SANDBOX: "false"
  APPSMITH_ENABLE_EMBEDDED_DB: 0

Hey @darkmatter18, sorry for the delay in getting back to this. It looks like you're using an externally managed MongoDB, running in your cluster. The error reports that you don't have replica set enabled on your MongoDB. Can you confirm if replicaSet is enabled please? You can confirm by running rs.status() on your MongoDB. Having replicaSet enabled is required for Appsmith to run.
If you do have replicaSet enabled, and yes see the above error, please open a separate issue mentioning this above comment and we'll take it up. Thank you.
Closing this as the title issue seems to be not reproducible anymore with current Helm charts. if that's not the case, happy to reopen.

Happened again now.
helm upgrade appsmith appsmith/appsmith --version 2.0.7 -f values.yaml -i -n appsmith --set mongodb.auth.rootPassword=xxx
Appsmith pod gives MongoDB replica set is not enabled

same problem here

hey @ErlendFax @melquisedequecosta98  can you please share us the values.yaml used to deploy appsmith.
we did the following and get appsmith up and running
✗ helm upgrade appsmith appsmith/appsmith --version 2.0.7 -f values.yaml -i -n goutham --create-namespace --set mongodb.auth.rootPassword=password
Release "appsmith" does not exist. Installing it now.
coalesce.go:223: warning: destination for appsmith.persistence.localCluster is a table. Ignoring non-table value ([minikube])
coalesce.go:223: warning: destination for mongodb.persistence.existingClaim is a table. Ignoring non-table value ()
coalesce.go:223: warning: destination for appsmith.persistence.localCluster is a table. Ignoring non-table value ([minikube])
NAME: appsmith
LAST DEPLOYED: Thu Dec 14 00:21:31 2023
NAMESPACE: goutham
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace goutham -l "app.kubernetes.io/name=appsmith,app.kubernetes.io/instance=appsmith" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace goutham $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace goutham port-forward $POD_NAME 8080:$CONTAINER_PORT

To expose your Appsmith service to be accessible from the Internet, please refer to our docs here https://docs.appsmith.com/getting-started/setup/installation-guides/kubernetes/publish-appsmith-online.

and i see the following outputs
kubectl get pods -n goutham
NAME                         READY   STATUS    RESTARTS   AGE
appsmith-0                   1/1     Running   0          4m46s
appsmith-mongodb-0           1/1     Running   0          4m46s
appsmith-mongodb-1           1/1     Running   0          4m26s
appsmith-mongodb-arbiter-0   1/1     Running   0          4m46s
appsmith-redis-master-0      1/1     Running   0          4m46s
appsmith-redis-replicas-0    1/1     Running   0          4m46s

I have encountered the same problems.
I set up an ephemeral container on appsmith-mongodb-0 and checked its status with rs.status(), and found that mongodb-arbiter-0 was in an unhelthy state and mongodb-1 was not even a member of the replica set.
After further investigation, it turned out that the communication between the pods did not seem to be working, so I drained the pods from the worker node where mongodb-arbiter-0 and mongodb-1 were running, and started them on another node, which restored them.
This is just a hypothesis, but it seems that AWS security group tracking has a limit, and it may have been caught by it; MongoDB Heartbeat communicates frequently, so it may be caught by this limit. (I use AWS EKS)

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html

Hope this helps you guys.

repo: appsmithorg/appsmith


text:
[Bug]: Bindings section doesn't show expected value for Modal Widget and SelectWidget

Is there an existing issue for this?

[X] I have searched the existing issues

Description

For select widget, filterText accordion is not opening, is this expected?
For insert modal / show modal, the popup looks like this, should we just not show the popup when no bindings?

Steps To Reproduce

Add widgets and bind data to them
Open entity explorer, click on show bindings
Check the binding value

Public Sample App
No response
Environment
Production
Issue video log
No response
Version
1.9.61

@AmanAgarwal041 after the modal.name change the modal widget won't be showing empty binding section anymore, correct?


text:
[Bug] Menu widget needs to show transparent background

The menu widget continues to show white colour even when you choose no background colour. I think it'll be better if the colour is transparent, then the button can fit into the background.
@Tooluloope @jsartisan @somangshu

@wmdev0808 here we will also change the background / text colour property inline to the button widget style customisation changes.

Box shadow
Menu styles (Primary, Warning, Danger, Info, Secondary, Custom)
border radius
get all style attributes inside style section

We will cover all this with the above fixes

authors: areyabhishek somangshu


text:
fix: App crash on js rename

Description

Add a TL;DR when description is extra long (helps content team)
Please include a summary of the changes and which issue has been fixed. Please also include relevant motivation
and context. List any dependencies that are required for this change
Links to Notion, Figma or any other documents that might be relevant to the PR

PR fixes following issue(s)
Fixes # (issue number)

if no issue exists, please create an issue and ask the maintainers about this first

Media

A video or a GIF is preferred. when using Loom, don’t embed because it looks like it’s a GIF. instead, just link to the video

Type of change

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Chore (housekeeping or task changes that don't impact user perception)
This change requires a documentation update

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

[ ] Manual
[ ] JUnit
[ ] Jest
[ ] Cypress

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

[ ] My code follows the style guidelines of this project
[ ] 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
[ ] 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

/build-deploy-preview


text:
fix stop Rich text Editor from crashing on Modal

Description
Changed Rich text Mechanism of onDestroy to fix Rich text Editor on Modal.
Fixes #6035
Type of change

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

How Has This Been Tested?
UI verification
Checklist:

[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
[x] New and existing unit tests pass locally with my changes

Test coverage results :test_tube:
:red_circle: Total coverage has decreased
// Code coverage diff between base branch:release and head branch: fix/6035_RTE_in_modal

Status
File
% Stmts
% Branch
% Funcs
% Lines

:red_circle:
total
51.9 (0)
33.51 (-0.01)
30 (0)
52.57 (0)

:red_circle:
app/client/src/utils/autocomplete/TernServer.ts
50.59 (-0.24)
39.41 (-0.84)
36.21 (0)
54.77 (-0.27)

/ok-to-test sha=69a2f85

/ok-to-test sha=75e35c1

@rahulramesha I am able to repro the issue on Firefox. Working fine on chrome and safari.

/ok-to-test sha=d0c4993

@rahulramesha Getting something went wrong on RTE on firefox.

@vivekverma2312 , could you share me that app, it seems to be working fine in the app i was testing.

@rahulramesha Please use below link to debug. Error is observed for the 2nd click in action button.
https://deploy-preview-6077--appsmith-editor-ce.netlify.app/applications/60e44fa66dac1a490b6a50da/pages/60e44fa66dac1a490b6a50dc

/ok-to-test sha=762c4fa

@rahulramesha It's working fine now.

Rerunning all test, Unrelated tests failed

/ok-to-test sha=5c71bc9

/ok-to-test sha=10ad7a8

authors: rahulramesha somangshu vivekverma2312


text:
More detailed description of the Architecture and Anatomy of a stack

It would really help stack developers if we had a section that really describes what a developer needs provide in their stack at each of the phases (e.g. init, run, etc.) and hoe that maps to the various files in the hierarchy. The intro to this should be a more details describing of the architectural framework of a stack (i.e. more than the simple tree structure we describe already). Maybe we could so this along the lines of "Architecture and Anatomy of a stack" section?
I'd be happy to take a first cut at this.

I'm working on this, will post a first draft soon

repo: appsody/website


text:
SELinux permissions

Checklist

[x] commit message follows commit guidelines.
[x] website builds and runs in production - for information on how to test locally go here.

Description

Added considerations on whitelisting mount points in case SELinux policies prevent access from Docker containers to host directories
Related Issues

https://github.com/appsody/appsody/issues/74

Verified this is good and needed (I'm using Appsody on OpenShift 3.11)
I did the following:
[root@solan1 my-project]# chcon -Rt svirt_sandbox_file_t /dev
With my set up simply being at /dev (project being at /dev/my-project, and all is well 😄

authors: a-roberts chilanti


text:
Crash when cancel on selecting a date

When you click on the calendar button it shows the calendar picker as it should but then if you click cancel the app crashes
"The getter year was called with null"
This is due to lines 314 & 315 referring to a date that is null in flutter_calendar.dart. Moving these inside the if statement will fix the issue
Do you need a PR or can you make the change?
Paul

Fixed.

authors: Paul-Todd ericwindmill


text:
chore: upgrading dependencies

What does this PR do?
(Provide a description of what this PR does.)
Test Plan
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)
Related PRs and Issues
(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)
Have you read the Contributing Guidelines on issues?
(Write your answer here.)

Building base image for testing here: https://github.com/EVDOG4LIFE/docker-base-bumpcheck/actions/runs/10223127773
50min - 1 hr build time and will be pushed as the latest version here: https://hub.docker.com/repository/docker/evdog/appwrite/general
Previously tested with the docker-compose bump and all was well.

repo: appwrite/docker-base


text:
Chat history Redis

Chat history is now stored in Redis instead of memory.
Note that for some reason, messages are also stored in PostgreSQL. I didn't touch the Postgre code, only the memory code was replaced by Redis. I, however, added a comment about this weird duplicity.
I didn't test the code. You know how to test it much better, than I do.
Fixes #3.

Full user chat history is persisted in the PostgreSQL.
I will try to test it tomorrow

@vporton the code is fulll of python issues. Could you fix those so I can focus on testing the logic?

OK, I fixed the Python exceptions.


text:
Create a provision operation when creating a database

Add custom adapter for Operation that prepends /databases/:id when there is a database

fixes #38 refs #28
@mixonic for you

Gracias :-) :cake:

authors: bantic mixonic


text:
Services and VHost styles

Updated to new micro footer
Update slider styles
Adding cost estimator component to service sliders
Updated vhost styles

Requires an updated aptible-sass#diesel

For you @mixonic

@sandersonet great tests! I've left some small additional feedback.

Thanks for the feedback @mixonic, PR updated with recommended changes.

Great stuff @sandersonet

authors: mixonic sandersonet


text:
Bump to current Go version.

1.18 is EOL as of this past February.

Thank you for this... I am waiting for the merge, to fix the cves in my docker images...

https://app.shortcut.com/aptible/story/12520/release-supercrontic-go-version-bump

repo: aptible/supercronic