text:
[5.0] [index] Fix infinite loop while looking at superclasses

Cherry-pick https://github.com/apple/swift/pull/23674 to 5.0

Explanation: Fixes an infinite loop when indexing an invalid class with circular inheritance.
Scope: Affects indexing (including indexing while building) of classes.
SR Issue: SR-10236
Radar: rdar://49434989
Risk: Low; avoids infinite loop by keeping track of already seen classes.
Testing: Regression test cases added.
Reviewer: @akyrtzi

While checking for superclasses in isUnitTest, we need to handle
circular inheritance. For good measure, add tests for protocols as well.
The new API is designed to behave the same as walkInheritedProtocols
except that is walks over superclasses.
https://bugs.swift.org/browse/SR-10236
rdar://49434989

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 2ea6c058d8ac457ce86416df77ae3e4d3bd835f7

@swift-ci please test Linux

Build failed
Swift Test Linux Platform
Git Sha - 2ea6c058d8ac457ce86416df77ae3e4d3bd835f7

@swift-ci clean test linux

authors: benlangmuir swift-ci tkremenek


text:
[Sema] Fix Differentiable member type usage crasher.

Fix crasher when conforming a synthesized member type (e.g. CotangentVector) to a protocol with property requirements.
Resolves TF-466. Enabling general extensions of synthesized member types requires extra work.

@swift-ci Please test tensorflow

source: gharchive/pull-request

repo: apple/swift

license_type: permissive

license_source: github-api


text:
[5.1] [clang-importer] Fix option -disable-modules-validate-system-headers

Cherry-pick https://github.com/apple/swift/pull/24877 to swift-5.1-branch
Reviewed by: @jrose-apple

This option stopped working when clang changed its default behaviour to
-fmodules-validate-system-headers; we now need to explicitly disable it
to preserve the behaviour of our flag.
rdar://problem/50908762

@swift-ci please test


text:
Add default implementations for AdditiveArithmetic.{+=, -=}.

This patch defines a default implementation for += and -= in extension AdditiveArithmetic implemented in terms of + and -.

@swift-ci please smoke test

These need availability (or @_alwaysEmitIntoClient, which is probably fair since they're so simple).

@swift-ci please smoke test

These need availability (or @_alwaysEmitIntoClient, which is probably fair since they're so simple).

Added @_alwaysEmitIntoClient.

@stephentyrone There isn't a default implementation for Numeric.*= either. Should we add one for that?

FYI, default implementation could affect type-checker performance because we currently consider both protocol requirement and it's default implementation, so let's at least run smoke perf suite on these changes.

@swift-ci please smoke test compiler performance

Summary for master smoketest
Unexpected test results, excluded stats for ReactiveCocoa
No regressions above thresholds

Debug

debug brief
debug detailed

Release

release brief
release detailed

Debug

debug 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
110,196,000,417
110,249,708,326
53,707,909
0.05%

LLVM.NumLLVMBytesOutput
6,157,552
6,157,576
24
0.0%

time.swift-driver.wall
14.3s
14.4s
140.8ms
0.99%

debug 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) (21)

name
old
new
delta
delta_pct

AST.NumLoadedModules
1,038
1,038
0
0.0%

AST.NumTotalClangImportedEntities
4,084
4,084
0
0.0%

IRModule.NumIRBasicBlocks
18,754
18,754
0
0.0%

IRModule.NumIRFunctions
10,570
10,570
0
0.0%

IRModule.NumIRGlobals
8,065
8,065
0
0.0%

IRModule.NumIRInsts
313,674
313,674
0
0.0%

IRModule.NumIRValueSymbols
17,698
17,698
0
0.0%

LLVM.NumLLVMBytesOutput
6,157,552
6,157,576
24
0.0%

SILModule.NumSILGenFunctions
5,372
5,372
0
0.0%

SILModule.NumSILOptFunctions
7,018
7,018
0
0.0%

Sema.NumConformancesDeserialized
14,807
14,807
0
0.0%

Sema.NumConstraintScopes
38,152
38,462
310
0.81%

Sema.NumDeclsDeserialized
141,012
141,142
130
0.09%

Sema.NumDeclsValidated
11,356
11,356
0
0.0%

Sema.NumFunctionsTypechecked
1,516
1,516
0
0.0%

Sema.NumGenericSignatureBuilders
4,316
4,316
0
0.0%

Sema.NumLazyGenericEnvironments
31,151
31,201
50
0.16%

Sema.NumLazyGenericEnvironmentsLoaded
2,024
2,024
0
0.0%

Sema.NumLazyIterableDeclContexts
24,525
24,545
20
0.08%

Sema.NumTypesDeserialized
61,071
61,089
18
0.03%

Sema.NumTypesValidated
12,058
12,058
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
141,772,134,083
141,644,626,559
-127,507,524
-0.09%

LLVM.NumLLVMBytesOutput
7,176,568
7,176,484
-84
-0.0%

time.swift-driver.wall
25.5s
25.6s
25.5ms
0.1%

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) (21)

name
old
new
delta
delta_pct

AST.NumLoadedModules
76
76
0
0.0%

AST.NumTotalClangImportedEntities
2,226
2,226
0
0.0%

IRModule.NumIRBasicBlocks
21,184
21,184
0
0.0%

IRModule.NumIRFunctions
10,056
10,056
0
0.0%

IRModule.NumIRGlobals
8,083
8,083
0
0.0%

IRModule.NumIRInsts
224,172
224,172
0
0.0%

IRModule.NumIRValueSymbols
17,313
17,313
0
0.0%

LLVM.NumLLVMBytesOutput
7,176,568
7,176,484
-84
-0.0%

SILModule.NumSILGenFunctions
4,178
4,178
0
0.0%

SILModule.NumSILOptFunctions
5,850
5,850
0
0.0%

Sema.NumConformancesDeserialized
12,333
12,333
0
0.0%

Sema.NumConstraintScopes
37,946
38,256
310
0.82%

Sema.NumDeclsDeserialized
31,963
31,979
16
0.05%

Sema.NumDeclsValidated
7,784
7,784
0
0.0%

Sema.NumFunctionsTypechecked
1,526
1,526
0
0.0%

Sema.NumGenericSignatureBuilders
1,612
1,612
0
0.0%

Sema.NumLazyGenericEnvironments
6,595
6,601
6
0.09%

Sema.NumLazyGenericEnvironmentsLoaded
130
130
0
0.0%

Sema.NumLazyIterableDeclContexts
4,267
4,269
2
0.05%

Sema.NumTypesDeserialized
17,691
17,693
2
0.01%

Sema.NumTypesValidated
6,942
6,942
0
0.0%

@stephentyrone is this patch ready?

@stephentyrone @xedin I’m good merging this if you are

@airspeedswift How do you feel about the use of @aEIC here? I don't think it's actually necessary, right?

I think it's fine. The implementations are so trivial so inlining would always be optimal, and it'd be infuriating to have to if #available them.

LGTM, then.

authors: airspeedswift jrose-apple rxwei stephentyrone swift-ci xedin


text:
[mandatory-inlining] Fix lifetime extension error.

This bug is caused by a quirk in the API of the linear lifetime
checker. Specifically, even though valueHasLinearLifetime is passed a SILValue
(the value whose lifetime one is checking), really it doesnt care about that
value (except for error diagnostics). Really it just cares about the parent
block of the value since it assumes that the value is guaranteed to dominate all
uses.
This creates a footgun when if one is writing code using "generic ossa/non-ossa"
routines on SILBuilder (the emit*Operation methods), if one in non-ossa code
calls that function, it returns the input value of the strong_retain. This
causes the linear lifetime error, to use the parent block of the argument of the
retain, instead of the parent block of the retain itself. This then causes it to
find the wrong leaking blocks and thus insert destroys in the wrong places.
I fix this problem in this commit by noting that the partial apply is our
original insertion point for the copy, so of course it is going to be in the
same block. So I changed the linear lifetime checker to check for leaks with
respect to the partial applies result.
In a subsequent commit, I am going to add a new API on top of this that is based
around the use of the value by the partial apply (maybe
extendLifetimeFromUseToInsertionPoint?). By using the use, it will express in
code more clearly what is happening here and will insert the copy for you.
rdar://54234011

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

Resolves SR-NNNN.

@swift-ci test

Sorry, I don't understand enough to review. I'll let @atrick review.

I am going to update the patch given Andy's comments and merge this.

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge

authors: eeckstein gottesmm


text:
[Typechecker] @dynamicMemberLookup can't find method without arg label

If we don't have a subscript with an argument label, then @dynamicMemberLookup will complain about not finding a subscript(dynamicMember:). For example:
// error: @dynamicMemberLookup attribute requires 'S' to have a
//        'subscript(dynamicMember:)' method that accepts either
//        'ExpressibleByStringLiteral' or a keypath
@dynamicMemberLookup
struct S {
  subscript(dynamicMember: String) -> String {
    fatalError()
  }
}

This can be improved by emitting another diagnostic to tell the user that they need to add an explicit argument label to satisfy the @dynamicMemberLookup requirement.
Resolves SR-10557.

The placeholder is confusing, I think. It’s telling the user to create an argument label, but inserting a placeholder with hint “argument label” in the position of the internal parameter name.
I think @xedin’s solution is right: We should have a fix-it suggestion for any candidate that matches regardless of internal parameter name, and the fix-it should suggest adding dynamicMember as the argument label.

Whoops, did a really bad rebase by accident. Will open a new PR.

authors: theblixguy xwu


text:
[CS] Don't create new locator when simplifying to anchor

We can directly use the version of simplifyLocator that works on
an anchor and path array ref instead.

@swift-ci please smoke test


text:
[utils] Improve swift_build_support.shell failure messages.

What's in this pull request?
[utils] Improve swift_build_support.shell failure messages.

 - This improves the error messages when commands fail (or don't exist) to show
   a one-line summary of the issue instead of the Python backtrace, and matches
   what was being done by the matching function in `SwiftBuildSupport`.

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

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

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

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

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

(this depends on https://github.com/apple/swift/pull/2830, I will rebase once merged)

/cc @gribozavr
@swift-ci please Python lint

@swift-ci Please smoke test

OS X smoke test issue was unrelated, I removed the build directory.
@swift-ci Please smoke test OS X platform

@ddunbar
FAIL: Swift :: Python/swift_build_support.swift (2295 of 8267)
******************** TEST 'Swift :: Python/swift_build_support.swift' FAILED ********************
Script:
--
/usr/bin/python -m unittest discover -s /home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/swift/validation-test/Python/../../utils/swift_build_support
--
Exit Code: 1

Command Output (stderr):
--
ss....s.................................E................
======================================================================
ERROR: test_tar_nonexistent_file_raises (tests.test_tar.TarTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/swift/utils/swift_build_support/tests/test_tar.py", line 56, in test_tar_nonexistent_file_raises
    destination='/another/path/that/shouldnt/exist')
  File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/swift/utils/swift_build_support/swift_build_support/tar.py", line 35, in tar
    shell.call(args + [source], stderr=subprocess.PIPE)
  File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/swift/utils/swift_build_support/swift_build_support/shell.py", line 76, in call
    str(e.returncode) + ", aborting")
  File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/swift/utils/swift_build_support/swift_build_support/diagnostics.py", line 32, in fatal
    raise SystemExit(sys.argv[0] + ": fatal error: " + message)
SystemExit: python -m unittest: fatal error: command terminated with a non-zero exit status 2, aborting

----------------------------------------------------------------------
Ran 57 tests in 8.371s

FAILED (errors=1, skipped=3)

--

Oops, didn't realize we had coverage of this. Will fix!

@swift-ci Please smoke test

authors: ddunbar gribozavr


text:
Temporarily disable a SILVerifier check for valid accessed storage.

This won't actually affect compilation. The verifier check makes sure
that all formatlly accessed storage has a recognized source to guard
against the possiblity for exclusivity optimization to be overly
optimistic. The check currently fails on address-type block arguments,
but the cases where it fails don't actually need to be recognized for
exclusivity optimization to work properly (don't worry, we won't
actually drop any checks in these cases). I plan to completely
disallow address block args instead before reenabling the access
verification.
There are still some loop passes that clone regions without properly
sinking projections. It should be straightforward to adapt
SinkAddressProjections to handle loops.
Fixes rdar://57291811 and rdar://56914099
SIL verification failed: Unknown formal access pattern: storage

@swift-ci smoke test


text:
[irgen] For benchmarking purposes, add the ability to force the alignment of all globals to a custom alignment.

I have seen in certain cases benchmarks being noisy b/c the alignment of global
data was shifting in between 8 and 16 byte aligned. This patch provides an
internal LLVM option that enables us to experiment with seeing if aligning data
like this (just for measuring perf), helps to stabilize said benchmarks.

@eeckstein this was inspired by your work aligning the module to page size.

@swift-ci smoke test

@swift-ci test windows platform

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci test windows platform

@swift-ci test windows platform

@swift-ci test windows platform

@swift-ci smoke test

@swift-ci test windows platform

@swift-ci test windows platform

@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - 42c9273035fe8ae497c35c4e8e97d0eb7e4c7085

Build failed
Swift Test OS X Platform
Git Sha - 42c9273035fe8ae497c35c4e8e97d0eb7e4c7085

@eeckstein I think someone needs to investigate the effects. I don't have time now though. @shahmishal is looking at putting my previous work of creating a linux benchmark build on the CI now. My hope is he uses this and makes sure it works as I expect.

@swift-ci smoke test

Looking at this real quick. Going to see if I can land this real quick.

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci test windows platform

I have a patch that fixes the windows failure. Needed this: {{( dllexport)?}}

I want to see if the linux side works before I do a force push.

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

OS X failure is something from swift driver. Not sure what it is.

@swift-ci smoke test OS X platform

I tested this out a bit and we actually do not want to do this. This is b/c we will also do this to metadata globals which will break invariants.

authors: gottesmm swift-ci


text:
[TF] Remove PythonKit from build presets.

PythonKit was removed as a Swift build dependency in 9f0e0a6.
PythonKit was instead added as a CMake dependency of tensorflow/swift-apis in
tensorflow/swift-apis#1045.

Fixes build error:
[./utils/build-script] NOTE: using preset "tensorflow_linux,tensorflow_swift_apis,no_test", which expands to

./utils/build-script --assertions --swift-enable-ast-verifier=0 '--swift-install-components=autolink-driver;compiler;clang-resource-dir-symlink;stdlib;swift-remote-mirror;sdk-overlay;parser-lib;toolchain-tools;license;sourcekit-inproc' '--llvm-install-components=llvm-cov;llvm-profdata;IndexStore;clang;clang-resource-headers;compiler-rt;clangd;lld' --llbuild --swiftpm --xctest --libicu --libcxx --build-ninja --install-llvm --install-swift --install-lldb --install-llbuild --install-swiftpm --install-xctest --install-libicu --install-prefix=/usr --install-libcxx --install-sourcekit-lsp --build-swift-static-stdlib --build-swift-static-sdk-overlay --build-swift-stdlib-unittest-extra --test-installable-package --toolchain-benchmarks --install-destdir=/swift-base/swift/swift-nightly-install --installable-package=/swift-base/swift/swift-tensorflow-LOCAL-2020-07-28-a-.tar.gz --build-subdir=buildbot_linux --lldb --release --test --validation-test --long-test --stress-test --test-optimized --foundation --libdispatch --indexstore-db --sourcekit-lsp '--lit-args=-v --time-tests' --lldb-test-swift-only --install-foundation --install-libdispatch --reconfigure --skip-test-cmark --skip-test-lldb --skip-test-swift --skip-test-llbuild --skip-test-swiftpm --skip-test-xctest --skip-test-foundation --skip-test-libdispatch --skip-test-playgroundsupport --skip-test-libicu --skip-test-indexstore-db --skip-test-sourcekit-lsp --pythonkit --install-pythonkit --test-installable-package= --tensorflow-swift-apis --install-tensorflow-swift-apis

error: unknown setting: pythonkit

Merging to unblock the master -> tensorflow merge. Happy to address feedback later!

LGTM

authors: compnerd dan-zheng


text:
[Test] Add Interpreter and IRGen tests for SR-13203

Adding more tests for SR-13203:

An Interpreter test that prints the name of the class.
An IRGen test that checks for the mangled name.

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 6856257f892fb66594e931c4bbaaa2b559d8ab64

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 6856257f892fb66594e931c4bbaaa2b559d8ab64

Build failed
Swift Test OS X Platform
Git Sha - 6856257f892fb66594e931c4bbaaa2b559d8ab64

authors: slavapestov swift-ci theblixguy


text:
[Clang Importer] Set IsSystem module flag for Clang input files when precompiling a clang module

This flag is important when we are pre-building system modules to be loaded later in Explicit Module Builds.
Resolves rdar://70212660

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 9fd82f778a0350e7219b229ef826333a486d2318

@swift-ci please smoke test

@swift-ci please smoke test macOS Platform

@swift-ci please smoke test Windows Platform

@swift-ci please smoke test macOS Platform

@swift-ci please smoke test macOS Platform

@swift-ci please smoke test Windows Platform

@swift-ci please smoke test macOS Platform

@swift-ci please smoke test Windows Platform

@swift-ci please smoke test macOS Platform

@swift-ci please smoke test Windows Platform

@swift-ci please smoke test

@swift-ci please smoke test Windows Platform

authors: artemcm swift-ci


text:
DependenciesScanner: include -sdk in Swift module building command

Swift module building commands need -sdk because dependencies sometimes use
sdk-relative paths (prebuilt modules for example). Without -sdk, the command
will not be able to local these dependencies, leading to unnecessary
rebuilding from textual interfaces.
rdar://81177968

@swift-ci please smoke test

@swift-ci please smoke test


text:
[Sema] Check existence of GenericSignature before getting GenericParamList from it

Fixes one compiler crasher.

@swift-ci Please smoke test

@swift-ci Please smoke test


text:
SILGen: Carry WMO of type lowering context to closure captures.

TypeConverter doesn't know by itself what SILModule it's currently lowering on
behalf of, so the existing code forming the TypeExpansionContext for opaque types
incorrectly set the isWholeModule flag to always false. This created a miscompile
when a public API contained a closure that captured a value involving private types
from another file in the same module because of mismatched type expansion contexts
inside and outside the closure. Fixes rdar://93821679

@swift-ci Please test

@swift-ci Please test source compatibility


text:
[IRGen] Request LLDB specific tuning for all targets.

Previously the default was used, implying LLDB specific tuning only for Darwin targets.
For example, the compilation flags (DW_AT_APPLE_flags attribute) are only emitted when tuning for LLDB. With Swift, LLDB uses this attribute mostly as a fallback source for the compilation options specified in the embedded serialized AST.
However, it is the only source for LLDB on whether a custom '-resource-dir' was used.
cf. lldb's SwiftASTContext::CreateInstance
Motivation
In my testing this enabled LLDB to find the stdlib that was used at compile time via '-resource-dir' when remote-debugging linux targets.
Another approach might be to add a compiler flag (similar to clang's -ggdb/-glldb) but that doesn't seem to be particularly useful to me, given that LLDB is (AFAIK) the only debugger capable of debugging Swift in any meaningful way at the moment.
Ditto for potential adverse effects on GDB debugging by tuning for LLDB.
That said I would very much appreciate feedback in this regard; this is basically just guesswork on my part...
Test
I added a simple test to check whether the LLDB-tuning specific DW_AT_APPLE_flags attribute is emitted into the assembled object files.
There is no test for whether the exact compiler options end up being emitted but there are already existing tests that check that certain compiler options are emitted to IR and the IR -> object file transformation should be covered by LLVM.

We are very much trying to kill this set of flags, and LLDB already needs to use its own resource dir rather than the one a project was built with (if different). cc @scallanan, @jimingham, @adrian-prantl.

LGTM

@swift-ci please test

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 4980cd214c67257aba277213a1cebce228775d14
Test requested by - @adrian-prantl

let's try that again:
@swift-ci please test

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 4980cd214c67257aba277213a1cebce228775d14
Test requested by - @adrian-prantl

@swift-ci Please clean smoke test Linux platform

@swift-ci Please clean smoke test Linux platform

(Trying a clean Linux smoke test since I don't trust our incremental builds used by multiple PR build runs...)

Thanks for the feedback!
I updated the commit message and changed the test not to use DW_AT_APPLE_flags. Instead I switched to the same approach used by the corresponding LLVM test.
(Sorry for killing the running tests)

Hey all, I'm going to try to repro the test failures on Ubuntu.  Please hold off on merging until we can track down why the REPL tests are failing.  I'm starting to look at this now.

Fixed my botched copy&paste job. Sorry about that.
%llvm-readobj is not available as a lit substitution. Is it OK to use plain llvm-readobj or should I add the substitution to lit.cfg?
And with regard to LLDB, do I understand correctly that the recommended approach would be to use an entire ('custom') toolchain and to use that toolchain's LLDB to debug targets built against it?
Thanks again for the help!

Hi @Jnosh,

And with regard to LLDB, do I understand correctly that the recommended approach would be to use an entire ('custom') toolchain and to use that toolchain's LLDB to debug targets built against it?
Thanks again for the help!

I think you're asking if you need to use an LLDB that matches the Swift compiler that you're using to build programs that you want to build.  i.e. if you modify Swift, build a Swift compiler, and build programs with that modified Swift compiler, you do need to use the corresponding LLDB that goes with that Swift.  Swift and LLDB currently are joined at the hip, as deep internals of Swift are accessed by the debugger to handle running Swift expressions and printing variables from Swift code.
Did I answer the right question here?

(Also, please note we're still trying to reproduce the Linux issue, so please do not merge this change in until we give an all clear.  Thanks!)

@swift-ci Please test Linux platform

@swift-ci Please test Linux platform

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - cab313732fa4ff8132fd12c4f431b691492baf3d
Test requested by - @tfiala

@swift-ci Please clean test Linux platform
(clean again...)

@swift-ci Please clean test Linux platform

Hi Todd,

I think you're asking if you need to use an LLDB that matches the Swift compiler that you're using to build programs that you want to build. i.e. if you modify Swift, build a Swift compiler, and build programs with that modified Swift compiler, you do need to use the corresponding LLDB that goes with that Swift. Swift and LLDB currently are joined at the hip, as deep internals of Swift are accessed by the debugger to handle running Swift expressions and printing variables from Swift code.

It's more that I'm trying to use a standard library not located in the toolchain that LLDB is in. Let me give you some context:
I'm cross-compiling an executable for a Linux target from a macOS host. To do so I use the -resource-dir flag to point swiftcat a Linux toolchain so it can find the Linux stdlib. This part is working fine.
Now I'm trying to remote debug the executable using LLDB which also works except for LLDB of course not finding a matching stdlib for the Linux target. I can just copy the Linux stdlib into the OS X toolchain that I'm using but I was trying to avoid that since I'm mostly using the Xcode toolchain or development snapshots and I'd prefer not to modify those installations.
I was looking at LLDB for unrelated reasons and noticed that it will use the -resource-dir set at compile time if the compile flags are available which is what ultimately lead me here.
My current thinking is that it's probably cleanest to just create a separate toolchain for this purpose and not use the Xcode or Library/Developer toolchains in combination with -resource-dir at all.
i.e. build a separate macOS toolchain that also contains a Linux stdlib and use lldb (and swiftc) from that toolchain so it can simply find the target stdlib in its own toolchain.
Would that be a sensible approach?

[For posterity's sake: note after I forced a clean build on the PR Linux (full build) tester, we got a good build.  To me, this -- combined with the other non-PR CI not seeing this issue -- leads me to believe something in the incremental PR building across PRs is likely not rebuilding properly.]
@Jnosh, thanks for clarifying what you're trying to accomplish!

I'm cross-compiling an executable for a Linux target from a macOS host. To do so I use the -resource-dir flag to point swiftcat a Linux toolchain so it can find the Linux stdlib. This part is working fine.

You mentioned it later on, but I would expect the way to handle this would be to create an SDK for Linux that lives on the macOS side.  This would allow a macOS-side lldb to connect to the Linux binaries pushed over to the Linux target, and (if the SDK lookup code is working correctly) find the Linux binaries on the macOS host.
I haven't done this yet, and I would not at all be surprised if there is work to be done to resolve Linux SDK-related content properly on the local macOS end.  You may be the first forging into those waters, although I'd expect this to eventually be an extremely useful workflow for Swift-based server development for those already on macOS.
I'm also unclear on whether using a macOS-side Linux SDK requires a separate toolchain, or whether it suffices to just specify the SDK to the swiftc from your locally built swiftc (or the one from Xcode 8.x).
Including @jrose-apple, who might have a better answer here.

@swift-ci Please smoke test Linux platform

(Trying to unclog the macOS smoke test)
@swift-ci Please smoke test OS platform

@tfiala, thanks for taking the time!

I'm cross-compiling an executable for a Linux target from a macOS host. To do so I use the -resource-dir flag to point swiftcat a Linux toolchain so it can find the Linux stdlib. This part is working fine.

You mentioned it later on, but I would expect the way to handle this would be to create an SDK for Linux that lives on the macOS side. This would allow a macOS-side lldb to connect to the Linux binaries pushed over to the Linux target, and (if the SDK lookup code is working correctly) find the Linux binaries on the macOS host.

A Linux SDK in this context would be like the macOS, iOS, ... SDKs? i.e. collection of headers/modules, objects to link against, ...?

I haven't done this yet, and I would not at all be surprised if there is work to be done to resolve Linux SDK-related content properly on the local macOS end.

Yeah, the locations I came across while looking into this and a few other issues generally dealt with SDKs only for Darwin targets.

You may be the first forging into those waters, although I'd expect this to eventually be an extremely useful workflow for Swift-based server development for those already on macOS.

Agreed. Although I'm currently compiling a standalone target (hobby Kernel) so I'm mostly avoiding the SDK issues.

I'm also unclear on whether using a macOS-side Linux SDK requires a separate toolchain, or whether it suffices to just specify the SDK to the swiftc from your locally built swiftc (or the one from Xcode 8.x).

From what (little) I can tell, using the normal macOS toolchain should mostly work just fine once the compiler/lldb/... know how to find other SDKs. I'm actually pretty impressed at how flexible the compiler is in this regard already. 👍
From what I can tell all that's needed toolchain-wise is the Swift stdlib (and module overlays) for the target platform. (Which might conceivable also migrate to the SDK once binary compatibility is ironed out?)
Basically I just drop the usr/lib/swift/linux/x86_64/* and usr/lib/swift_static/linux/* parts of a Linux toolchain into a macOS toolchain and swiftc can compile objects for x86_64 Linux.
Linking is the only part that swiftc can't manage on its own yet. As you mentioned, an SDK to link against would be needed (+ compiler_rt) and the linker invocation would have to go through clang (with e.g. -use-ld=lld) instead of ld but ideally not much more than that...
LLDB also seems to work fairly well. Symlink usr/lib/swift into the toolchains LLDB.framework/Resources and the toolchain LLDB finds the Linux stdlib module.
Remote debugging Linux Swift binaries should probably work for the most part at that point.

I'm not quite sure what to say here. Clearly it's important for LLDB to find the Linux stdlib and such, as well as any headers (and other Swift modules) you're using in the target you're remote-debugging. At the same time, reading that automatically from the built library's debug info may eventually be incorrect, since LLDB has intimate knowledge of certain standard library types. We probably need a real story here in general—eventually there'll be a tension between "emulate the build environment as close as possible" and "LLDB and swiftc are tied to a particular version of the Swift standard library".

I don't think what you're doing now is likely to cause problems, though, as long as you're using an lldb you built alongside your swiftc.

@jrose-apple Can we merge this?

Ah, yes, this whole extra discussion isn't really about the debugger tuning directly.
@swift-ci Please smoke test

authors: Jnosh adrian-prantl jrose-apple slavapestov swift-ci tfiala


text:
Fix OwnershipLiveRange for @owned values getting transformed to none values via switch_enum

rdar://95039799
We are currently not computing OwnershipLiveRange correctly in the presence of switch_enum transforming the owned value to a none value.
We can end up with illegal SIL with LoadCopyToLoadBorrowOptimization, due to this.
Example:

sil [ossa] @switch_enum_test : $@convention(thin) (@inout StructWithEnum) -> () {
 bb0(%0 : $*StructWithEnum):
   %1 = struct_element_addr %0 : $*StructWithEnum, #StructWithEnum.val
   %2 = struct_element_addr %0 : $*StructWithEnum, #StructWithEnum.val
   %3 = load [copy] %2 : $*EnumA
   destroy_addr %1 : $*EnumA
   switch_enum %3 : $EnumA, case #EnumA.sometrivial!enumelt: bb1, case #EnumA.somenontrivial!enumelt:bb2, case #EnumA.none!enumelt: bb3

 bb1(%6 : $TrivialStruct):
   %f = function_ref @get_enum : $@convention(thin) () -> @owned EnumA
   %r = apply %f() : $@convention(thin) () -> @owned EnumA
   %ele = struct_element_addr %0 : $*StructWithEnum, #StructWithEnum.val
   store %r to [init] %ele :$*EnumA
   %9999 = tuple()
   return %9999 : $()

 bb2(%7 : @owned $NonTrivialStruct):
  unreachable

 bb3:
  unreachable
 }

can get transformed to:

sil [ossa] @switch_enum_test : $@convention(thin) (@inout StructWithEnum) -> () {

bb0(%0 : $*StructWithEnum):
  %1 = struct_element_addr %0 : $*StructWithEnum, #StructWithEnum.val
  %2 = struct_element_addr %0 : $*StructWithEnum, #StructWithEnum.val
  %3 = load_borrow %2 : $*EnumA
  destroy_addr %1 : $*EnumA
  switch_enum %3 : $EnumA, case #EnumA.sometrivial!enumelt: bb1, case #EnumA.somenontrivial!enumelt: bb2, case #EnumA.none!enumelt: bb3

bb1(%6 : $TrivialStruct):
  end_borrow %3 : $EnumA

  %8 = function_ref @get_enum : $@convention(thin) () -> @owned EnumA
  %9 = apply %8() : $@convention(thin) () -> @owned EnumA
  %10 = struct_element_addr %0 : $*StructWithEnum, #StructWithEnum.val
  store %9 to [init] %10 : $*EnumA
  %12 = tuple ()
  return %12 : $()

bb2(%14 : @guaranteed $NonTrivialStruct):
  unreachable

bb3:
  unreachable
}

which is incorrect:
Write:   destroy_addr %1 : $*EnumA
SIL verification failed: Found load borrow that is invalidated by a local write?!: loadBorrowImmutabilityAnalysis.isImmutable(LBI)
Verifying instruction:
     %2 = struct_element_addr %0 : $*StructWithEnum, #StructWithEnum.val
->   %3 = load_borrow %2 : $*EnumA
     switch_enum %3 : $EnumA, case #EnumA.sometrivial!enumelt: bb1, case #EnumA.somenontrivial!enumelt: bb2, case #EnumA.none!enumelt: bb3
     end_borrow %3 : $EnumA

@swift-ci test

I am fine with this for 5.6 to fix this bug. That being said, lets get on main the real fix for this as we discussed: getting @atrick's patch that stops OSSA from using dead end blocks committed. That will solve this problem while allowing us to turn back on this optimization. It will also eliminate a bunch of subtle bugs that we have seen due to dead end blocks in OSSA.

Fixed a code comment.

@swift-ci test

@swift-ci benchmark

Pasting benchmark results from the bot :
------- Performance (x86_64): -O -------
REGRESSION           OLD    NEW    DELTA    RATIO
FlattenListFlatMap   3006   3768   +25.3%   0.80x (?)
------- Code size: -O -------
------- Performance (x86_64): -Osize -------
IMPROVEMENT            OLD    NEW    DELTA    RATIO
FlattenListFlatMap     4206   2640   -37.2%   1.59x (?)
FlattenListLoop        1400   1029   -26.5%   1.36x (?)
PrefixAnySeqCntRange   15     13     -13.3%   1.15x (?)
StringWalk             1360   1240   -8.8%    1.10x (?)
StrComplexWalk         3020   2810   -7.0%    1.07x (?)
------- Code size: -Osize -------
------- Performance (x86_64): -Onone -------
REGRESSION                                        OLD    NEW    DELTA    RATIO
SIMDReduce.Int8                                   6303   7186   +14.0%   0.88x (?)
IMPROVEMENT                                       OLD    NEW    DELTA    RATIO
ObjectiveCBridgeFromNSDictionaryAnyObjectForced   6850   6400   -6.6%    1.07x (?)
------- Code size: -swiftlibs -------

authors: atrick gottesmm meg-gupta


text:
[test] NFC: Add missing REQUIRES

This test uses regex literals, so needs the regex parsing code to be available.
rdar://101486764

@swift-ci please smoke test and merge

@swift-ci please smoke test and merge


text:
SILCombine: don’t release owned arguments of a removed read-only function too early

This can cause a use-after-free runtime crash
Fixes SR-3301

@swift-ci Please smoke test and merge


text:
[silgen] Verify protocol witnesses's SIL right after emitting them.

These still get verified as part of SILGenModule's verification during SILGenModule's destructor. But moving this earlier catches the error earlier and makes it easier to debug any SIL issues immediately in the debugger rather than having to backtrack from the SILGenModule's destructor.

@swift-ci test

@swift-ci test macOS platform

Hit a misc swiftpm issue again... Going to smoke test this

@swift-ci test macOS platform

@swift-ci test macOS platform

@swift-ci test macOS platform


text:
SIL: Use a scoped SILBuilder to insert dealloc_stacks for closure captures.

Fixes rdar://105701833.

@swift-ci Please test


text:
Use preprocessor metaprogramming for macro roles in the demangle node printer

Yet more preprocessor metaprogramming for macro roles

@swift-ci please smoke test

@swift-ci please smoke test macOS

@swift-ci please clean smoke test macOS

Superseded by https://github.com/apple/swift/pull/70033


text:
[stdlib] Commenting out a few transparent annotations

To make standard library compile with resiliency on.
rdar://problem/30175030

@swift-ci Please smoke test and merge


text:
[IRGen] Assign layout strings for static layout generic types in meta…

…data initialization function
Explanation: The layout string needs to be assigned before completion, to make it available in recursive metadata initialization. Setting it in the completion function causes a race between other metadata initializers using it and the completion function running.
Scope: Compact Value Witnesses only
Issue: rdar://127535274
Original PR: https://github.com/apple/swift/pull/74058
Risk: Low. Only affects Compact Value Witnesses.
Testing: Added a validation test
Reviewer: @mikeash @aschwaighofer

@swift-ci test


text:
[swift 4] Better diagnostics for multi-line string literals (#9148)

This is a cherry-pick of https://github.com/apple/swift/pull/9148.

Explanation:
Scope: Limited, affects reporting of diagnostics regarding multi line string literals
Radar/SR: rdar://problem/31870223, https://bugs.swift.org/browse/SR-4701
Risk: Low
Testing: Normal PR testing is sufficient

@swift-ci please test

@benlangmuir can you review? If not, please let me know


text:
ModelSelect2Widget error

Hi everyone,
I have implemented this package in my project to retrieve set of items as dropdown choices and managed to get the Select2Widget working as it is; however when I tried to implement ModelSelect2Widget to have it retrieved from the object, it kept giving me Server Error (500) page. Been looking into this for a while now, appreciate if someone can provide some guidance.
forms.py
from django.forms import Form, ModelChoiceField
from core.models import Occurrence, SubOccurrence
from django_select2.forms import ModelSelect2Widget, Select2Widget

class OccurrenceConfigurationForm(Form):
    occurrence_select = ModelChoiceField(
        queryset=Occurrence.objects.all(),
        widget=Select2Widget()
    )

    sub_occurrence_select = ModelChoiceField(
        queryset=SubOccurrence.objects.all(),
        label=u"Sub Occurrence",
        widget=ModelSelect2Widget(
            model=SubOccurrence,
            search_fields=['name__icontains'],
        )
    )

models.py
from django.db import models

class Occurrence(models.Model):
    name = models.CharField(max_length=200)
    archived = models.BooleanField(default=False)

    def __str__(self):
        return self.name

class SubOccurrence(models.Model):
    name = models.CharField(max_length=200)
    archived = models.BooleanField(default=False)
    occurrence = models.ForeignKey(Occurrence,
                                   on_delete=models.CASCADE,
                                   related_name='sub_occurrences')

    def __str__(self):
        return self.name

Hi @ashrafaa if you get a 500 Server error, there must be an exception in your logs. If would greatly help if you could provide me with the exception that was raised.

Hi @codingjoe thanks for your reply. It seems like I might not set it up properly last time; now I managed to get it rendered, but then the issue is I dont have any option values. Below are the form content when printed out

Occurrence:	<select name="occurrence" required id="id_occurrence" data-allow-clear="false" data-minimum-input-length="0" class="django-select2 django-select2-heavy" data-field_id="MTM5NzgzOTY2NzgyMDcy:1gzLLs:pXrdfri0Jnoqpj_A1JidRfe1jL8" data-ajax--url="/select2/fields/auto.json" data-ajax--cache="true" data-ajax--type="GET">
</select>

Sub Occurrence:	<select name="sub_occurrence" required id="id_sub_occurrence" data-allow-clear="false" data-minimum-input-length="0" class="django-select2 django-select2-heavy" data-field_id="MTM5NzgzOTY2NzgyMTg0:1gzLLs:7n_9xd9OEGJ3VjmI7yknlKqRNQM" data-ajax--url="/select2/fields/auto.json" data-ajax--cache="true" data-ajax--type="GET" data-select2-dependent-fields="occurrence">
</select>

I see ModelSelect2Widget use of cache based on parent class of HeavySelect2Widget. I tried adding below lines to my settings, but it just then crashed the whole view (and again no useful exceptions raised in the logs! :()
CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/1",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
        }
    },
    'select2': {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/2",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
        }
    }
}

# Set the cache backend to select2
SELECT2_CACHE_BACKEND = 'select2'

Appreciate your pointing me to the right direction!

@ashrafaa that seems to be all correct. It is also expected that you don't see any options rendered. The options are being rendered on demain. That kind of the whole point. If you have a lot of choices – foreign key to large table – you don't want all the options to be rendered but loaded via AJAX.

source: gharchive/issue

authors: ashrafaa codingjoe

license: MIT


text:
Can't load bindings Error: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found

Hi,
node and pm2 version
v10.10.0 and 3.2.2
cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Getting below error in logs and service is not getting registered.
Logs:
appoptics:error Can't load bindings Error: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /data/pwaReact/capistranoDeployment_PWA/releases/20201203201522/node_modules/appoptics-bindings/build/Release/appoptics-bindings.node)
appoptics:error AppopticsAPM disabled due to: require failed:
appoptics:error api key _stats conflicts, ignoring

It looks like your issue might be installing appoptics on a different machine and copying the installations?
I created a container and installed, using node v10.23.0, and loaded. if i install on ubuntu 20.04 using gcc 9.3.0 then it references
cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
strings ao-metrics.node | grep CXXABI
CXXABI_1.3
__cxa_begin_catch@@CXXABI_1.3
__cxa_rethrow@@CXXABI_1.3
__cxa_end_catch@@CXXABI_1.3
__gxx_personality_v0@@CXXABI_1.3
strings appoptics-bindings.node | grep CXXABI
CXXABI_1.3
__cxa_begin_catch@@CXXABI_1.3
__cxa_allocate_exception@@CXXABI_1.3
_ZTVN10__cxxabiv117__class_type_infoE@@CXXABI_1.3
__cxa_free_exception@@CXXABI_1.3
_ZTVN10__cxxabiv120__si_class_type_infoE@@CXXABI_1.3
__cxa_rethrow@@CXXABI_1.3
__cxa_end_catch@@CXXABI_1.3
__gxx_personality_v0@@CXXABI_1.3
__cxa_throw@@CXXABI_1.3
_ZTVN10__cxxabiv121__vmi_class_type_infoE@@CXXABI_1.3
__cxa_pure_virtual@@CXXABI_1.3
[root@e33541433f09 Release]#
if i build on centos:8 i get
strings appoptics-bindings.node | grep CXXABI
CXXABI_1.3.8
CXXABI_1.3.9
CXXABI_1.3
__cxa_begin_catch@@CXXABI_1.3
__cxa_allocate_exception@@CXXABI_1.3
_ZTVN10__cxxabiv117__class_type_infoE@@CXXABI_1.3
__cxa_free_exception@@CXXABI_1.3
_ZdlPvm@@CXXABI_1.3.9
_ZTVN10__cxxabiv120__si_class_type_infoE@@CXXABI_1.3
__cxa_throw_bad_array_new_length@@CXXABI_1.3.8
__cxa_rethrow@@CXXABI_1.3
__cxa_end_catch@@CXXABI_1.3
__gxx_personality_v0@@CXXABI_1.3
__cxa_throw@@CXXABI_1.3
_ZTVN10__cxxabiv121__vmi_class_type_infoE@@CXXABI_1.3
__cxa_pure_virtual@@CXXABI_1.3

Yes, you’re right. We copy whole zipped installation from our pre prod server to production and then run it. I just checked pre prod server is on centos 6 which might be creating an issue here.
But as per the details shared by you, will it not work on centos 7 either then?

it depends on what libraries and compilers are installed. i would guess that the centos 6 pre-prod server has updated versions of the compiler and libraries because i would expect it to work if they were the libraries originally supplied. new versions may have new CXXABI versions but they don't drop the newest versions when they create new versions of the libraries and compiler.
the compiler that was distributed with centos 6 is not supported but it seems like the version installed now on your centos 6 system skipped g++ 4.8.5 (because it doesn't supply CXXABI 1.3.8 or 1.3.9).
the easiest suggestion would be to do the pre-prod using centos 7. if that's not possible then the centos 6 system should have gcc/g++ 4.8.5 and libraries.
i'm working on pre-built binaries now; we will build with the lowest version of the OS and compiler that we support.

i will post a message on one of these issues when pre-built binaries are ready to go. i appreciate the information you provide when you submit an issue.

authors: bmacnaughton immohitrathi

repo: appoptics/appoptics-apm-node


text:
Change AppToolBar Background Color

Is there a way to change the AppToolBar background color?  I tried appBar.getElement().getStyle().set("background", "var(--lumo-contrast-10pct") but it seems not to work.  Thank you!

I also tried using a custom style via css and it the background is still show as default.
[part~="app-bar"] {     border: 1px solid var(--lumo-shade-10pct);         background-color: black;     transition: border-color ease-in-out .15s, box-shadow ease-in-out .15s; }

@allenvpn312 Have you tried setting?

--app-layout-bar-background-color

Thank you for the quick response.  Is this the corret syntax?
var(--app-layout-bar-background-color):  black

Untested but try the following:
html {
  --app-layout-bar-background-color: black;
}

Ahhh...I understand now.  Thank you

repo: appreciated/vaadin-app-layout


text:
[Bug]: Curl importer improvements

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Quoting from Slack:
@Rohan Arthur @Parth The CURL import page looks a bit broken.
Location of the logo
Location and size of the button seems off
CMD+Enter doesn’t work

Ref: https://theappsmith.slack.com/archives/C02KTH6EHUG/p1644372129617709
Steps To Reproduce

Create a curl importer component.
Add curl string. press cmd+enter.

Environment
Production
Version
Cloud

Parth's design available here: https://www.figma.com/file/Qs7p5frNx7uEfVYpADGk0d/Datasource-Pane-Improvements?node-id=9%3A4139

repo: appsmithorg/appsmith


text:
[Bug]: The old file is replaced with new file in s3 crud page upload

Is there an existing issue for this?

[X] I have searched the existing issues

Description
If the user tries to upload the 2nd file in the same folder of the s3 crud page the Images are overlapped instead of Creating the new file
Note: This issue is occurring because all the file names are displayed as undefined

Steps To Reproduce

generate a S3 crud page
now add a folder name as folder 1 and add a file no 1
upload a file
Now search for the folder name folder one there will a file 1 displayed
Now Try to add a file 2 to the same folder that is folder 1
Now the uploaded file 2 replaces file 1 instead of being added as a new file

Public Sample App
No response
Version
release

This is happening when uploading a file directly also. [without using a folder]

List.items[0].Input -> doesn't have text property. Hence the file name is undefined.
Sample app export

Discussed with Raksha, found the issue to be fixed in Production environment. Browser Tested on - Chrome

Discussed with @RakshaKShetty, found the issue to be fixed in Production environment. Browser Tested on - Chrome
.

authors: Aishwarya-U-R RakshaKShetty btsgh eco-monk


text:
[Bug]: Generate page with Data - Created Queries are hidden in the dropdown and not immediately visible to user

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Queries created through generate page with data are not immediately visible - though they are present in the number dropdown on the right side.
Steps To Reproduce
https://www.loom.com/share/4b1b131253784b1f9dec875d8bf827f4
Public Sample App
No response
Environment
Release
Issue video log
No response
Version
Cloud

internal tracking: https://www.notion.so/appsmith/Test-party-New-IDE-457ce3d37cbc44c08f4a8b877de2f984?p=ba5c0e79ed224a61ad8265c29f6b05d9&pm=s

Solved with IDE tabs Revamp

authors: btsgh hetunandu rohan-arthur


text:
[Feature] Mailto Action

Summary
It would be great to be able to use an mail dispatch "action" for forms etc. The option could be made dependent on whether the server has a mail configuration or not.
Something like:
{{
       mailto(<FromMail>, <toMail>, <Subject>, <Message> )
}}

// Used like:
{{
    mailto(Mail_From_Input.text, "receiver@example.com",  "Your Request", RICH_Input.text)
}}

Motivation
I want to build an input mask for our GitLab service desk using Appsmith.
Unfortunately, GitLab does not currently provide an API endpoint for the Service Desk feature, so I would like to use a form to simulate that a customer has sent an email. However, I can't send an e-mail using Appsmith. (At least I would not know how?).
Therefore I currently have to use the GitLab API for normal issues, which does not offer the features of a service-desk-issue.
Regardless of my problem, though, there are certainly some possible usage scenarios for the feature.
Additional Context

If it is not clear what I meant, I will be happy to answer any questions.

Hey @Pjirlip 👋  thank you for the issue contribution. The way we think about sending emails is by introducing an email service as a datasource and triggering the email through them. So if you have access to

Sendgrid
AWS SES
Twillio
Any other email service

You should be able to trigger their email API with these fields. We don't have this as part of appsmith as configuring a mail server on our end could lead to a large drop in domain authority from users abusing the feature. So we recommend integrating with a third-party service to accomplish this. I hope this helps and we will definitely introduce a plugin for communicating with these services in the future 😃

Hello Nikhil,
thank you for your quick reply!
I can understand that, but using an external provider does not prevent potential misuse. It just shifts the potential negative reputation due to the misuse.
Especially since in my example only internal mail traffic is used. In Appsmith my mail server is stored with mailbox appmsith@mydomain.com and should send to gitlab@mydomain.com for the use case. The mail never leaves the mail server. Usually you don't use filters for local mailboxes. Accordingly, no negative repuattion can occur. I think this applies to most use cases concerning internal tooling.
Of course, this should be used with caution when sending to external addresses. (Maybe the feature is better suited with a restriction to mailboxes of the deposited domain). But I don't think it's any less dangerous than using click-built forms that use APIs or execute database queries. 😄
Thanks a lot for all the work you put into Appsmith and for being so diligent.

Hey @Pjirlip ! It's been a while, but I'd like to circle back on this issue if it is still relevant to you. Appsmith now supports an SMTP plugin that might serve your use case. Do you think that's something you'd like to try out?

@Pjirlip there are a couple of ways you can trigger emails, either with the SMTP plugin, or even with Twilio if you like. Closing the issue now, please re-open if your requirement is not met.

authors: Nikhil-Nandagopal Pjirlip nidhi-nair rohan-arthur


text:
[Feature]PDF Viewer widget

Summary
We need an PDF Viewer widget for base64 data
Motivation
i give the user the possibility to upload attachments via filepicker. It gets stored into mongodb
Now the user usually don't want to download the PDF file. he wants to have a look at it in his browser.
Additional Context
i tried with an iframe widget (message: no proper URL) Also other widgets cannot work with the base64 pdf data so far.

Hey @RickSoftpaw realised that we do have a pdf viewer under development, thanks for the point regarding the IFrame widget, closing this issue in favour of: https://github.com/appsmithorg/appsmith/issues/3358

authors: RickSoftpaw rishabhsaxena


text:
fix: Fix special char handling in pre-define env

When starting the fat container with APPSMITH_MONGODB_URI variable set to a value that has query params, like mongodb+srv://user:pass@appsmith.abcde.mongodb.net/testdb?retryWrites=true&w=majority, then the fat container ignores it and goes ahead with using a local MongoDB server.
The problem is that we generated a pre-define.env file, that gets the following line (among many others like it):
APPSMITH_MONGODB_URI=mongodb+srv://user:pass@appsmith.abcde.mongodb.net/testdb?retryWrites=true&w=majority

This file is then sourced with . pre-define.env. When this runs, this file is evaluated like a shell script, and the shell's glob based file-name expansions take affect.
So for this line, the shell looks for a file that looks like mongodb+srv://user:pass@appsmith.abcde.mongodb.net/testdb?retryWrites=true&w=majority, where there's any letter in place of the ?, which is the glob definition of ? character. Since it doesn't find any such files, it will turn this line into just APPSMITH_MONGODB_URI=, indicating that there's no files to expand the glob pattern into.
Now since the APPSMITH_MONGODB_URI is set to empty value, the fat container will proceed to use it's local MongoDB just fine.
This can be avoided by wrapping the value in quotes. Like
APPSMITH_MONGODB_URI='mongodb+srv://user:pass@appsmith.abcde.mongodb.net/testdb?retryWrites=true&w=majority'

In this case, the shell will take the value verbatim and won't attempt to do glob expansion (or any potential variable expansion, if the value has any $ characters in it).
This PR adds a sed transformation to the generation of pre-define.env that:

Replaces ' in each line with '"'"', which is kind of an escaped single-quote, in a single-quoted string.
Adds a ' just after the = sign on each line.
Adds a ' at the end of each line.

Type of change

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

How Has This Been Tested?
> export z="a'b=d?x"
> printenv | sed "s/'/'\"'\"'/; s/=/='/; s/$/'/" | grep '^z'
z='a'"'"'b=d?x'

even though this PR is referened in Changelog of v1.6.15, the actual entrypoint.sh within v1.6.15 (https://github.com/appsmithorg/appsmith/blob/v1.6.15/deploy/docker/entrypoint.sh) does not seem to have the changes of this PR merged...

even though this PR is referened in Changelog of v1.6.15, the actual entrypoint.sh within v1.6.15 (https://github.com/appsmithorg/appsmith/blob/v1.6.15/deploy/docker/entrypoint.sh) does not seem to have the changes of this PR merged...

@sharat87 could you have a look, why this happend?

Hey @WernerDreierB, thanks for bringing my attention to this. This fix wasn't part of the last release, it was erroneously reported in the release notes. We are correcting the release notes now. Thanks!


text:
chore: Adding UI builders code paths to codeowners

Pull Request Template
Use this template to quickly create a well written pull request. Delete all quotes before creating the pull request.

Description
Adding UI builders code paths to codeowners.

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
[ ] 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


text:
fix: [Table widget] Date column with input format Unix timestamps should sort properly

PR fixes following issue(s)
Fixes https://github.com/appsmithorg/appsmith/issues/29800
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
[x] 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 tags="@tag.All"


text:
chore: IDE persistence

Description
Adds local persistence to IDE level features

IDE Tabs
IDE View mode (Split screen preference)

To achieve this, added a new option: persist in Focus Retention. This will persist any Focus state and restore it when requested for the first time.
PR fixes following issue(s)
Fixes #31135
Fixes #31025
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 tags="@tag.All"

/ok-to-test tags="@tag.All"

/ok-to-test tags="@tag.All"

/ok-to-test tags="@tag.All"

/ok-to-test tags="@tag.IDE, @tag.JS"

/ok-to-test tags="@tag.IDE, @tag.JS"

/ok-to-test tags="@tag.IDE, @tag.JS"


text:
Default app template for java-microprofile uses a WebSphere Liberty maven plugin

Describe the bug
WebSphere Liberty is the commercial version of Open Liberty and Appsody is an open-source project.
The problems range from optics all the way to potentially tainting the licensing terms for Appsody.
To Reproduce
Visual inspection of the pom.xml for the stack:
https://github.com/appsody/stacks/blob/17d8c9c5992637025efcbc6f22f3e9f8f591fb1c/incubator/java-microprofile/templates/default/pom.xml#L93
Expected behavior
The application template should use the Open Liberty plug in.
Actual behaviour
The application template should use the WebSphere Liberty plug in.
Environment Details (please complete the following information):
N/A
If applicable please specify:

CLI version: appsody 0.5.2
Stack you are using (including the version):
java-microprofile 0.2.21

Screenshots
N/A
Additional context
N/A

This is addressed by https://github.com/appsody/stacks/pull/514.
Along with that comes the idea of separating out the new function into a new openliberty stack, however.. so until we commit to that maybe it's fair to leave this issue open as-is.

Now that you mention an "openliberty stack", it reminds me that I was thinking about this just a couple of days ago.
All 3 Java stacks in Appsody are capable of Eclipse MicroProfile, so "java-microprofile" is misleading.
In hindsight, it should be the "java-openliberty" stack. MicroProfile is just one out of dozens of features that can be added to an open liberty server.

There are 3 Java stacks in Appsody (java-microprofile, java-spring-boot2, quarkus) capable of supporting Eclipse MicroProfile, so "java-microprofile" is a misleading name.

java-spring-boot2-liberty, yes. java-spring-boot2, no.

The naming issues regarding the java-microprofile won't be addressed in this stack.  However, the new java-openliberty has addressed some of the points here.

authors: ebullient nastacio scottkurz

repo: appsody/stacks


text:
viewDidLoad is called on application start, but should be called on tab activation

When UIStoryboard.initialViewController is UITabBarController, Typhoon runs through all childViewControllers and indirectly calls viewDidLoad in all these view controllers. It's happening on the start of an application, but default behaviour is to receive viewDidLoad on first tab activation.
Here is gist with code from Typhoon that cause such behaviour https://gist.github.com/anonymous/2b6573c18e711888ced8#file-gistfile1-m-L10-L16

@bugzhunter Yes, I know the reason of that error... It's because of PR: https://github.com/appsquickly/Typhoon/pull/350 - It tries to inject properties into UIViews, so views are mistakely loaded on viewController.view getter.
Have you ideas how to fix your problem and keep this PR working? If I'll come up with something good, this problem would be fixed asap

What drawbacks would have something like this? https://gist.github.com/bugzhunter/a6e0090469243c98b6f2#file-gistfile1-m-L14-L21

The problem here: if view is not loaded (which is always true at this stage), properties will not be injected into UIView, because this code called once, after UIVIewController created.
The correct solution is: try to inject properties into view, after it's loaded. (i.e. after viewDidLoad). Right now I think only option is to use method swizzling and replace viewDidLoad with another which will post notification or call notification block.

@bugzhunter, Fixed in 3.2.0

Kudos!

authors: alexgarbarev bugzhunter

repo: appsquickly/Typhoon


text:
Update storage and avatars services to include methods to get URLs

Issue: https://github.com/appwrite/sdk-for-flutter/issues/71
SDK Generator PR: https://github.com/appwrite/sdk-generator/pull/495

@lohanidamodar, you can focus on https://github.com/appwrite/sdk-for-flutter/pull/74/commits/6a75c0ce80b9876df622800889c7e5d874018884 to see the changes to the storage and avatars services.

Done This
appwrite:
    git:
      url: https://github.com/appwrite/sdk-for-flutter.git
      ref: feat-71-method-generate-file-url

getting this error
('../../../../../AppData/Local/Pub/Cache/git/sdk-for-flutter-9a770bc75904727660acc7b58a1a9344e8ae68dc/lib/src/client.dart').
[        ] Try correcting the name to the name of an existing getter, or defining a getter or field named 'endpoint'.
[        ]         final uri = Uri.parse(client.endpoint + path).replace(queryParameters: params);

We want to get the image Url its a must have feature.

We want to get the image Url its a must have feature.

@Shiba-Kar, this is a pretty stale branch and only a POC. I would suggest building the URL manually instead of trying to use this branch.

repo: appwrite/sdk-for-flutter


text:
update pglogical repo

Updating pglogical repo

I believe I also need to update the GPG Key - not particularly sure how to do that atm

repo: aptible/docker-postgresql

license: mit

license_source: bigquery


text:
[SDKv2] Add lookupOriginalAccountAddress query

Description

Add lookupOriginalAccountAddress query
Add e2e test

Note: I will add additional e2e to this method when rotate key is ready.
Test Plan

pnpm fmt & pnpm test
Related Links

Current dependencies on/for this PR:

main

PR #21   👈

This comment was auto-generated by Graphite.

Current dependencies on/for this PR:

main

PR [SDKv2] Add lookupOriginalAccountAddress query #21   👈

This comment was auto-generated by Graphite.

so they generate message even if there is no dependency PR? or im reading it wrong?

Current dependencies on/for this PR:

main

PR [SDKv2] Add lookupOriginalAccountAddress query #21   👈

This comment was auto-generated by Graphite.

so they generate message even if there is no dependency PR? or im reading it wrong?

@0xmaayan Yep Graphite does that, regardless of # of stacked PRs. I believe they drop everything into a stack.

Updated param naming
Fixed merging conflict

repo: aptos-labs/aptos-ts-sdk


text:
Update index.md

For a newbie following the tutorial

Mentioned steps suggest how to use aptos in a fresh project.
But the example code is directly from examples package, which doesn't work in fresh project and might lead to confusion.
While running the code it shows error missing import path. Typo in import statement.
The optional imports of package bcs and crypto not working in fresh projects. Since they are not required in the mentioned tutorial, removing them. Reference :
go get github.com/aptos-labs/aptos-go-sdk/crypto       go: module github.com/aptos-labs/aptos-go-sdk@upgrade found (v0.1.0), but does not contain package github.com/aptos-labs/aptos-go-sdk/crypto go get github.com/aptos-labs/aptos-go-sdk/bcs    go: module github.com/aptos-labs/aptos-go-sdk@upgrade found (v0.1.0), but does not contain package github.com/aptos-labs/aptos-go-sdk/bcs

Thanks for your contribution!

authors: gregnazario primeagen-rustaceans

repo: aptos-labs/developer-docs


text:
Added WakemeUp

Title and Issue number

Title : Wakemeup
Issue No. : 10
Code Stack : Html , CSS , Js
Close #10

Checklist:

[X] I have mentioned the issue number in my Pull Request.
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have created a helpful and easy to understand README.md
[X] I have updated the Index.html file for my contribution

@Mapur2 Please update the index.html.md file present in the repo


text:
feat: add sonatype-nexus-community/nancy

sonatype-nexus-community/nancy: A tool to check for vulnerabilities in your Golang dependencies, powered by Sonatype OSS Index
$ aqua g -i sonatype-nexus-community/nancy

How to confirm if this package works well
Reviewers aren't necessarily familiar with this package, so please describe how to confirm if this package works well.
Please confirm if this package works well yourself as much as possible.
Command and output
$ nancy help
nancy is a tool to check for vulnerabilities in your Golang dependencies,
powered by the 'Sonatype OSS Index', and as well, works with Nexus IQ Server, allowing you
a smooth experience as a Golang developer, using the best tools in the market!

Usage:
  nancy [flags]
  nancy [command]

Examples:
  Typical usage will pipe the output of 'go list -json -deps' to 'nancy':
  go list -json -deps ./... | nancy sleuth [flags]
  go list -json -deps ./... | nancy iq [flags]

  If using dep typical usage is as follows :
  nancy sleuth -p Gopkg.lock [flags]
  nancy iq -p Gopkg.lock [flags]

Available Commands:
  config      Setup credentials to use when connecting to services
  help        Help about any command
  iq          Check for vulnerabilities in your Golang dependencies using 'Sonatype's Nexus IQ IQServer'
  sleuth      Check for vulnerabilities in your Golang dependencies using Sonatype's OSS Index
  update      Check if there are any updates available

Flags:
  -v, -- count                 Set log level, multiple v's is more verbose
  -c, --clean-cache            Deletes local cache directory
  -d, --db-cache-path string   Specify an alternate path for caching responses from OSS Inde, example: /tmp
  -h, --help                   help for nancy
      --loud                   indicate output should include non-vulnerable packages
  -p, --path string            Specify a path to a dep Gopkg.lock file for scanning
  -q, --quiet                  indicate output should contain only packages with vulnerabilities (default true)
      --skip-update-check      Skip the check for updates.
  -t, --token string           Specify OSS Index API token for request
  -u, --username string        Specify OSS Index username for request
  -V, --version                Get the version

Use "nancy [command] --help" for more information about a command.

Thank you always!

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

authors: CrystalMethod suzuki-shunsuke

repo: aquaproj/aqua-registry


text:
".... not writing as not part of the current PR" - what does this mean / how to have it include all .tf files in scan?

We have .tf files in various, nested subdirs and are seeing this error. The action is outputting nothing to the PR and seems to print this in the logs for every check.
For example:
No public access block so not restricting public buckets .... not writing as not part of the current PR
Bucket does not have a corresponding public access block. .... not writing as not part of the current PR

Using aquasecurity/tfsec-pr-commenter-action@v1.0.2

@richstokes - the action runs tfsec against he whole repo and then cross references the results from the tfsec against the Hunk changes in the commit of the PR. if there error is part of an active change then it writes the comment.
The message you're seeing suggests that tfsec has found an issue with the s3 bucket not having a corresponding public access block, but as the bucket isn't part of the PR its not going to include a comment

same issue for v1.0.5, for test I added new resource with error, tfsec reported them, but commenter skipped.

@owenrumney, can I configure the action to comment every alert, even if it isn't part of the PR?

@kmcarvalho - not at the moment, but this is something I could add - it would have to be a comment direct in the PR rather than against the commit file though so might lose its value

@njimenezotto  - I'm not sure - I see you're setting the working directory which might be causing an issue with the commenter matching against the commit paths. Can you run the action output for the tfsec-pr-commenter-action step?

Hello,
I would add an use case where it could be great to have a configuration to ask tfsec to publish a comment even if the change is not in the PR.
I am currently testing terraspace. Terraspace is a wrapper of terraform. It means that we will define some Terraform code wrapped with a Ruby layer. This allows to add some further functionalities, follow some Terraform good practices etc ..
When we launch Terraspace (during a github-action), the "real" Terraform code will be generated into a cache folder. Of course this cache folder is not pushed to the git repository.  Then I would launch tfsec on this cache folder to check that the generated code follow securities guidelines and write a comment in the pull request if it is not the case.
However, because the cache folder is not in the git repository, tfsec will never write a comment in the PR.
Sorry if my explanation is not clear enough.
Have a nice day

I have been playing around with debugging this bad boy locally and found out that it points to the function that determines ( hardcoded for us ) if the file being commented on is relevant.
https://github.com/owenrumney/go-github-pr-commenter/blob/8aed49544a3f1352d15b059e0113a06182ac3bef/commenter/commenter.go#L155-L170
There might be more the the whole setup than just this - but I decided to quickly write up my own action using tfsec with JQ and other commenting framework 😎  as at the end I never got this one to run for me

Hi @RafPe, good find! Would you mind sharing your action on the Marketplace? I'm running into the same issue and would like to try it out, at least until this is updated 😄

Hi,
Is there any news on this ticket?
I am using version 1.2.0 and the writing of comments in PR doesn't work, meaning I keep getting “not writing as not part of the current PR” message for all the security findings.
I have one PR with one commit and new resources created purposely to test the tool in this commit, in particular two s3 buckets without encryption.
When I compare changes in the PR I can clearly see the new S3 buckets resources defined for this only commit. But I still get the error.
I tried using parameters like working_dir for the action or adding the extra command  --force-all-dirs but still, I am getting the message “not writing as not part of the current PR”.

authors: RafPe clrung codingthecloud kmcarvalho laurentvasseurtekos owenrumney richstokes zotrix

repo: aquasecurity/tfsec-pr-commenter-action


text:
Use vulnerability database from local cache

Problem
I would like to run the trivy-operator in standalone mode in an air-gapped environment. For this we use our own trivy-image. It is regulary rebuild with an up-to-date vulnerability database in its local cache (TRIVY_CACHE_DIR).
We have two issues with our setup using the HELM-Chart:

we cant disable the InitContainer
the trivy container enforces arguments to download its database: --db-repository (https://github.com/aquasecurity/trivy-operator/blob/v0.14.0/pkg/plugins/trivy/plugin.go#L700)

Command
  InitContainer:
   Command:
      trivy
    Args:
      --cache-dir
      /tmp/trivy/.cache
      image
      --download-db-only
      --db-repository
      <private-registry-name>

2023-07-06T10:23:04.261Z  ^[[34mINFO^[[0m           DB Repository: <private-registry-name>
2023-07-06T10:23:04.261Z  ^[[34mINFO^[[0m           Downloading DB...
2023-07-06T10:23:04.519Z  ^[[31mFATAL^[[0m          init error: DB error: failed to download vulnerability DB: database download error: OCI repository error: 1 error occurred:
                          * GET https://<registry-url>/jwt/auth?scope=repository%3A<repository-name>%2Foci%2F<image-name>%3Apull&service=container_registry: DENIED: access forbidden

@yanehi sound reasonable you can raise a PR if you have time

Related https://github.com/eraser-dev/eraser/issues/888#issuecomment-1753407795

Hey @chen-keinan , could you please confirm our agreed approach here:

Update getPodSpecForStandaloneFSMode() and getPodSpecForStandaloneFSMode()

or

Create new receiver functions to cater offline vulnerability database use case

@zhcli in general look ok , feel free to raise a PR and I'll take a look at it in details

authors: chen-keinan yanehi zhcli

repo: aquasecurity/trivy-operator


text:
Butterworth filter constructor have no parameter for sample rate

All other filter design tool take sample rate as a parameter, why NWaves not care about sample rate?

Similar to MATLAB/sciPy, this library expects normalized frequencies for input. You don't specify sample rate explicitly, but it's there:
double freq_in_Hz = 500;
double sample_rate = 8000;

double freq = freq_in_Hz / sample_rate;

var filter = new Filters.Butterworth.LowPassFilter(freq, order);

// i.e.:
// var filter = new Filters.Butterworth.LowPassFilter(500.0 / 8000, order);

In MATLAB, though, normalized frequencies are mapped onto range [0, 1] (in NWaves it's [0, 0.5]). Hence, the code above would be written as:
[b, a] = butter(order, 2*500/8000, 'low');

Thanks for the clear explanation.


text:
Throttling test

Some spammy(Infof's should be removed) tests which I created with higher messages per duration settings.
Previously there were greater divides between expected messages sent vs throtteld even the low/med tests were breaking. Things looking decent except in the absurd number of messages range.
I'm stil a little confused on how the new struct gets configured with the NewThrottling method, but this is a good step in the right direction.
11:22:53 throttle_test.go:55: [INFO]

Time taken Low: 191.384µs
11:22:53 throttle_test.go:70: [INFO]

Time taken Med: 370.076µs
11:22:53 throttle_test.go:84: [INFO]

Time taken Med5: 448.041µs
--- FAIL: TestThrottleMed5 (0.00s)
	assert.go:15: /home/josh/go/root/src/github.com/araddon/gou/throttle_test.go:85
	assert.go:36: !  Failure
	assert.go:38: !  - Should throttle 5000 of 10000 requests: 1000
11:22:53 throttle_test.go:98: [INFO]

Time taken Big: 5.221796ms
--- FAIL: TestThrottleBig (0.01s)
	assert.go:15: /home/josh/go/root/src/github.com/araddon/gou/throttle_test.go:99
	assert.go:36: !  Failure
	assert.go:38: !  - Should throttle 10000 of 20000 requests: 9948
11:22:53 throttle_test.go:112: [INFO]

Time taken: 49.735997ms
--- FAIL: TestThrottleBigger (0.05s)
	assert.go:15: /home/josh/go/root/src/github.com/araddon/gou/throttle_test.go:113
	assert.go:36: !  Failure
	assert.go:38: !  - Should throttle 100000 of 200000 requests: 95027
11:22:54 throttle_test.go:127: [INFO]

Time taken absurd: 498.38368ms
--- FAIL: TestThrottleAbsurd (0.50s)
	assert.go:15: /home/josh/go/root/src/github.com/araddon/gou/throttle_test.go:128
	assert.go:36: !  Failure
	assert.go:38: !  - Should throttle 1000000 of 2000000 requests, but seems to break limiting algorithm: 501618
11:22:54 uid_test.go:9: [DEBUG] 327230693338121729
11:22:54 uid_test.go:10: [DEBUG] 327230693338121730
FAIL
exit status 1
FAIL	github.com/araddon/gou	1.659s

perhaps i need to change api as it is confusing:

LogThrottle* is complete separate from Throttler which is just the underlying utility
LogThrottle always uses per hour so the limit passed in is "per hour"   https://github.com/araddon/gou/blob/master/log.go#L263

Also, most of those tests are indeterminate, as the duration the test runs causes the number of messages that are throttled to be relative to length of test.

authors: Ropes araddon

repo: araddon/gou


text:
Updated react boilerplate for use with buidler

Fix https://github.com/aragon/aragon-cli/issues/1259
Changes
Also makes the boilerplate as vanilla as possible, removing things that may be overkill, like:

linting
coverage

And some things that are not yet supported by the Buidler plugin:

templates
publishing

To test

Just check out the "buidler" branch in aragon-react-boilerplate (https://github.com/aragon/aragon-react-boilerplate/tree/buidler),
npm i,
then npm start,
optionally npm test.

Note 1: Since the plugin doesn't yet provide Aragon snapshot data, aragen must be started manually. You can do so by installing aragon-cli globally and running aragon devchain start.
Note 2: If the client in the browser doesn't show the app, you might need to wait a bit and refresh the tab manually. This is a known issue to be addressed in the plugin.

It seems a bit odd the tests would require the devchain (or a snapshot) to be running too; unit tests shouldn't need to do any publishing or etc.
Now if the user wanted to do integration tests of an entire organization, we might want to provide some snapshots with some contracts pre-deployed.

Yes agreed. I'm thinking a lot about just manually building an placeholder apm for development of apps. Definitely the simplest and fastest solution.

I'll be closing this PR without merging, and instead moving the contents to aragon/aragon-buidler-boilerplate, so that we are backwards compatible with aragon-react-boilerplate. Later on we can decide to deprecate some boilerplates.

repo: aragon/aragon-react-boilerplate


text:
Support dts to replica databases/groups

What this PR does:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 40.35%. Comparing base (a27c47b) to head (faad14e).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #834      +/-   ##
==========================================
+ Coverage   40.20%   40.35%   +0.14%
==========================================
  Files         265      265
  Lines       26708    26769      +61
==========================================
+ Hits        10738    10802      +64
+ Misses      14823    14820       -3
  Partials     1147     1147

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter csynineyang

repo: arana-db/arana


text:
Fix content-type for JS APIs

Scope & Purpose
Fix response content-type

[x] Bug-Fix for devel-branch (i.e. no need for backports?)
[x] The behavior change can be verified via automatic tests

Testing & Verification
This change is already covered by existing tests, such as the http_server suite
http://jenkins01.arangodb.biz:8080/job/arangodb-matrix-pr/6692/

http://jenkins01.arangodb.biz:8080/job/arangodb-matrix-pr/6695/

repo: arangodb/arangodb


text:
Safeguards against using V8 when JavaScript is turned off

Scope & Purpose
This PR adds safeguards against using V8 internally in environments that have JavaScript turned off via the --javascript.enabled false option.
The PR also moves a bit of V8 context initialization code from the Scheduler and the DatabaseFeature into the V8DealerFeature, so it is now all in one place.
Finally it adds a new metrics that tracks the total time it took to create V8 contexts.

[x] :hankey: Bugfix
[ ] :pizza: New feature
[x] :hammer: Refactoring
[ ] :book: CHANGELOG entry made
[x] :muscle: The behavior in this PR was manually tested
[x] :computer: The behavior change can be verified via automatic tests

Backports:

[x] Backports required for: 3.7

Testing & Verification

[ ] This change is a trivial rework / code cleanup without any test coverage.
[x] This change is already covered by existing tests, such as shell_client, shell_server, http_server.
[x] This PR adds tests that were used to verify all changes:

[x] Added new integration tests (i.e. in server_parameters)

http://172.16.10.101:8080/view/PR/job/arangodb-matrix-pr/11960/

http://172.16.10.101:8080/view/PR/job/arangodb-matrix-pr/11973/

Tests blue


text:
Added EnterpriseGraph Dump & Restore Tests

3.10 Backport of: https://github.com/arangodb/arangodb/pull/16797
EE Companion: https://github.com/arangodb/enterprise/pull/1033

https://jenkins01.arangodb.biz/job/arangodb-matrix-pr/24420/


text:
Index Background Creation Bug

Scope & Purpose
Do not skip documents that have been inserted, when removing in same transaction.
When indexes are created in background a temporary IndexBuilder index is inserted as placeholder for the actual index. This index records which documents are inserted and removed during index creation. However, we limited this recording to a single event per document per transaction.
If the same document is inserted and removed within the same transaction during an index background creation, the document will eventually show up in the index.
Furthermore, the comment "don't track documents more than once" is a bit misleading. Since we use the local document id to track documents, any such id will show up in insert at most once.

Should this be backported?

@maierlars
Should this be backported?

First I would wait a few weeks to see if this does not have any unintended side effects.
Additionally, you have write the same document twice in the same transaction. That is an unlikely use case.

authors: MBkkt maierlars


text:
Fix multiple links per collection issue (#6661)

Fix muliple links per collection issue (arangodb/release-3.4#48).

Fix comparison.

Added test

Fix suite name.

Address some edge cases.

Clear views on teadown in tests

Update aql-view-arangosearch-ddl-cluster.js

Update aql-view-arangosearch-ddl-noncluster.js

Fix jslint errors

Added some comments about the comparison.

Please note that for legal reasons we require you to sign the
Contributor Agreement
before we can accept your pull requests.

http://jenkins01.arangodb.biz:8080/view/PR/job/arangodb-matrix-pr/1368/


text:
TTL index methods in collection indexes

Hi, I'm unable to find method to create ttl-index for a given collection. Since, this feature is available from 3.5.0 of ArangoDB, I would like to know when we can expect it to be available as part of arangojs. Thanks.

It's already possible to do this using ensureIndex. The ensureXYZIndex helper methods (e.g. ensureSkiplist) are redundant and will likely be removed in an upcoming major version of arangojs.

This issue will be addressed by the upcoming major release.

authors: pluma ravihara

repo: arangodb/arangojs


text:
compressed .ply as output?

Hi Aras, as a fan of GSPLAT, I wanted to express my appreciation for the various works you have done on it. As an artist who works with game engines and WebXR, I was hoping to inquire about the possibility of a compressed .ply file output on this Unity project. I was wondering if it would be possible to have an option to output a compressed .ply file, which could then be used on other platforms also outside of Unity.
I hope it might help the spread and more creative recreation and artistic collage of multiple GSPLAT scenes for various platforms based on .ply.
Thank you so much, very keen to know your thoughts on it! thks!

so sorry if i am wrong, I just found EXPORT PLY from the Renderer Script, will try it :)))

What is "compressed PLY output"? (is this the same question as #88 or #86)

authors: aras-p qiangjiadong

repo: aras-p/UnityGaussianSplatting


text:
[Bug]: Module will not start. Error message: undry.js:753 LibWrapperPackageError: lib-wrapper. Error detected in module Simultaneous Combat System. It is likely this module has not been updated for FVTT Version 11 Stable.

Expected Behavior
I am expecting the module to load and the SCS screen to come up.
Current Behavior
Throws an error on load.
Steps to Reproduce

Always happens on World load if module is active.
If my other modules are loaded then SCS loads normally.

Context

Version
Current
Foundry VTT Version
11.315
Operating System
Windows
Browser / App
Chrome
Game System
Dnd5e 3.0.1
Modules Disabled

[ ] I can confirm that disabling all of my other modules doesn't fix this issue.

Although the module will load with all other modules disabled, it only shows the three buttons: Move, Attack, Spells. Clicking on the buttons causes nothing to happen. The console reads:

repo: arcanistzed/scs


text:
🛑 ARCaptcha API is down

In d2a1501, ARCaptcha API (https://api.arcaptcha.ir/arcaptcha/api/heartbeat) was down:

HTTP code: 200
Response time: 1101 ms

Resolved: ARCaptcha API is back up in dfcfed5.

repo: arcaptcha/ARCaptcha-monitoring


text:
Merge remote-tracking branch 'refs/remotes/origin/master' into i406-tabs

Added comments describing functions and citing the sources for the calculations. Moved hard-coded control temperatures to globalvars. Added my name to every function I wrote.

@martin-mosteiro this looks like no file was modified.

@JIMENOFONSECA Correct - my changes had mistakenly been done on a different branch. I have now corrected the commits that corresponded to this branch.
@gabriel-happle These are the changes I had discussed with you. Feel free to comment on whether these changes appropriately address the concerns you expressed.

@JIMENOFONSECA, @martin-mosteiro: I have added some changes to make the code run. I'd prefer not to break my flow today with trying to figure out if it does the proper stuff - maybe you guys can look into that?

merging as it was requested as priority.


text:
Input可以适配在PC移动端都是输入中文的过程中不触发onChange，建议加一个props实现

目前是有一个I
OS设备生效的props，能否这个props对所有设备都生效呢。
（我测试IOS设备也不生效，而且有bug）

当前提供了blockChangeWhenCompositing属性，用于在ios输入中文时不触发onChange。这个有问题的话，可以提供下复现环境。其他（如安卓）设备无法监听，因为仅当ios系统键盘在输入中文时，会将拼音先置入input中，并且提供compositionstart和compositionstart系统事件供监听。安卓键盘仅当确认中文字后才会置入input，在置入之前，前端都无法感知到input的变化，即使有机型会置入input，没有触发 composition 相关事件，也是无法区分是否正输入中文的。

repo: arco-design/arco-design-mobile


text:
list 组件到达底部时会触发两次reach-bottom方法

[ ] I'm sure this does not appear in the issue list of the repository

Basic Info

Package Name And Version: arco-design-pro-vue@2.7.0
Browser: chrome111.0.0.0

What is expected?
当list组件滑动到底部时，只触发一次reach-bottom
Steps to reproduce
当list组件滑动到底部时，就会触发两次reach-bottom，开发文档的案例也会出现这个问题

@L1nYong hi 组件问题可以提到组件库哈。3q

repo: arco-design/arco-design-pro-vue


text:
fix: update pageShowDates when mode changed

Types of changes

[ ] New feature
[x] Bug fix
[ ] Enhancement
[ ] Documentation change
[ ] Coding style change
[ ] Component style change
[ ] Refactoring
[ ] Test cases
[ ] Continuous integration
[ ] Typescript definition change
[ ] Breaking change
[ ] Others

Background and context

RangePicker在trigger打开的情况下切换mode，RangePicker的年份没有及时更新

https://codesandbox.io/s/sweet-sid-msnhzj?file=/demo.js
Solution

添加mode作为更新pageShowDates的依赖
How is the change tested?

无影响用例，直接单元测试
Changelog

Component
Changelog(CN)
Changelog(EN)
Related issues

DatePicker
修复 RangePicker 在弹出层打开的情况下切换 mode 年份不更新的 bug
Fix RangePicker switching mode year without updating when popup is turned on
#1570

Checklist:

[x] Test suite passes (npm run test)
[x] Provide changelog for relevant changes (e.g. bug fixes and new features) if applicable.
[x] Changes are submitted to the appropriate branch (e.g. features should be submitted to feature branch and others should be submitted to main branch)

Other information

抱歉 ❤，这个通过另外方式进行了修复

authors: NoAlligator yinkaihui

repo: arco-design/arco-design


text:
nord not on melpa or any other repository

I can't seem to find the nord theme on any of the listed repositories listed below.

Thanks for your notification 👍
It will be available as soon as melpa/melpa PR #4655 is mergeable also described in the backlog issue comment arcticicestudio/nord #6 posted yesterday.
One of the Melpa maintainers reviewed the package and created PR #21 to fix some format issues which I'll need to review and merge to make Nord Emacs available from MELPA as soon as possible.

The PR has been merged and nord-theme is now available from MELPA.

authors: arcticicestudio gregf

repo: arcticicestudio/nord-emacs


text:
Added e.ListN() and d.ListN()

Example usage:
// to encode / decode the following rust data type:
pub fixed_array: [u8; 3],

// decoding
d.ListN(3, u.U8( ));
// encoding
e.ListN(e.U8(100), e.U8(100), e.U8(200));

Hi Jannik! 2 questions here:

Is there a difference between e.Tuple and e.ListN?

Regarding d.ListN, do you have a real life example from your builder experience where it would have been useful to you?

I don't think it has any differences in comparison to e.Tuple. It is just syntactic sugar. The abi-type array64 would require to be written like "e.Tuple(e.U8(), ..., e.U8()) instead of the just e.ListN(64, e.U8())

I've dug through all the available example abis when writing a "abi to ts proxy generator", and this was one of the things I found analyzing them:
https://github.com/multiversx/mx-sdk-rs/blob/1a87af8ad27029355e5ebfb39fc784800277e8e3/contracts/examples/digital-cash/src/signature_operations.rs#L54C1-L54C76

For e.U8() you will need to pass the value, e.g. e.U8(10). So e.ListN(64, e.U8()), no? Because the values of the 64 u8 will need to be provided

The link you sent me is referring to that line:

signature: ManagedByteArray<Self::Api, ED25519_SIGNATURE_BYTE_LEN>,

Unsure what you are referring to?
And what would you think about an overload d.Tuple(d.U8(), 3) that matches pub fixed_array: [u8; 3]. Basically, if there are only 2 arguments, the first one is a decoder and the second one is a number, then we decode with 3 times a d.U8().
And we would need to handle correctly the typescript types. So a type test would need to be added. But that could be a great learning here and I could assist.

Unsure what you are referring to?

I was saying, that to use such construct right now, you would have to do a d.Tuple() with 64 parameters d.SomeThing() right now, which is not very convenient.
For decryption, d.Tuple(d.U8(), 64) would be cool.
For encryption, I'm not sure, if e.Tuple() allows you to pass an array of things right now. I'm curious how you code it right now, if you'd have to pass such signatures to a SC with the current state of the xsuite framework?
I know its a bit of an edge case, but its possible nevertheless, so just curious, if its convenient enough already.

I understand now what you meant!
For encoding, you would do:
const bytes = [0, 30, 28, 10, ...]; // arrow of bytes
e.Tuple(...bytes.map(b => e.U8(b)))

We could even simplify and allow to pass a list of encoders to e.Tuple and e.List, and hence the encoding would be:
e.Tuple(bytes.map(b => e.U8(b))

How does this sound? Do you think something would be preferable?
For decoding, you would do as mentioned:
d.Tuple(d.U8(), 64)

Sounds good?

authors: janniksam lcswillems

repo: arda-org/xSuite


text:
🛑 U3A Raspberry Pis is down

In 9e5aa3c, U3A Raspberry Pis (http://u3a.epizy.com/rpis) was down:

HTTP code: 0
Response time: 0 ms

Resolved: U3A Raspberry Pis is back up in 3a05d73.

repo: ardus-uk/upptime