XCode 14.2/Swift 5.7 memory corruption on Task creation when app is launched on iOS < 16.

Description
Task creation in some contexts can lead to corruption of the application's memory. Examples can be seen in the demo application code.
Steps to reproduce

Download demo application source code: https://github.com/mstyura/Swift-Task-Heap-Curruption-on-iOS-15-and-earlier.
Select scheme TaskCrasher - Release - libgmalloc - use with arm64 simulator;
Run demo app on arm64 iOS simulator with iOS 15.4;

Expected behavior
Application is not crashed.
Actual behavior
Demo app crashes with libgmalloc enabled. Address sanitizer unfortunately unable to catch the issue.

I've actually encountered problem on real production application on iOS device where app  is randomly crashed on memory access to address 0x100000000 + offset where offset is usually +0x10, +0x20 or -0x8 in application or system library code.
Also in real application libmalloc were capable to detect it was corrupted on some point, but it was unclear who was responsible for corruption.
Environment

Swift compiler version info

swift-driver version: 1.62.15 Apple Swift version 5.7.2 (swiftlang-<IP_ADDRESS>.5 clang-14<IP_ADDRESS>)
Target: arm64-apple-macosx13.0

Xcode version info

Xcode 14.2
Build version 14C18

Deployment target:
checked that issue happen on iOS 14 and iOS 13 and iOS 15 as deployment target.

Additional context:
An app that I observed crashing worked fine when built with XCode 13.4.1 and Swift 5.6, but experienced significant, random crashes with "bad access" errors on addresses like 0x100000020 when built with XCode 14.2 or XCode 14.1 and Swift 5.7. As a result, it's currently not feasible to target iOS versions lower than 16 and use Swift 5.7 with async functions and Tasks without encountering random crashes.
UPD: On demo application issue is only happen when compiled with -O (optimize for speed), but not when compiled with -Osize (optimize for size) or -Onone.

Hello @DougGregor and @rjmccall! Sorry for bothering you by directly mentioning here. Could you please take a look at the issue, maybe you will suggest how severe the actual problem is. Thanks a lot in advance, Yury!

CC: @mikeash

@mstyura Thanks a lot for the nice reproducer. I'm able to replicate the crash here. I'll see if I can figure out what's going on.

I uncommented just willCauseHeapCorruption1 to focus on a single thing. This creates a task and passes in the AsyncFunctionPointer $sxIeghHr_xs5Error_pIegHrzo_s8SendableRzs5NeverORs_r0_lTRyt_Tg5043$s11TaskCrasher19globalAsyncFunctionyyYaFyyI6YbcfU_Tf3npf_nTu (demangles to async function pointer to function signature specialization <Arg[1] = [Constant Propagated Function : closure #1 @Sendable () async -> () in TaskCrasher.globalAsyncFunction() async -> ()]> of generic specialization <()> of reabstraction thunk helper <A, B where A: Swift.Sendable, B == Swift.Never> from @escaping @callee_guaranteed @Sendable @async () -> (@out A) to @escaping @callee_guaranteed @async () -> (@out A, @error @owned Swift.Error)).
This async function pointer specifies an initial context size of 16. However, the runtime assumes that it will be able to store a AsyncContext struct, which is 32 bytes. Thus we run off the end.
In the current version of the concurrency runtime, AsyncContext is only 16 bytes. A Flags field was removed from it in commit aca744b21165a20655502b563a6fa54c2c83efdf. Looks like the compiler part of this change unconditionally shrinks the type, but the old runtime still writes to the now-missing Flags field:
  initialContext->Flags = AsyncContextKind::Ordinary;

I think this is usually harmless, as this field will usually extend into whatever else the task uses the initial context for. But if there is no other such use, we don't allocate enough memory, and this dead write turns into a memory smasher. The compiler probably needs to pad this value a bit when targeting older OSes. @rjmccall can you take a look?

I think this is usually harmless, as this field will usually extend into whatever else the task uses the initial context for

@mikeash  could you please elaborate on the reasons behind the safety of writing outside of "bounds"? I've observed that crashes do not occur when a lambda captures external variables, and I'm curious about how these variables are stored. I wonder if writing to the "Flags" field might potentially interfere with the data structures related to the context of the lambda capture. Thank you.

In the current version of the concurrency runtime, AsyncContext is only 16 bytes. A Flags field was removed from it in commit https://github.com/apple/swift/commit/aca744b21165a20655502b563a6fa54c2c83efdf. Looks like the compiler part of this change unconditionally shrinks the type, but the old runtime still writes to the now-missing Flags field.

I understand that it's a natural behavior for a compiler that was compiled with the AsyncContext definition without flags, but with a backward-compatible runtime that assumes the presence of flags. In light of this, perhaps it would be sensible to reintroduce the "flags" field in the form of a private and unusable field (aka placeholder), in order to preserve size assumptions and avoid any potential breakage.

When creating a task, the compiler generates an "initial context size" which tells the runtime how much extra space to allocate. This space is then used for various task-local stuff, like variables that persist across suspension points. The runtime also puts an AsyncContext at the start of this area. The way it's supposed to look is:
AsyncContext             Task-local whatnot
+--------+--------------+-------------------+
| Parent | ResumeParent | ...other stuff... |
+--------+--------------+-------------------+

That's on newer concurrency runtimes, after the commit I linked above. On older concurrency runtimes, it's supposed to look like this:
AsyncContext                     Task-local whatnot
+--------+--------------+-------+-------------------+
| Parent | ResumeParent | Flags | ...other stuff... |
+--------+--------------+-------+-------------------+

However, with a new compiler that thinks AsyncContext is always smaller, it actually looks like this when running on an older runtime:
AsyncContext             Task-local whatnot
+--------+--------------+-------+
| Parent | ResumeParent | Flags |
+--------+--------------+-------+-----------+
                        | ...other stuff... |
                        +-------------------+

The Flags field overlaps with what follows, which is, forgive the use of technical jargon, Bad.
It looks like this is usually harmless, as the runtime sets Flags and then it's never used again. This happens before any other stuff is written, so that space will be reused and everything works fine. The problem occurs when there is no other stuff. Then you end up with this picture:
AsyncContext
+--------+--------------+-------+
| Parent | ResumeParent | Flags |
+--------+--------------+-------+
                        ^
                        |
                        end of the allocation is here!

If nothing else needs to be stored, the compiler asks the runtime to allocate just enough space for Parent and ResumeParent. That means that Flags points off the end of the allocation. If we're lucky (or running with Guard Malloc), Flags lies in an unmapped page and crashes. If we're unlucky, Flags lines up with some other random chunk of memory, and smashes whatever happens to be there.
I don't think we need to go so far as to reintroduce Flags, but we do need to ensure that the compiler reserves enough space for it in the allocation when targeting older OSes.

Yes, I think setting a minimum size is probably the way to go.

Hello @rjmccall! Sorry for bothering you. I've downloaded XCode 14.3 beta1 with swiftc of version swiftlang-<IP_ADDRESS>.11 clang-14<IP_ADDRESS>.60 (released on 16 Feb 2023 according to https://xcodereleases.com/) and tried demo app in it. It still crashes under libgmalloc. It might be due to the fact that 2 relevant MRs with fixes:

https://github.com/apple/swift/pull/63525 (merged on February 9)
https://github.com/apple/swift/pull/63531 (merged on February 14)

are just not include in the <IP_ADDRESS>.11 version of swiftc. Is there any way to know this for sure, I mean a way to map swiftc version to git commit? Thanks a lot in advance, Yury.

@mstyura You can try out the latest 5.8 snapshot to know for certain.

@AnthonyLatsis  the problems is that whenever I use custom toolchain with xcode, I'm getting the error when trying to launch app with debugger attached:
Details

Could not launch “TaskCrasher”
Domain: IDEDebugSessionErrorDomain
Code: 3
Failure Reason: LLDB provided no error string.
User Info: {
    DVTErrorCreationDateKey = "2023-02-21 15:14:32 +0000";
    DVTRadarComponentKey = 855031;
    IDERunOperationFailingWorker = DBGLLDBLauncher;
    RawUnderlyingErrorMessage = "LLDB provided no error string.";
}
--

Analytics Event: com.apple.dt.IDERunOperationWorkerFinished : {
    "device_model" = "iPhone14,6";
    "device_osBuild" = "15.4 (19E240)";
    "device_platform" = "com.apple.platform.iphonesimulator";
    "launchSession_schemeCommand" = Run;
    "launchSession_state" = 1;
    "launchSession_targetArch" = arm64;
    "operation_duration_ms" = 1;
    "operation_errorCode" = 3;
    "operation_errorDomain" = IDEDebugSessionErrorDomain;
    "operation_errorWorker" = DBGLLDBLauncher;
    "operation_name" = IDERunOperationWorkerGroup;
    "param_consoleMode" = 0;
    "param_debugger_attachToExtensions" = 0;
    "param_debugger_attachToXPC" = 0;
    "param_debugger_type" = 3;
    "param_destination_isProxy" = 0;
    "param_destination_platform" = "com.apple.platform.iphonesimulator";
    "param_diag_MainThreadChecker_stopOnIssue" = 0;
    "param_diag_MallocStackLogging_enableDuringAttach" = 0;
    "param_diag_MallocStackLogging_enableForXPC" = 1;
    "param_diag_allowLocationSimulation" = 0;
    "param_diag_checker_tpc_enable" = 0;
    "param_diag_gpu_frameCapture_enable" = 0;
    "param_diag_gpu_shaderValidation_enable" = 0;
    "param_diag_gpu_validation_enable" = 1;
    "param_diag_memoryGraphOnResourceException" = 0;
    "param_diag_queueDebugging_enable" = 0;
    "param_diag_runtimeProfile_generate" = 0;
    "param_diag_sanitizer_asan_enable" = 0;
    "param_diag_sanitizer_tsan_enable" = 0;
    "param_diag_sanitizer_tsan_stopOnIssue" = 0;
    "param_diag_sanitizer_ubsan_stopOnIssue" = 0;
    "param_diag_showNonLocalizedStrings" = 0;
    "param_diag_viewDebugging_enabled" = 0;
    "param_diag_viewDebugging_insertDylibOnLaunch" = 1;
    "param_install_style" = 0;
    "param_launcher_UID" = 2;
    "param_launcher_allowDeviceSensorReplayData" = 0;
    "param_launcher_kind" = 0;
    "param_launcher_style" = 1;
    "param_launcher_substyle" = 0;
    "param_runnable_appExtensionHostRunMode" = 0;
    "param_runnable_productType" = "com.apple.product-type.application";
    "param_testing_launchedForTesting" = 0;
    "param_testing_suppressSimulatorApp" = 0;
    "param_testing_usingCLI" = 0;
    "sdk_canonicalName" = "iphonesimulator16.4";
    "sdk_osVersion" = "16.4";
    "sdk_variant" = iphonesimulator;
}
--

System Information

macOS Version 13.1 (Build 22C65)
Xcode 14.3 (21801.3) (Build 14E5197f)
Timestamp: 2023-02-21T16:14:32+01:00

The workaround suggested here haven't helped.

Hm. cc @shahmishal

@JDevlieghere @adrian-prantl can you help look into this issue?

Hi @mstyura RawUnderlyingErrorMessage = "LLDB provided no error string."; usually means that either lldb-rpc-server was not involved in the failure, or lldb-rpc-server crashed.  When lldb-rpc-server crashes, you'll find a crash log in ~/Library/Logs/DiagnosticReports.  Do you see anything in that directory?

FWIW I tried to repo this with a slightly different Xcode and swift-5.8-DEVELOPMENT-SNAPSHOT-2023-02-20-a-osx.pkg, and did not reproduce the failure.

@jasonmolenda thanks for a hint. ~/Library/Logs/DiagnosticReports had a crash report:

Report
{"app_name":"lldb-rpc-server","timestamp":"2023-02-22 09:58:32.00 +0100","app_version":"","slice_uuid":"c8fe70f6-1e03-35ed-b1cf-be9b10758b7d","build_version":"","platform":1,"share_with_app_devs":0,"is_first_party":1,"bug_type":"309","os_version":"macOS 13.1 (22C65)","roots_installed":0,"incident_id":"D164F174-2269-4220-8742-5E2AB6ACF1FE","name":"lldb-rpc-server"}
{
  "uptime" : 26000,
  "procRole" : "Unspecified",
  "version" : 2,
  "userID" : 502,
  "deployVersion" : 210,
  "modelCode" : "MacBookPro18,1",
  "coalitionID" : 3056,
  "osVersion" : {
    "train" : "macOS 13.1",
    "build" : "22C65",
    "releaseType" : "User"
  },
  "captureTime" : "2023-02-22 09:58:32.1027 +0100",
  "incident" : "D164F174-2269-4220-8742-5E2AB6ACF1FE",
  "pid" : 68342,
  "translated" : false,
  "cpuType" : "ARM-64",
  "roots_installed" : 0,
  "bug_type" : "309",
  "procLaunch" : "2023-02-22 09:58:32.0185 +0100",
  "procStartAbsTime" :<PHONE_NUMBER>65,
  "procExitAbsTime" :<PHONE_NUMBER>22,
  "procName" : "lldb-rpc-server",
  "procPath" : "\/Applications\/Xcode_14.3_beta.app\/Contents\/SharedFrameworks\/LLDBRPC.framework\/Versions\/A\/Resources\/lldb-rpc-server",
  "parentProc" : "Xcode",
  "parentPid" : 68266,
  "coalitionName" : "com.apple.dt.Xcode",
  "crashReporterKey" : "0226B24A-284E-4EB7-74B1-5552D11514AE",
  "responsiblePid" : 68266,
  "responsibleProc" : "Xcode",
  "wakeTime" : 566,
  "sleepWakeUUID" : "071FE87B-9A5E-4E63-A86D-F8574E81268C",
  "sip" : "enabled",
  "exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"},
  "termination" : {"code":1,"flags":518,"namespace":"DYLD","indicator":"Library missing","details":["(terminated at launch; ignore backtrace)"],"reasons":["Library not loaded: @rpath\/Python3.framework\/Versions\/3.8\/Python3","Referenced from: <FE0FAA10-6242-3AC6-B7A2-8FD049E7988C> \/Library\/Developer\/Toolchains\/swift-5.8-DEVELOPMENT-SNAPSHOT-2023-02-20-a.xctoolchain\/System\/Library\/PrivateFrameworks\/LLDB.framework\/Versions\/A\/LLDB","Reason: tried: '\/Library\/Developer\/Toolchains\/swift-5.8-DEVELOPMENT-SNAPSHOT-2023-02-20-a.xctoolchain\/System\/Library\/PrivateFrameworks\/Python3.framework\/Versions\/3.8\/Python3' (no such file), '\/usr\/lib\/swift\/Python3.framework\/Versions\/3.8\/Python3' (no such file, not in dyld cache), '\/System\/Volumes\/Preboot\/Cryptexes\/OS\/usr\/lib\/swift\/Python3.framework\/Versions\/3.8\/Python3' (no such file), '\/Library\/Developer\/Toolchains\/swift-5.8-DEVELOPMENT-SNAPSHOT-2023-02-20-a.xctoolchain\/System\/Library\/PrivateFrameworks\/LLDB.framework\/Versions\/A\/..\/..\/..\/..\/..\/..\/..\/..\/Library\/Frameworks\/Python3.framework\/Versions\/3.8\/Python3' (no such file), '\/Library\/Developer\/Toolchains\/swift-5.8-DEVELOPMENT-SNAPSHOT-2023-02-20-a.xctoolchain\/System\/Library\/PrivateFra"]},
  "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":114,"task_for_pid":17},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
  "faultingThread" : 0,
  "threads" : [{"triggered":true,"id":824673,"threadState":{"x":[{"value":6},{"value":1},{"value":6126364592},{"value":216},{"value":6126363568},{"value":0},{"value":0},{"value":0},{"value":32},{"value":9},{"value":1},{"value":10},{"value":0},{"value":54},{"value":3},{"value":18446744073709551615},{"value":521},{"value":6909596484,"symbolLocation":392,"symbol":"__simple_bprintf"},{"value":0},{"value":0},{"value":6126363568},{"value":216},{"value":6126364592},{"value":1},{"value":6},{"value":8448488256,"symbolLocation":0,"symbol":"gProcessInfo"},{"value":6126367680},{"value":6126367272},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6910089728},"cpsr":{"value":4096},"fp":{"value":6126363520},"sp":{"value":6126363456},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6910046608,"matchesCrashFrame":1},"far":{"value":4343496704}},"frames":[{"imageOffset":463248,"symbol":"__abort_with_payload","symbolLocation":8,"imageIndex":0},{"imageOffset":506368,"symbol":"abort_with_payload_wrapper_internal","symbolLocation":104,"imageIndex":0},{"imageOffset":506420,"symbol":"abort_with_payload","symbolLocation":16,"imageIndex":0},{"imageOffset":41124,"symbol":"dyld4::halt(char const*)","symbolLocation":328,"imageIndex":0},{"imageOffset":28824,"symbol":"dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*)","symbolLocation":4204,"imageIndex":0},{"imageOffset":24004,"symbol":"start","symbolLocation":2404,"imageIndex":0}]}],
  "usedImages" : [
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" :<PHONE_NUMBER>,
    "size" : 568164,
    "uuid" : "487cfdeb-9b07-39bf-bfb9-970b61aea2d1",
    "path" : "\/usr\/lib\/dyld",
    "name" : "dyld"
  }
],
  "sharedCache" : {
  "base" :<PHONE_NUMBER>,
  "size" :<PHONE_NUMBER>,
  "uuid" : "00a1fbb6-43e1-3c11-8483-faf0db659249"
},
  "vmSummary" : "ReadOnly portion of Libraries: Total=991.7M resident=0K(0%) swapped_out_or_unallocated=991.7M(100%)\nWritable regions: Total=9248K written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=9248K(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nSTACK GUARD                       56.0M        1 \nStack                             8176K        1 \nVM_ALLOCATE                         16K        1 \n__AUTH                              46K       11 \n__AUTH_CONST                        70K       38 \n__DATA                            1311K       40 \n__DATA_CONST                      7964K       42 \n__DATA_DIRTY                        78K       22 \n__LINKEDIT                       863.0M        4 \n__OBJC_CONST                        11K        5 \n__OBJC_RO                         65.4M        1 \n__OBJC_RW                         1986K        1 \n__TEXT                           128.7M       44 \ndyld private memory                512K        2 \n===========                     =======  ======= \nTOTAL                              1.1G      213 \n",
  "legacyInfo" : {
  "threadTriggered" : {

  }
},
  "trialInfo" : {
  "rollouts" : [
    {
      "rolloutId" : "63582c5f8a53461413999550",
      "factorPackIds" : {

      },
      "deploymentId" : 240000002
    },
    {
      "rolloutId" : "60f8ddccefea4203d95cbeef",
      "factorPackIds" : {

      },
      "deploymentId" : 240000022
    }
  ],
  "experiments" : [

  ]
}
}

Basically swift toolchain has LLDB which attempts to load Python3.framework, but  toolchain is absent Python3.framework. Manually added symlink to XCodes Python3.framework to resolve issue: sudo ln -nfs /Applications/Xcode_14.2.app/Contents/Developer/Library/Frameworks/Python3.framework /Library/Developer/Toolchains/swift-5.8-DEVELOPMENT-SNAPSHOT-2023-02-20-a.xctoolchain/System/Library/PrivateFrameworks/Python3.framework. Now I can debug apps with custom swift toolchains. Thanks for a help!

As @jasonmolenda pointed out, Xcode and the Command Line Tools (CLT) are self contained and each contain a copy of the Python 3 framework, which allows us to have a relative RPATH from LLDB. There's (purposely) no Python 3 in the operating system so there's no relative RPATH that can guarantee you to find the Python framework from /Library/Developer/Toolchains. As a workaround, we have two absolute RPATHs: one for Xcode installed in /Applications/Xcode.app and one to the /Library/Developer/CommandLineTools.


integrate column reflows weird on smaller windows

When I shinked my window down to part of my screen, the Triggers/Inputs/Outputs reflowed weirdly

We have a new design for integrate that will help with this. Closing this issue as we don't want to fix the current layout.


Where is qemu-$to_arch-static binary files when container whose arch isn't equal to host's one is run?

Is this a bug report, feature (enhancement) request or question? (leave only one on its own line)
/kind question
Description:
I understand
the command docker run --rm --privileged multiarch/qemu-user-static --reset -p yes enables running the container whose arch isn't equal to host's one.
and binfmt_misc and qemu works for this,
But I could find qemu-$to_arch-static neither in host pc nor in container,
but the program in the container is executed through /usr/bin/qemu-$to_arch-static.
I felt it like a mystery...
Where is qemu-$to_arch-static binary files when container whose arch isn't equal to host's one is run?
Steps to reproduce the issue:

docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
docker run the image whose arch is not equal to host's one.
run ps auwx in the container run at step 2.
run ls /usr/bin

Describe the results you received:
Step3: COMMAND shows "/usr/bin/qemu-aarch64-static *"
Step4: ls' doesn't show qemu-*-static <- it's a mystery..
Environment:

Container application: Docker

Output of docker version, podman version or singularity version
$ docker version
Client: Docker Engine - Community
 Version:           20.10.17
 API version:       1.41
 Go version:        go1.17.11
 Git commit:        100c701
 Built:             Mon Jun  6 23:02:57 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.11
  Git commit:       a89b842
  Built:            Mon Jun  6 23:01:03 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.6
  GitCommit:        10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc:
  Version:          1.1.2
  GitCommit:        v1.1.2-0-ga916309
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Additional information optionally:

I found this question at stackoverflow,
this says qemu-$to_arch-static is in multiarch/qemu-user-static.
but multiarch/qemu-user-static container isn't running at that time.
Can we get files from container which isn't running?

I edited my 1st post according to issue template.

When you run docker run --rm --privileged multiarch/qemu-user-static --reset -p yes, it will register and LOAD those binaries.
The -p enables the persistence (see here in qemu repo) which enables the flag F of binfmt_misc. And you can get details of the flag F at kernel doc.
so the F mode opens the binary as soon as the emulation is installed and uses the opened
image to spawn the emulator, meaning it is always available once installed, regardless of how
the environment changes.

And the kernel source code here.
	if (e->flags & MISC_FMT_OPEN_FILE) {
		f = open_exec(e->interpreter);
		if (IS_ERR(f)) {
			pr_notice("register: failed to install interpreter file %s\n",
				 e->interpreter);
			kfree(e);
			return PTR_ERR(f);
		}
		e->interp_file = f;
	}

@zxdvd Thank you for replying me!
I'd read the documents you told  me.

I'm not familiar with kernel, so it may take a bit long time to read docs.

@zxdvd Excuse me, to be crarified, I have a question.

When you run docker run --rm --privileged multiarch/qemu-user-static --reset -p yes, it will register and LOAD those binaries.

Where are the binaries(=interpreters) loaded into?
I understand that
the interpreters are loaded into kernel memory for binfmt function and kernel is shared among host and containers,
so the bin files whose arch is not equal to host's one can be executed in containers.
Please correct me if I'm wrong.

@agrexgh I think you are right. When flag F enabled, the interpreters are opened and the returned file descriptor is recorded and binfmt_misc uses the file descriptor directly instead of finding the path and opening it.

Thank you, @zxdvd!
I understood well how to work!
So I close this issues.


Add support for nested if%hw

The following:
let%hw upd_curseq rsa rsb v =
  if%hw rsa.rs_vld land (lnot rsb.rs_vld) then
    0h
  else if%hw rsa.rs_vld land (lnot rsb.rs_vld) then
    1h

Throws:
Error: Uninterpreted extension 'hw'.

On the line with he second if%hw statement.

For some reason, I missed this issue -
let%hw foo = if%hw 1h then 2h else if%hw 0h then 7h else 0h;;

is ok, but
let%hw foo = if%hw 1h then 2h else if%hw 0h then 7h;;

is not.  That is to be expected - the 2nd if does not have an else which is required for the underlying mux2.  The error reported could be more expressive though...

Aha, yes, good catch. I'll look into that.


chore: migrate to @nuxt/test-utils alpha

Following the steps in https://github.com/nuxt/test-utils/issues/644, this PR migrates to the latest alpha of @nuxt/test-utils which includes nuxt-vitest.
It's primarily intended for testing any potential regressions prior to release.
(It looks like there are some.)

I finally managed to update the test dependencies and fix the tests. It was quite some work, but mostly because of workarounds/hacks that were required previously, which could now all be removed. Thanks a lot for your work on @nuxt/test-utils!


802.11-related fixes

I had to make these changes to be able to use gopacket to strip data payload from packets while retaining all 802.11 headers.
It looks like originally gopacket was suitable for my task until this commit: https://github.com/google/gopacket/commit/d23ebfbfc434b2f371699e7d59a30d096de2cde1
It would be good to know what goal that commit was trying to solve. Probably it is OK to use Dot11WEP instead of Dot11Data, but so far I do not understand how to propagate context from Dot11 to Dot11Data via Dot11DataQoSData.
I tested my changes on sniffed Wi-Fi packets - both encrypted (not only data, but and also management - see 802.11w) or not. Everything is OK if to stop iterating over layers at Dot11Data or at Radiotap if bad FCS encountered.

Pull request #436 which has been merged fixed these issues

Closing, because the issue was resolved.


Ship Homebrew auto-update support.

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you successfully run brew tests with your changes locally?

Roll this out to everyone (not just developers) and document the environment variables used for configuration.
Will give it a day or two to allow anyone who wants to test this to do so and for the dust to settle after the other auto-update PRs.
Fixes https://github.com/Homebrew/brew/issues/288.

:+1:

:fireworks: :tada: :confetti_ball: :balloon:


change max width

Unlimit the width from
https://github.com/holoviz/panel/blob/310309ed624cb1b65fefbfd28b3521a421585304/panel/chat/message.py#L182
Not sure if I should change the default of ChatMessage, or just do for Lumen AI default, or targeted for Lumen tables. The main reason why it was implemented is because of something like
https://www.freshconsulting.com/insights/blog/uiux-principle-46-text-box-width-should-help-users-read/

Suspect we might different max widths for different agents maybe?

Superseded by https://github.com/holoviz/lumen/pull/634


Lock Down Brakeman, upgrading to 3.1 is broken

v3.1.0 was released today and causes tests to fail :cry:

@Fryguy Please review

:+1: I'm good merging even before this goes "green"


Fixing tce registry

solving strcuture folder conflict

@EstebanFS We apologize for the delay.  Is this commit still required?  What problem are you trying to solve with this commit?


Tidy code to prepare for OSS

The intent is to open-source the source code used to execute the transformation - this task captures the need to make sure that the code is ready for such publication.  This includes adding license and any copyright information, and making sure that the code is documented and commented so as to be usable by developers other than the authors of the code.

Now open sourced


is server 6.0.0 - 403 occurred while using GET scim2/Users endpoint with scope internal_user_mgt_list

Location : https://is.docs.wso2.com/en/latest/develop/scim2-rest-apis/
Steps to Reproduce:
Get a access token using client_credentials grant with scope internal_user_mgt_list
Use it to call GET /Users, it returns following error message
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:Error"
],
"detail": "Operation is not permitted. You do not have permissions to make this request.",
"status": 403
}
Note : for all scim2 rest apis it returns same error message even with appropriate scope set. but it worked perfectly with basic auth

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Caddy2 add on custom binary

I have a custom binary (has route53dns tls).
How can I set this up so the addon uses a custom binary?
I see the yaml has a setting
  custom_binary_path: str?
is this a relative relative or absolute path in hassos?

Hi,
The path should be absolute, here an examples:
custom_binary_path: /share/caddy/caddy

The above example tries to find a caddy binary inside a "caddy" folder, inside the share folder.
Of course, any other accessible folder should work as well.
By the way, accessible are any folders below:

share
config
ssl

Hope that helps, otherwise let me know.

Further explanations can also be found in the documentation.
https://github.com/einschmidt/hassio-addons/blob/main/caddy-2/DOCS.md#updatesplugins

THANKS! I have that working perfectly using a Caddyfile
I did determine that addon only uses the Caddyfile adapter if using the filename Caddyfile.  If I want someting else then I guess I need to specifically set the commandline adapter switch (how to add commandline switches? via environment?)
SO Now I'm wondering about the
  caddy_upgrade: bool?
is that setting supposed to update a binary with particular plugin from here?
e.g.
https://caddyserver.com/download?package=github.com%2Fcaddy-dns%2Froute53
if so what setting holds the the url?  If not then this should be a new feature as caddy2 now makes it easy (again) to build/download a custom binary :).

If I want someting else then I guess I need to specifically set the commandline adapter switch (how to add commandline switches? via environment?)

Check the args option:
https://github.com/einschmidt/hassio-addons/blob/main/caddy-2/DOCS.md#option-args

caddy_upgrade: bool?
is that setting supposed to update a binary with particular plugin from here?

See here: https://github.com/einschmidt/hassio-addons/blob/main/caddy-2/DOCS.md#option-caddy_upgrade
A proper caddy_upgrade setting looks like the following:
caddy_upgrade: true

When set to true, the addon will update any binary upon launch, automatically, if necessary, including any plugins.

When set to true, the addon will update any binary upon launch, automatically, if necessary, including any plugins.

it also does this everytime the addon is started even if the installed Caddy is the correct current version.


Refined setup tool

Make a more refined setup too for creating new specs
Instead of seeing is files/dirs are missing, check them all, and if any are missing, run the setup/create tool.

What is really needed is instead of running check_dep everytime, it should only be part of a setup command....
There would need to be an initial setup, and an update concept, perhaps the same if at all possible


Removing orbit=true to TextIcons; removing spfont

so @ferrannp should we now deploy an new Maven artifact, since we remove spfont?


Cloud runner develop

Changes

...

Checklist

[x] Read the contribution guide and accept the code of conduct
[ ] Readme (updated or not needed)
[ ] Tests (added, updated or not needed)

Codecov Report

Merging #437 (4035d1a) into main (579daa9) will decrease coverage by 10.33%.
The diff coverage is 33.33%.

:exclamation: Current head 4035d1a differs from pull request most recent head 9999dcf. Consider uploading reports for the commit 9999dcf to get more accurate results

@@             Coverage Diff             @@
##             main     #437       +/-   ##
===========================================
- Coverage   52.52%   42.19%   -10.34%
===========================================
  Files          66       72        +6
  Lines        2056     2337      +281
  Branches      376      405       +29
===========================================
- Hits         1080      986       -94
- Misses        914     1349      +435
+ Partials       62        2       -60

Impacted Files
Coverage Δ

src/model/cloud-runner/error/cloud-runner-error.ts
44.44% <0.00%> (-5.56%)
:arrow_down:

.../model/cloud-runner/providers/aws/aws-job-stack.ts
10.00% <0.00%> (-0.21%)
:arrow_down:

.../aws/cloud-formations/task-definition-formation.ts
100.00% <ø> (ø)

src/model/cloud-runner/providers/k8s/index.ts
10.47% <0.00%> (-1.53%)
:arrow_down:

src/model/cloud-runner/providers/local/index.ts
16.66% <0.00%> (-83.34%)
:arrow_down:

src/model/cloud-runner/providers/test/index.ts
11.11% <0.00%> (-88.89%)
:arrow_down:

src/model/cloud-runner/remote-client/index.ts
20.31% <0.00%> (ø)

...cloud-runner/services/follow-log-stream-service.ts
18.51% <0.00%> (+0.66%)
:arrow_up:

...rc/model/cloud-runner/workflows/custom-workflow.ts
22.72% <0.00%> (-59.10%)
:arrow_down:

...loud-runner/workflows/workflow-composition-root.ts
45.45% <0.00%> (-41.22%)
:arrow_down:

... and 61 more

Be aware, there are a few redundant new files that are stubbing new behaviour and a couple of commented lines.
I'd prefer to keep these on this occasion as it will make the 1.0 release lighter and easier. And will include resolutions for those loose ends.


Support for Tags

Overview
Add support for Tags. NOTE: We do not have designs for a page in the UI to manage tags, so the user will be using something like select2 (see demo here and click the 'Multiple' tab), where the user can type in Tags while creating an Integration and press enter to save it.
Requirements:

A /tags endpoint to GET all tags. Should not need any other CRUD actions here, unless you want to knock them out ahead of time. Good in case users make a typo and have OCD. We don't want anyone having a conniption either.
A method to load tags automatically for Integrations as an associated model. I don't think we will ever need to load Integrations without Tags, but if you think it should be separated out for less overhead and more flexibility, feel free to do it as a query param like /integrations?tags=1. Of course, let me know so that I can update the request in the UI.
The UI avoid having to do a separate request for all tags (only if we need to for a dedicated Tags page, for instance) and then filtering through them, assigning them by ID to the proper Integration, etc. All of that should be done API-side.
A method to load tags when we request a single Integration with /integrations/:idWe can do this one of two ways (not sure how you are doing this atm):

/integrations/:id/tags
/integrations/:id?tags=1

The Tag should allow spaces, numbers, and maybe certain special characters (will leave that up to you guys to decide, but consider use cases like e2e or front-end).
The user should be able to POST a Tag when creating their Integration. You can either allow it as an array of strings or array of objects as part of the larger Integration object when we POST/PUT at the end of the creation work flow, or as a separate POST the moment they press Enter in the Tags input field (however you will not have the Integration ID it will be associated with yet as the Integration won't have been created; this may be trickier). I don't care either way.

Up for Discussion / Lower Priority
Possibly for post-Summit, but some things to consider:

A /tags/:id/integrations endpoint to GET all integrations associated with a particular Tag. This may be lower priority. Use case: the user clicks a Tag/label from an Integration Detail page and it will list all Integrations with that same tag (will not include Templates, or anything else with the same Tag). In the future, we can support /tags/:id/ to load everything with that Tag, or /tags/:id/templates once we begin to incorporate Templates.
Additional CRUD actions for the general /tags endpoint. I will leave it up to you to decide whether or not to allow anything other than GET here, because, as I stated earlier, we currently do not have a page to manage them, so any changes to tags will be done within the context of an Integration or Template.
Users won't be able to PUT or DELETE them yet (even from a specific Integration), but we can add the action in already if you are inclined to do so.

Relevant Designs
Will ask UXD as there will be minor changes in the UI. Also, they should appear in the Integration Detail Page (should also have metrics there), which we don't have a design for atm.
cc @jimmidyson @sjcox-rh @dongniwang

@kahboom Connections and Integrations can now be tagged using the tags field. The tags field support a list of strings. Tags are always set on the connection or integration. You can obtain a list of  tags that are currently in use using GET /api/v1/tags/, which will return a Alphabetically ordered list of tags. So you can simply start using tags on connections and integration without predefining a list of tags. I think this should take care of all the requirements.  Your widget may need to add a new tag to create a new tag that is not yet in the list.
Let's get started with this and we discuss the lower priority list if needed.

Looks great @KurtStam , thank you! Let's close this out and open up specific issues for tags if we need to later on. We can always reference this issue later.


Add new white/black alpha colors

https://www.figma.com/file/ojCcgC5Zd12eUSzq6V5m24/Foundations-Post?type=design&node-id=26-111&mode=design&t=89C4WHH0EIozKIWj-0
### Tasks
- [ ] Add new colors
- [ ] Fix TODO for radio and checkbox in https://github.com/swisspost/design-system/pull/2813/files

Changed priority to urgent as some components require those new colors.


fix: fixed issues in TPM attestation for ECC

Motivation:
fixed issues in TPM attestation for ECC: buffer position, reading x and y, parsing crv, compare curveId
Conformance:
You should have signed the Eclipse Contributor Agreement as explained in https://github.com/eclipse/vert.x/blob/master/CONTRIBUTING.md
Please also make sure you adhere to the code style guidelines: https://github.com/vert-x3/wiki/wiki/Vert.x-code-style-guidelines

@pmlopes please review.

@vietj could you review?

@vietj please review

thanks @podlesrafal can you backport to 4.x branch ?


Add recipe for emulating CustomLayout from V8 and older

@Legioth It works like a charm, until someone removes the CustomLayout with a component from a View or changes the view. This results in V20 always in (TypeError) : this.querySelector is not a function - do you have an idea how to fix that?

That's an interesting surprise that I reported as https://github.com/vaadin/flow/issues/11490. I don't remember seeing that when I created the original version, so I was either not observant enough or then this is a regression.
In either case, the client-side remove() won't be needed in case the whole layout is removed, so it should be safe to add a guard to the JS expression in the detach listener:
"this.querySelector && this.querySelector('[location=\"'+$0+'\"]').lastChild.remove()"

@Legioth Thanks for your update and investigation! I took a similar approach in the meantime but yours look way cleaner.


Add Score D to USA Low

No, this will add two properties inside the tiles called `"D_SCORE . You should update the frontend to read that property on the lower zoom level.

@esfoobar-usds
I might be missing something decoding the lower tiles from the map on the main branch results in the lower tiles still showing the E_SCORE?
{
          "type": "Feature",
          "properties": {
            "E_SCORE": 0.9339749925937375
          },
          "geometry": {
            "type": "Polygon",
            "coordinates": [ ... ]
           }
  }

I wonder if we need to invalidate the cache?

No, I haven't uploaded them yet. I'm stuck in a rounding issue. I'll let you know when this is up.

No, I haven't uploaded them yet. I'm stuck in a rounding issue. I'll let you know when this is up.

Ok cool! Thanks!

Good thing with this PR: size of tiles should be extremely smaller! :)


feature: Support choosing Kubernetes QoS class through the decorator

enables choosing the Kubernetes QoS class out of Guaranteed/Burstable/BestEffort through the decorator.

lgtm! can you verify airflow works as expected?


Add 'resources' to the hidden folders

The resources folder should be hidden.

Resolved.

I have the same issue. I added some folder names to the hidden files array and they are still visible.


Add vim logo

Name with link
https://github.com/vim/vim/blob/master/runtime/vimlogo.svg
Description
Link to the vector file, preferably from an official source

Hey @ryoppippi
Vim is already available.

OMG! Yeah I found it.Thanks


Create {1212}{Bartholdiliberty#0984}{43794}.txt

Remember to fill in your Flow address in the content next time.


Can you change the location of where models are generated when using amplify codegen models?

Which Category is your question related to?
Datastore, Amplify codegen models
Right now when I run amplify codegen models, the models are currently created in the src/models directory. Is there any way to change this?
I imagine that it would act similarly to how the normal codegen where the file location can be changed in the .graphqlconfig.yml

Hi @cmaycumber. Thank you for requesting this. We are tracking this feature here #55. Closing this in favor of that.

Not an expert on bash but this worked for me to move the models from "./models" to "./src/models"
"aws-amplify-generate-models-at-path": "amplify codegen model &&  files=$(find ./models -type f | wc -l) && if [ $files -eq 4 ]; then rm -r ./src/models && mv ./models ./src && rm -rf ./models; fi"
Since I run this command on my CI pipeline I also added the check to verify that the original folder has 4 files which suggests the schema creation worked

I found a SourceDir setting in amplify/.config/project-config.json... it was src, and when I changed it to my desired folder (app), then amplify codegen models put the models in app. Haven't tried setting SourceDir to . but that might work.

Any update here? Amplify should allow you to specify a root for all their generated files (including ui-components). I find it rather annoying that they have partially customized configurations. I already had a 'models' folder.

It's tracked here: https://github.com/aws-amplify/amplify-codegen/issues/55

This feature is now supported. You can specify an --output-dir when running amplify codegen models in order to specify where the files will be rendered. Marking this issue as closed.


Media storage and compression algorithms for signed content

Investigate how could we compresse signed content for Medical Events and what media storage should we use for this purpose

We should probably use CP1251 encoding to reduce signed content size

acceptance criteria:

[ ] ensure that chosen file storage will support the planned volumes

@lymychp
Original signed content size for the full package was 43 kb
The package consisted of:
encounter
5 conditions
10 observations
2 immunizations
3 allergy intolerances
Signed_conten size after compression - 9 kb
in case an average patient has 5 encounters per year there will be needed 45kb/patient
So, is it enough?

@IrinaRevutska  it is more than enough)


feat: port CategoryTheory.Category.KleisliCat

mathlib SHA: 70d50ecfd4900dd6d328da39ab7ebd516abe4025
Porting notes:

Unable to locate a lean4 equivalent to unfold_projs
Unsure if the nolint attribute should be kept or removed. #lint still complains about unused arguments in the definition of KleisliCat

Please fix the build.