text:
Rename DistributedActors -> DistributedCluster module

Resolves https://github.com/apple/swift-distributed-actors/issues/1043

11:01:49 Generating documentation for 'DistributedCluster'... Converting documentation... /code/Sources/DistributedCluster/Docs.docc/Clustering.md:77:3: warning: Topic reference 'ClusterControl/joined(node:within:)-2cla8' couldn't be resolved. No local documentation matches this reference. /code/Sources/DistributedCluster/Docs.docc/Clustering.md:78:3: warning: Topic reference 'ClusterControl/waitFor(::within:)-spiq' couldn't be resolved. No local documentation matches this reference. Conversion complete! (7.72s) Generated DocC archive at '/code/.build/plugins/Swift-DocC/outputs/DistributedCluster.doccarchive'

Fixing... those are so annoying that they're not properly stable :|

repo: apple/swift-distributed-actors


text:
Raspberry Pi Pico W's LED doesn't blink

Today I tried to run the Blinky example on my Raspberry Pico Pi W.
I sucefully builded the .uf2 file:

Installed Swift 6.0-dev Nightly
Cloned Repo
cd swift-embedded-examples/pico-blink
Changed the Toolchain:

export TOOLCHAINS=$(plutil -extract CFBundleIdentifier raw \
~/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/Info.plist)

compiled:

./build

but when i install the .uf2 file the led doesn't blink
Build Output:
# Determine file paths
REPOROOT=$(git rev-parse --show-toplevel)
git rev-parse --show-toplevel
++ git rev-parse --show-toplevel
+ REPOROOT=/Users/ilgrandeanonimo/swift-embedded-examples
TOOLSROOT=$REPOROOT/Tools
+ TOOLSROOT=/Users/ilgrandeanonimo/swift-embedded-examples/Tools

# Setup tools and build flags
SWIFT_EXEC=${SWIFT_EXEC:-`xcrun -f swift`}
xcrun -f swift
++ xcrun -f swift
+ SWIFT_EXEC=/Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/bin/swift
CLANG=${CLANG:-`xcrun -f clang`}
xcrun -f clang
++ xcrun -f clang
+ CLANG=/Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/bin/clang
SWIFT_FLAGS="-enable-experimental-feature Embedded -disable-stack-protector"
+ SWIFT_FLAGS='-enable-experimental-feature Embedded -disable-stack-protector'
CLANG_FLAGS="-D__MACH__ -ffreestanding -mcpu=cortex-m0plus -mthumb"
+ CLANG_FLAGS='-D__MACH__ -ffreestanding -mcpu=cortex-m0plus -mthumb'
LD_FLAGS="-static -Wl,-e,_reset -dead_strip -Wl,-no_zero_fill_sections -Wl,-segalign,4 -Wl,-segaddr,__RESET,0x20000000 -Wl,-segaddr,__VECTORS,0x20000100 -Wl,-seg1addr,0x20000200 -Wl,-pagezero_size,0"
+ LD_FLAGS='-static -Wl,-e,_reset -dead_strip -Wl,-no_zero_fill_sections -Wl,-segalign,4 -Wl,-segaddr,__RESET,0x20000000 -Wl,-segaddr,__VECTORS,0x20000100 -Wl,-seg1addr,0x20000200 -Wl,-pagezero_size,0'

XCODE_RESOURCE_DIR=`env TOOLCHAINS="" xcrun clang -print-resource-dir`
env TOOLCHAINS="" xcrun clang -print-resource-dir
++ env TOOLCHAINS= xcrun clang -print-resource-dir
+ XCODE_RESOURCE_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0
LD_FLAGS+=" $XCODE_RESOURCE_DIR/lib/darwin/macho_embedded/libclang_rt.soft_static.a"
+ LD_FLAGS+=' /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/macho_embedded/libclang_rt.soft_static.a'

SWIFT_BUILD_FLAGS="--triple armv6m-apple-none-macho --configuration release --verbose"
+ SWIFT_BUILD_FLAGS='--triple armv6m-apple-none-macho --configuration release --verbose'
for SWIFT_FLAG in $SWIFT_FLAGS; do
	SWIFT_BUILD_FLAGS+=" -Xswiftc $SWIFT_FLAG"
done
+ for SWIFT_FLAG in '$SWIFT_FLAGS'
+ SWIFT_BUILD_FLAGS+=' -Xswiftc -enable-experimental-feature'
+ for SWIFT_FLAG in '$SWIFT_FLAGS'
+ SWIFT_BUILD_FLAGS+=' -Xswiftc Embedded'
+ for SWIFT_FLAG in '$SWIFT_FLAGS'
+ SWIFT_BUILD_FLAGS+=' -Xswiftc -disable-stack-protector'

for CLANG_FLAG in $CLANG_FLAGS; do
	SWIFT_BUILD_FLAGS+=" -Xcc $CLANG_FLAG"
done
+ for CLANG_FLAG in '$CLANG_FLAGS'
+ SWIFT_BUILD_FLAGS+=' -Xcc -D__MACH__'
+ for CLANG_FLAG in '$CLANG_FLAGS'
+ SWIFT_BUILD_FLAGS+=' -Xcc -ffreestanding'
+ for CLANG_FLAG in '$CLANG_FLAGS'
+ SWIFT_BUILD_FLAGS+=' -Xcc -mcpu=cortex-m0plus'
+ for CLANG_FLAG in '$CLANG_FLAGS'
+ SWIFT_BUILD_FLAGS+=' -Xcc -mthumb'

PYTHON_EXEC=${PYTHON_EXEC:-`xcrun -f python3`}
xcrun -f python3
++ xcrun -f python3
+ PYTHON_EXEC=/Applications/Xcode.app/Contents/Developer/usr/bin/python3
MACHO2UF2=$TOOLSROOT/macho2uf2.py
+ MACHO2UF2=/Users/ilgrandeanonimo/swift-embedded-examples/Tools/macho2uf2.py

# Build with Swift package manager
$SWIFT_EXEC build $SWIFT_BUILD_FLAGS
+ /Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/bin/swift build --triple armv6m-apple-none-macho --configuration release --verbose -Xswiftc -enable-experimental-feature -Xswiftc Embedded -Xswiftc -disable-stack-protector -Xcc -D__MACH__ -Xcc -ffreestanding -Xcc -mcpu=cortex-m0plus -Xcc -mthumb
Planning build
Building for production...
Write auxiliary file /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/swift-version--4DD707390B2078BE.txt
/Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/bin/clang -target armv6m-apple-none-macho -O2 -DSWIFT_PACKAGE=1 -fblocks -I /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/Support/include --sysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -fPIC -g -D__MACH__ -ffreestanding -mcpu=cortex-m0plus -mthumb -MD -MT dependencies -MF /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Support.build/Support.c.d -c /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/Support/Support.c -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Support.build/Support.c.o
/Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/bin/clang -target armv6m-apple-none-macho -O2 -DSWIFT_PACKAGE=1 -fblocks -I /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/Support/include --sysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -fPIC -g -D__MACH__ -ffreestanding -mcpu=cortex-m0plus -mthumb -MD -MT dependencies -MF /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Support.build/crt0.S.d -c /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/Support/crt0.S -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Support.build/crt0.S.o
/Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/bin/swiftc -module-name RP2040 -emit-dependencies -emit-module -emit-module-path /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Modules/RP2040.swiftmodule -output-file-map /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/output-file-map.json -parse-as-library -whole-module-optimization -num-threads 8 -c @/Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/sources -I /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Modules -target armv6m-apple-none-macho -swift-version 5 -v -O -j8 -DSWIFT_PACKAGE -Xcc -fmodule-map-file=/Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Support.build/module.modulemap -Xcc -I -Xcc /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/Support/include -module-cache-path /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/ModuleCache -parseable-output -parse-as-library -color-diagnostics -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -I /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib -L /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib -g -enable-experimental-feature Embedded -disable-stack-protector -Xcc --sysroot -Xcc /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -Xcc -F -Xcc /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -Xcc -fPIC -Xcc -g -Xcc -D__MACH__ -Xcc -ffreestanding -Xcc -mcpu=cortex-m0plus -Xcc -mthumb -package-name pico_blink
warning: save unknown driver flag -disable-stack-protector as additional swift-frontend flag
Apple Swift version 6.0-dev (LLVM 7b8e6346027d2b1, Swift 763421cee31dc8f)
Target: armv6m-apple-none-macho
/Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/bin/swift-frontend -frontend -c /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/HAL/Digital.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/HAL/Pins.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/HAL/RP2040.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/HAL/Time.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/Clocks.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/IOBank.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/PLL.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/PPB.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/PadsBank.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/RP2040Hardware.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/Resets.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/SIO.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/Timer.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/Watchdog.swift /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/XOSC.swift -supplementary-output-file-map /var/folders/xc/87dyfbzn53g1n8qhr_6b0dkm0000gp/T/TemporaryDirectory.6M991A/supplementaryOutputs-1 -target armv6m-apple-none-macho -disable-objc-interop -I /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Modules -I /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -color-diagnostics -g -debug-info-format=dwarf -dwarf-version=4 -module-cache-path /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/ModuleCache -swift-version 5 -O -D SWIFT_PACKAGE -enable-experimental-feature Embedded -empty-abi-descriptor -resource-dir /Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/lib/swift -file-compilation-dir /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink -Xcc -fmodule-map-file=/Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Support.build/module.modulemap -Xcc -I -Xcc /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/Support/include -Xcc --sysroot -Xcc /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -Xcc -F -Xcc /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -Xcc -fPIC -Xcc -g -Xcc -D__MACH__ -Xcc -ffreestanding -Xcc -mcpu=cortex-m0plus -Xcc -mthumb -module-name RP2040 -package-name pico_blink -disable-stack-protector -plugin-path /Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/lib/swift/host/plugins -plugin-path /Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/local/lib/swift/host/plugins -enable-default-cmo -parse-as-library -num-threads 8 -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/Digital.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/Pins.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/RP2040.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/Time.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/Clocks.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/IOBank.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/PLL.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/PPB.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/PadsBank.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/RP2040Hardware.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/Resets.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/SIO.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/Timer.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/Watchdog.swift.o -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/RP2040.build/XOSC.swift.o
/Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/RP2040Hardware.swift:75:11: warning: initialization of immutable value 'fbdiv' was never used; consider replacing with assignment to '_' or removing it
 73 |       let referenceFrequency = UInt32(12000 * 1000)
 74 |
 75 |       let fbdiv = vcoFrequency / referenceFrequency
    |           `- warning: initialization of immutable value 'fbdiv' was never used; consider replacing with assignment to '_' or removing it
 76 |
 77 |       let pdiv = postDivisor1 << 16 | postDivisor2 << 12

/Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/RP2040Hardware.swift:77:11: warning: initialization of immutable value 'pdiv' was never used; consider replacing with assignment to '_' or removing it
 75 |       let fbdiv = vcoFrequency / referenceFrequency
 76 |
 77 |       let pdiv = postDivisor1 << 16 | postDivisor2 << 12
    |           `- warning: initialization of immutable value 'pdiv' was never used; consider replacing with assignment to '_' or removing it
 78 |
 79 |       let resetTarget: Resets.ResetValue = pll.unsafeAddress == pllUSB.unsafeAddress ? .pll_usb : .pll_sys

/Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/RP2040Hardware.swift:88:11: warning: initialization of immutable value 'usbClockKHz' was never used; consider replacing with assignment to '_' or removing it
 86 |     func initializeClocks() {
 87 |       let xoscKHz = UInt16(12000)
 88 |       let usbClockKHz = UInt16(48000)
    |           `- warning: initialization of immutable value 'usbClockKHz' was never used; consider replacing with assignment to '_' or removing it
 89 |       let systemClockKHz = UInt32(125000)
 90 |       let multiplier = UInt16(1) // this is technically hardware dependent (e.g. the adafruit feather has 64 here)

/Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/Sources/RP2040/Hardware/RP2040Hardware.swift:90:11: warning: initialization of immutable value 'multiplier' was never used; consider replacing with assignment to '_' or removing it
 88 |       let usbClockKHz = UInt16(48000)
 89 |       let systemClockKHz = UInt32(125000)
 90 |       let multiplier = UInt16(1) // this is technically hardware dependent (e.g. the adafruit feather has 64 here)
    |           `- warning: initialization of immutable value 'multiplier' was never used; consider replacing with assignment to '_' or removing it
 91 |       let KHz = UInt16(1000)
 92 |
Write auxiliary file /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Blinky.product/Objects.LinkFileList
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/libBlinky.a @/Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/Blinky.product/Objects.LinkFileList
Build complete! (3.01s)

# Get the output directory
BUILDROOT=$($SWIFT_EXEC build $SWIFT_BUILD_FLAGS --show-bin-path)
$SWIFT_EXEC build $SWIFT_BUILD_FLAGS --show-bin-path
++ /Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/bin/swift build --triple armv6m-apple-none-macho --configuration release --verbose -Xswiftc -enable-experimental-feature -Xswiftc Embedded -Xswiftc -disable-stack-protector -Xcc -D__MACH__ -Xcc -ffreestanding -Xcc -mcpu=cortex-m0plus -Xcc -mthumb --show-bin-path
+ BUILDROOT=/Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release

# Link
$CLANG .build/release/Support.build/{Support.c,crt0.S}.o .build/release/Blinky.build/*.o -target armv6m-apple-none-macho -o $BUILDROOT/blinky $LD_FLAGS
+ /Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/bin/clang .build/release/Support.build/Support.c.o .build/release/Support.build/crt0.S.o .build/release/Blinky.build/Blinky.swift.o -target armv6m-apple-none-macho -o /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/blinky -static -Wl,-e,_reset -dead_strip -Wl,-no_zero_fill_sections -Wl,-segalign,4 -Wl,-segaddr,__RESET,0x20000000 -Wl,-segaddr,__VECTORS,0x20000100 -Wl,-seg1addr,0x20000200 -Wl,-pagezero_size,0 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/macho_embedded/libclang_rt.soft_static.a
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/macho_embedded/libclang_rt.soft_static.a, building for free standing-armv6m but attempting to link with file built for macOS-armv7
ld: warning: ignoring file /Users/ilgrandeanonimo/Library/Developer/Toolchains/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-04-30-a.xctoolchain/usr/lib/clang/17/lib/darwin/macho_embedded/libclang_rt.soft_static.a, building for free standing-armv6m but attempting to link with file built for macOS-armv7

# Extract sections from executable into flashable binary
$PYTHON_EXEC $MACHO2UF2 $BUILDROOT/blinky $BUILDROOT/blinky.uf2 --base-address 0x20000000 --segments '__TEXT,__DATA,__VECTORS,__RESET'
+ /Applications/Xcode.app/Contents/Developer/usr/bin/python3 /Users/ilgrandeanonimo/swift-embedded-examples/Tools/macho2uf2.py /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/blinky /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/blinky.uf2 --base-address 0x20000000 --segments __TEXT,__DATA,__VECTORS,__RESET
Writing segment __RESET size 24 (0x24) at vmaddr 0x20000000
Writing gap of size 232 (0xe8) at vmaddr 0x20000018
Writing segment __VECTORS size 192 (0x192) at vmaddr 0x20000100
Writing gap of size 64 (0x40) at vmaddr 0x200001c0
Writing segment __TEXT size 4940 (0x4940) at vmaddr 0x20000200
Writing gap of size 20 (0x14) at vmaddr 0x2000154c
Writing segment __DATA size 2064 (0x2064) at vmaddr 0x20001560
Produced /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/blinky.bin with 7536 bytes
Produced /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/blinky.uf2 with total size 15360 (0x3c00) bytes, payload size 7536 (0x1d70) bytes

# Echo final binary path
ls -al $BUILDROOT/blinky.uf2
+ ls -al /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/blinky.uf2
-rw-r--r--@ 1 ilgrandeanonimo  staff  15360 14 Mag 14:08 /Users/ilgrandeanonimo/swift-embedded-examples/pico-blink/.build/armv6m-apple-none-macho/release/blinky.uf2

The pico-w does not have a GPIO pin enabled for the LED; instead it uses the wireless chip to extend the GPIOs - this would require some additional HAL code to interact with that chip.

You can use the https://github.com/apple/swift-embedded-examples/tree/main/pico-w-blink-sdk example to do that instead. That one is built to use the existing pico sdk and interface for the pico-w

I think @phausler's solution is correct, please reopen this issue with more details if the solution does not work for you.

source: gharchive/issue

authors: ilgrandeanonimo phausler rauhul

repo: apple/swift-embedded-examples

license_type: permissive

license_source: github-api


text:
Improve wrapping of parenthesized expressions.

Since paren exprs are just represented as one-element tuples, they
were getting the same kind of wrapping as tuples, with breaks inside
the parens. This doesn't look great, because these are different kinds
of expressions. Now, we keep the parens inseparable from the tokens
that they are adjacent to, which lets them wrap more traditionally,
and we increase the continuation indentation inside them.
This required some changes to the way we stack indentation for
variable initialization and assignment to make multiple parenthesized
expressions line up nicely. For example, whereas we used to do this:
x =
  foo
    + bar
    + baz

Now we do
x =
  foo
  + bar
  + baz

...so that if those terms are paren exprs and they wrap inside, they
still shift in and out nicely and line up well:
x =
  (foo
    + foo2)
  + (bar
    + bar2)
  + (baz
    + baz2)

We find the loss of the original extra level of indentation to be
acceptable because the subsequent lines still start with a spaced
operator or some other token (like a prefix dot) that indicates
that the line is unambiguously a continuation line.

cc @dylansturg

source: gharchive/pull-request

repo: apple/swift-format

license_source: bigquery


text:
Simulate ninja -t clean by removing the database.

There's a belief that it is quite hard (if not impossible) to make a correct -t clean simulation. The next best thing to at least avoid breaking scripts that request ninja -t clean is to remove the build database. That's what we do in this patch.
rdar://20224847

@swift-ci please smoke test

repo: apple/swift-llbuild


text:
Documentation on registry usage

rdar://107005076

@swift-ci please smoke test

@swift-ci smoke test macos

@swift-ci test windows

cc @@zkiraly

@swift-ci please smoke test

@swift-ci please test Windows platform

@swift-ci please test Windows platform

@swift-ci please test Windows platform

@swift-ci please smoke test macOS

authors: MaxDesiatov tomerd yim-lee

repo: apple/swift-package-manager


text:
Destinations: pass -Xfrontend -validate-tbd-against-ir=none

This fixes an issue with the Windows build introduced with the conversion of SwiftDestinationTool to AsyncParsableCommand, as reported at https://github.com/apple/swift-package-manager/pull/6361#issuecomment-1496129406

@swift-ci smoke test

@swift-ci smoke test

I think that this should no longer be needed given that apple/swift#64920 has been merged

authors: MaxDesiatov compnerd


text:
[PackageDescription] Restore the old product API

This API was removed when implementing the product proposal but is being
restored to keep compatibility with current Swift 3 packages. The new
API will be introduced in the PackageDescription4 module.

@swift-ci please test

@ddunbar @andreslp can either of you do a sanity check?

Approved for the 3.1 release branch.


text:
Allow to use UNKNOWN case instead of unrecognizedEnumValue

Now in JSONScanner error will be return if enum case in unknown.
Propose - add setting to JSONDecodingOptions (ex. ignoreUnknownEnumCases) to return .UNKNOWN case instead of error.
Xcode 10, Swift 4.2, SwiftProtobuf - 1.1.2

I don't think any other languages provide an option for that, and I'm not immediately sure it would be a good thing since changing the enum value like that could put the message in an odd state (depending on how the enum field relates to other fields).  Since proto3 syntax enums support unknown values, it seems like if you need to deal with unknowns, binary might be a better format to use than json?

It turns out that the behavior is different: in case of json representation of model we have an error, with binary representation - it's ok.
For example, our testers use json transport to validate server data. And we use different inits on SwiftProtobuf.Message for that:
extension SwiftProtobuf.Message {
    public init(data: Data, useJSON: Bool) throws {
        if useJSON {
            try self.init(jsonUTF8Data: data)
        } else {
            try self.init(serializedData: data)
        }
    }
}

It turns out that the behavior is different: in case of json representation of model we have an error, with binary representation - it's ok.

Right, in binary form, we have the raw value and so it can still be modeled.  If you decided to use JSON it can't handing unknown fields or enum values.  That's one of the major limitation of JSON.  If you want to better support your protos evolving with time, binary is the format to use.

Looks like C++ has picked up an option to use the raw values instead of the names when generating JSON (https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/util/json_util.h#L67-L69), so it might make sense to add that to allow the data to better flow thru JSON.  That seems safer that an option to ignore unknown json enum names (which I still can't find anything else supporting).

I remember implementing support for numeric enums in the decode side -- it's required by the conformance test.   Looks like it even supports unknown values:
https://github.com/apple/swift-protobuf/blob/a1b3a3a7d458f0a0ac0afb7e61baaac5675c8d63/Sources/SwiftProtobuf/JSONScanner.swift#L1284
So it should only require a little work on the encoder to expose this there.

I don't think we can implement the original request here since we don't have an .UNKNOWN case  for enums and I'm reluctant to add one.
It might be reasonable to have an option to ignore unknown string-encoded enums (that is, to simply drop them entirely) rather than throw an error.  I'm concerned about the implications for repeated enum fields, though.
Mostly, I think this raises a question about our error reporting.  A long time ago, I considered trying to implement detailed error codes so that failures would detail the field where the problem occurred:  E.g., .unknownEnumValue("msg.submsg.field1")

Got to go ahead and close this off with #800 added a way to do JSON generation that should handling new enum values slightly better if folks really want to try to use JSON (over binary) when this is a concern.  We can always revisit if other languages also consider an option on the parsing side, but for now we'll stick with it being an error since it isn't clear how well things would work and it would be silent to callers when things are dropped.

authors: geor-kasapidi tbkka thomasvl

repo: apple/swift-protobuf


text:
Add swift-html

Pull Request Description
This adds https://github.com/pointfreeco/swift-html.
Acceptance Criteria
To be accepted into the Swift source compatibility test suite, a project must:

[x] be an Xcode or swift package manager project
[x] support building on either Linux or macOS
[x] target Linux, macOS, or iOS/tvOS/watchOS device
[x] be contained in a publicly accessible git repository
[x] maintain a project branch that builds against Swift 4.0 and passes any unit tests
[x] have maintainers who will commit to resolve issues in a timely manner
[x] be compatible with the latest GM/Beta versions of Xcode and swiftpm
[x] add value not already included in the suite
[x] be licensed with one of the following permissive licenses:

BSD
MIT 👈
Apache License, version 2.0
Eclipse Public License
Mozilla Public License (MPL) 1.1
MPL 2.0
CDDL

[x] pass ./project_precommit_check script run (TBD?)

Ensure project meets all listed requirements before submitting a pull request.

@swift-ci test

This also looks to have passed, but the build has a whole failed because of failures in other projects. Those look to be resolved now, so this next round of testing should go through.

@swift-ci test

authors: clackary stephencelis

repo: apple/swift-source-compat-suite


text:
Model Syntax nodes as structs

While investigating performance problems with SwiftSyntax, in particular the SyntaxRewriter, we have noticed that a considerable time was spent dealing with existentials that result from the way we model the syntax hierarchy using protocols. In an effort to reduce this problem, I have restructured the entire syntax layout to eliminate protocols and be entirely struct-based. As this has some major implications to SwiftSyntax’s API, I’d like to get some feedback on whether we should use it or not.
API Change
The main idea of this PR is to model each syntax node as a struct and allow casting between those structs either through initializers or designated as(TargetType.self) casting methods.
Furthermore there exist protocols SyntaxProtocol, ExprSyntaxProtocol etc. to which all all corresponding syntax nodes conform. That way, additional methods can be added to all syntax nodes by conforming to the corresponding protocol.
There is an enum SyntaxEnum that can be retrieved from as Syntax node by calling asSyntaxEnum and allows exhaustive switching over all enum kinds.
Performance improvement
Performance measurements were done by running an empty SyntaxRewriter / SyntaxVisitor on a Swift file with ~5000 lines of code. The baseline is the current performance of SwiftSyntax before #157 was merged.
Highlights are a 10x performance increase in SytnaxRewriter performance. Performance of SyntaxVisitor is roughly the same right now but can be improved by 10% in #158 that models it as a class instead of a protocol.
Empty SyntaxRewriter

Before
After #157
After this PR

Debug
391.8ms
180.7ms (-54%)
129.7ms (-28%)

Release
114.5ms
60.8ms (-47%)
12.7ms(-79%%)

Empty SyntaxVisitor

Before
After this PR
After #158

Debug
92.9ms
112.1ms (+21%)
107.9ms (+16%)

Release
12.3ms
12.6ms (+3%)
10.9ms (-12%)

Empty SyntaxAnyVisitor

Before
After this PR
After #158

Debug
106.2ms
136.2ms (+28%)
86.6ms (-18%)

Release
24.8ms
15.5ms (-38%)
8.4ms (-66%)

API example
// ===============
// MARK: Protocols
// ===============

protocol SyntaxProtocol {
    /// This is the hook through which common functionality can be implemented
    /// in the protocol. See the sample implementation of children.
    var asSyntax: Syntax { get }
}
extension SyntaxProtocol {
    var children: SyntaxChildren {
        return SyntaxChildren(self.asSyntax)
    }
    var isPresent: Bool {
        return self.asSyntax.isPresent
    }
    // etc.
}

protocol ExprSyntaxProtocol {
    var asExprSyntax: ExprSyntax { get }
}
extension ExprSyntaxProtocol {}

// =============
// MARK: Structs
// =============

struct Syntax: SyntaxProtocol {
    // MARK: Casting functions

    var asExprSyntax: ExprSyntax?
    var asFunctionCallExprSyntax: FunctionCallExprSyntax?
    // etc.
}

struct ExprSyntax: ExprSyntaxProtocol, SyntaxProtocol {
    // MARK: Casting functions

    var asSyntax: Syntax
    var asFunctionCallExprSyntax: FunctionCallExprSyntax?
    // etc.
}

struct FunctionCallExprSyntax: ExprSyntaxProtocol, SyntaxProtocol {
    // MARK: Casting functions

    var asSyntax: Syntax
    var asExprSyntax: ExprSyntax
    // etc.
}

// ==========
// MARK: Enum
// ==========

enum SyntaxEnum {
    case functionCallExpr(FunctionCallExprSyntax)
    // And all other leaf types (i.e. no cases for base types like ExprSyntax)
}

extension Syntax {
    var asSyntaxEnum: SyntaxEnum
}

\cc @allevato

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 97a0cdf90bd71891d6e102f91666ed7d2848d8fc

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 6184fafbc13c8da7e3d337bd8cf56842c11429a2

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - 6f03210d134353e9a25ad9631e79ea0556519885

@allevato Thanks for the review. Sorry, I totally missed to update the code example. It’s updated now.

authors: ahoppen akyrtzi swift-ci

repo: apple/swift-syntax


text:
Deprecate SyntaxCollection.replacing(childAt:with:) in favor of a writable subscript

The writable subscript fits much better into the current API design of SwiftSyntax instead of the hand-written replacing function, especially if we deprecate all the other hand-written manipulation methods in https://github.com/apple/swift-syntax/pull/1879.

Can SyntaxCollection now be MutableCollection?

Can SyntaxCollection now be MutableCollection?

Good idea 👍🏽

@swift-ci Please test

@swift-ci Please test Windows

authors: ahoppen rintaro


text:
Add precondition that a token’s range returned by the Parser is in the source file

We have been hitting crashes in
let begin = utf8.index(utf8.startIndex, offsetBy: startOffset)

presumably because startOffset is outside of the UTF8View’s bounds. I still can’t explain how this happens.
To further narrow down the issue, I propose we add preconditions that validate the start and end location of the range. This way, we will be crashing in our own code, hopefully giving us more insight into why the crash is happening.
Whenever these preconditions are violated, we should already be crashing today.

@swift-ci Please test


text:
Represent each parameterized test function argument as a separate element in Test.Case.arguments

Represent each parameterized test function argument as a separate element in Test.Case.arguments, including tuple types which have been de-structured into discrete function parameters.
Motivation:
This is an enhancement meant to represent arguments of parameterized test functions in Test.Case instances in a more useful way, and facilitate progress towards allowing (re-)running specific argument(s) of such functions.
Modifications:

Introduce a struct Test.Case.Argument which represents one argument passed to one parameter of a parameterized test function. This includes each argument's associated Test.ParameterInfo.
Change the Test.Case.arguments property to be an array of the new struct type.
Enhance Test.Case.Generator to generate Test.Case instances using the new argument structure—including de-structuring tuples into their constituent elements when needed. It accomplishes this more efficiently now using some specialized generic overloads.
Remove Test.Case.arguments(pairedWith:) function, since it's no longer necessary given the arguments property already pairs these values.
Introduce a convenience utility for testing purposes only, which handles errors thrown in eventHandler closures.

Checklist:

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

@swift-ci please test

@swift-ci please test

@swift-ci please test

@swift-ci please test

repo: apple/swift-testing


text:
Compiler crash with generic protocols: "meet operation was not commutative"

Description
The Swift compiler crashes in LLVM using a combination of generics and protocols as illustrated below.
Steps to reproduce
Run this code using swift code.swift:
public protocol Derived<A, B> : Base where T == any Derived<A, B> {
    associatedtype A
    associatedtype B
}

public protocol Base {
    associatedtype T
}

Output:
Meet operation was not commutative:

LHS: [concrete: Derived<[Derived].A, [Derived].B>]
RHS: [concrete: Derived<[Derived:A], [Derived:B]>]
Abstract differences with LHS < RHS:
Abstract differences with RHS < LHS:
- [Derived].A (#0) -> [Derived:A]
Concrete differences with LHS < RHS:
Concrete differences with RHS < LHS:
Concrete conflicts:

LHS ∧ RHS: [concrete: Derived<[Derived:A], [Derived].B>]
RHS ∧ LHS: [concrete: Derived<[Derived:A], [Derived:B]>]
Stack dump:
0.      Program arguments: /Library/Developer/CommandLineTools/usr/bin/swift-frontend -frontend -interpret IMapCrashRepro.swift -Xllvm -aarch64-use-tbi -enable-objc-interop -sdk /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -color-diagnostics -target-sdk-version 13.1 -module-name IMapCrashRepro
1.      Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)
2.      Compiling with the current language version
3.      While evaluating request TypeCheckSourceFileRequest(source_file "IMapCrashRepro.swift")
4.      While type-checking 'Derived' (at IMapCrashRepro.swift:1:8)
5.      While evaluating request RequirementSignatureRequest(IMapCrashRepro.(file).Derived@IMapCrashRepro.swift:1:17)
6.      While evaluating request RequirementSignatureRequestRQM(IMapCrashRepro.(file).Derived@IMapCrashRepro.swift:1:17)
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  swift-frontend           0x0000000108f7b5b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  swift-frontend           0x0000000108f7a5b4 llvm::sys::RunSignalHandlers() + 112
2  swift-frontend           0x0000000108f7bc34 SignalHandler(int) + 344
3  libsystem_platform.dylib 0x00000001a5ca42a4 _sigtramp + 56
4  libsystem_pthread.dylib  0x00000001a5c75cec pthread_kill + 288
5  libsystem_c.dylib        0x00000001a5bae2c8 abort + 180
6  swift-frontend           0x00000001059527d4 (anonymous namespace)::ConcreteTypeMatcher::dump(llvm::raw_ostream&) const + 0
7  swift-frontend           0x000000010592142c swift::rewriting::PropertyMap::unifyConcreteTypes(swift::rewriting::Term, llvm::Optional<swift::rewriting::Symbol>&, llvm::SmallVectorImpl<std::__1::pair<swift::rewriting::Symbol, unsigned int> >&, swift::rewriting::Symbol, unsigned int) + 696
8  swift-frontend           0x000000010591df7c swift::rewriting::PropertyMap::buildPropertyMap() + 1452
9  swift-frontend           0x000000010592ddd0 swift::rewriting::RequirementMachine::computeCompletion(swift::rewriting::RewriteSystem::ValidityPolicy) + 236
10 swift-frontend           0x000000010592e8e8 swift::rewriting::RequirementMachine::initWithProtocolWrittenRequirements(llvm::ArrayRef<swift::ProtocolDecl const*>, llvm::DenseMap<swift::ProtocolDecl const*, llvm::SmallVector<swift::StructuralRequirement, 4u>, llvm::DenseMapInfo<swift::ProtocolDecl const*>, llvm::detail::DenseMapPair<swift::ProtocolDecl const*, llvm::SmallVector<swift::StructuralRequirement, 4u> > >) + 900
11 swift-frontend           0x000000010592f6ec swift::RequirementSignatureRequestRQM::evaluate(swift::Evaluator&, swift::ProtocolDecl*) const + 1960
12 swift-frontend           0x0000000105875db8 llvm::Expected<swift::RequirementSignatureRequestRQM::OutputType> swift::Evaluator::getResultCached<swift::RequirementSignatureRequestRQM, (void*)0>(swift::RequirementSignatureRequestRQM const&) + 1288
13 swift-frontend           0x0000000105862b54 swift::RequirementSignatureRequest::evaluate(swift::Evaluator&, swift::ProtocolDecl*) const + 376
14 swift-frontend           0x00000001057bb824 llvm::Expected<swift::RequirementSignatureRequest::OutputType> swift::Evaluator::getResultCached<swift::RequirementSignatureRequest, (void*)0>(swift::RequirementSignatureRequest const&) + 1040
15 swift-frontend           0x000000010575ee4c swift::ProtocolDecl::getRequirementSignature() const + 108
16 swift-frontend           0x0000000105353680 swift::ASTVisitor<(anonymous namespace)::DeclChecker, void, void, void, void, void, void>::visit(swift::Decl*) + 1728
17 swift-frontend           0x000000010534ff4c (anonymous namespace)::DeclChecker::visit(swift::Decl*) + 400
18 swift-frontend           0x000000010534fdb0 swift::TypeChecker::typeCheckDecl(swift::Decl*, bool) + 204
19 swift-frontend           0x0000000105419cb0 swift::TypeCheckSourceFileRequest::evaluate(swift::Evaluator&, swift::SourceFile*) const + 540
20 swift-frontend           0x000000010541c95c llvm::Expected<swift::TypeCheckSourceFileRequest::OutputType> swift::Evaluator::getResultUncached<swift::TypeCheckSourceFileRequest>(swift::TypeCheckSourceFileRequest const&) + 576
21 swift-frontend           0x0000000105419a40 swift::performTypeChecking(swift::SourceFile&) + 120
22 swift-frontend           0x000000010463aa60 bool llvm::function_ref<bool (swift::SourceFile&)>::callback_fn<swift::CompilerInstance::performSema()::$_6>(long, swift::SourceFile&) + 16
23 swift-frontend           0x00000001046351d4 swift::CompilerInstance::forEachFileToTypeCheck(llvm::function_ref<bool (swift::SourceFile&)>) + 288
24 swift-frontend           0x0000000104635078 swift::CompilerInstance::performSema() + 148
25 swift-frontend           0x00000001045c8180 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 4364
26 swift-frontend           0x0000000104569294 swift::mainEntry(int, char const**) + 3940
27 dyld                     0x00000001a594be50 start + 2544
zsh: abort      swift IMapCrashRepro.swift

Expected behavior
The code should compile, or generate an error if the code is not valid (I'm not well-versed enough in Swift to be sure).
Environment

Swift compiler version info: Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51), and with the latest trunk: swift-DEVELOPMENT-SNAPSHOT-2023-02-02-a
Xcode version info: Version 14.2 (14C18)
Deployment target: irrelevant

CC: @slavapestov

Simpler:
protocol Derived<A, B> where C == any Derived<Never, B> {
  associatedtype A
  associatedtype B

  associatedtype C
}

authors: AnthonyLatsis compnerd tristanlabelle

repo: apple/swift


text:
[SourceKit] Add local variables to structure (SR-5057)

This PR includes local variables (source.lang.swift.decl.var.local) to structures provided by SourceKit. This also makes variables declared in for and while statements available in the structure.
Resolves SR-5057.
This is super important for SwiftLint, as you can see on https://github.com/realm/SwiftLint/issues/136 and all duplicated issues. I'm not sure if there's a historical reason for this not be included until now.

Similar question for this: does it make sense to be emitting accessibility and setter accessibility for local vars? They don't properly have such.

Does it make sense to be emitting accessibility and setter accessibility for local vars? They don't properly have such, unless I'm mistaken.

I thought about this and I wasn't able to come up with a good answer. It looks like they'll always be private (which isn't quite right), but at the same time, checking if key.setter_accessibility is present is the only way to check whether it's a let or a var declaration.

Hmm, yes, that's useful information, but surely there's a design possible that doesn't require describing the non-existent accessibility level of a non-existent setter?

Hmm, yes, that's useful information, but surely there's a design possible that doesn't require describing the non-existent accessibility level of a non-existent setter?

I think I agree. What would be the best approach here? Leaving that for another PR?

I wouldn't have the ability to answer that, but I will ask--is it possible to suppress the accessibility output and to have two flavors of source.lang.swift.decl.var.local?

is it possible to suppress the accessibility output and to have two flavors of source.lang.swift.decl.var.local

Wouldn't that be actually more inconsistent? This would be the only variable kind to be split in two based on its mutability.
Some alternatives:

Keep the accessibility as private. Although not 100% accurate, at least it's consistent and convenient. It'd be just a matter of clients understanding this convention.
Introduce a new source.lang.swift.accessibility.local. This could also be a bit inconsistent, because it's not something you can specify with a keyword.
Introduce a new key.ismutable (or something like that) field that should be added to variables declarations, indicating whether it's a var or let.

Whatever key is used to indicate the difference between var and let, I feel pretty strongly it should not be accessibility, as this information simply has nothing to do with access levels.
This is why I suggested different flavors of [...]var.local. If it feels inconsistent, it ought to be possible to split every variable kind into two based on mutability: [...]var.global.constant, [...]var.global.variable, etc. ("variable" and "constant" being the official terminology used in TSPL).
However, another key such as key.valuebindingkind might be nice, too, and extensible when ownership features come into play.

cc @nkcsgexi

I'm thinking about removing the accessibility fields for local variables for now and leave the discussion for the (near) future.

Rebased omitting the accessibility for local variables.

ping @nkcsgexi?

@swift-ci please test

@swift-ci please smoke test

@shahmishal any idea why PR testing isn't responding?

@swift-ci please smoke test

@nkcsgexi @marcelofabri  Is it possible to close this PR and re-create the PR? We have seen issues with few PR's, to workaround this issue we need to just create the PR.

authors: marcelofabri nkcsgexi shahmishal xwu


text:
Excise "Accessibility" from the compiler

"Accessibility" has a different meaning for app developers, so we've already deliberately excised it from our diagnostics in favor of terms like "access control" and "access level". Do the same in the compiler now that we aren't constantly pulling things into the release branch.
(This isn't exactly important, but we might as well clean it up.)

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 9ac781eaf2ed91e9ecf676297d95bc9742e9f5a9

apple/swift-lldb#250
@swift-ci Please smoke test

+1! Thanks Jordan!

authors: gottesmm jrose-apple swift-ci


text:
Build the Swift runtime using the locally built clang complier (testing)

This is only a test pull request to check if the changes that I am making to the build system work on Linux (and in the CI system).  No need to review this commit yet :)

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test


text:
[AutoDiff] Checks for inout arguments in differentiable functions.

cc @rxwei

@rxwei I added a test but it doesn't seem to throw the expected error. Do you see something clearly wrong with the added check?

This is now fixed and the tests pass locally.

@rxwei let me know when the auto-diff changes are complete and I can go ahead with the inout support implementation.

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@rxwei could you please let me know what the next steps are and when I can start working on them?

authors: eaplatanios rxwei


text:
test: xfail Interpreter/dynamic_replacement_multifile while investigating CI failures

rdar://52073880

cc: @aschwaighofer


text:
[CMake][SourceKit] SwiftLang should depend on clang-tablegen-targets

SwiftLang relies on some clang headers that rely on clang tablegen targets.
cc @compnerd @gottesmm @Rostepher

@benlangmuir @harlanhaskins @akyrtzi Not sure exactly who to ping on this. But I know it is one of you.

@swift-ci please smoke test

We already depend on swifAST, which depends on clang-tablegen-targets.  Why wasn't that sufficient?

We already depend on swifAST, which depends on clang-tablegen-targets. Why wasn't that sufficient?

I'm not sure actually, but I definitely hit this as an issue. I'll dig into it more to find out if it was a problem with my setup.

We already depend on swifAST, which depends on clang-tablegen-targets. Why wasn't that sufficient?

@benlangmuir Okay, I've identified the issue. Although SourceKitSwiftLang links against swiftAST, the CMake targets don't have a dependency. That means that libSourceKitSwiftLang.dylib depends on libSwiftAST.dylib, but you can still compile the sources for libSourceKitSwiftLang.dylib without doing anything for swiftAST (and therefore without generating the needed clang headers).

I believe that @xiaobai's response has addressed @benlangmuir's comments.

authors: benlangmuir compnerd gottesmm xiaobai


text:
[AutoDiff] [stdlib] Add JVP for 'differentiableReduce(::)'.

Add a JVP for differentiableReduce(_:_:).

Can one of the admins verify this patch?

I accidentally deleted tensorflow branch, which closed this PR. That was not intentional, sorry!
It would be nice to protect tensorflow branch against deletion to prevent this from happening again.

This PR was effectively cherry-picked into https://github.com/apple/swift/pull/32840. Thanks @rxwei for the original implementation!

authors: dan-zheng futurejones rxwei


text:
SILCombine: fix a miscompile in the alloc_stack optimization which causes a use-after-free.

A "copy_addr [take] %src to [initialization] %alloc_stack" is replaced by a "destroy_addr %src" if the alloc_stack is otherwise dead.
This is okay as long as the "moved" object is kept alive otherwise.
This can break if a retain of %src is moved after the copy_addr. It cannot happen with OSSA.
So as soon as we have OSSA, we can remove the check again.
rdar://problem/59509229

@swift-ci test

@swift-ci benchmark

Performance: -O

Improvement
OLD
NEW
DELTA
RATIO

ObjectiveCBridgeFromNSArrayAnyObjectForced
5340
4920
-7.9%
1.09x (?)

Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

authors: eeckstein swift-ci


text:
Don't import C++ class members that are protected or private

Instead of mapping C++ access specifiers to Swift access levels, we simply skip importing private and protected members at all. They should never be used, so leaving them out removes clutter from the module interface.
We omit protected members in addition to private members because Swift structs can't inherit from C++ classes, so there's effectively no way to access them.

@swift-ci smoke test

I love it. My one comment is that the ClangImporter bit could use a comment (I thought your old commit had a nice one, but it’s been a bit).

I think you're probably just remembering my commit message -- but I agree that a comment would be useful.
I see the macOS build bot has failed anyway, so I'll add the comment (probably something along the lines of my commit message) along with the fix for the macOS build failure.

Sounds good.
By the by, Windows just always fails the first trigger after force pushes since it doesn’t yet have the same auto-rescheduling behavior of the other bots. It’s also not a hard gate yet, so...

Sounds good.
By the by, Windows just always fails the first trigger after force pushes since it doesn’t yet have the same auto-rescheduling behavior of the other bots. It’s also not a hard gate yet, so...

OK, thanks for the explanation!

@swift-ci Please smoke test

This seems to have caused a regression on Windows.  Could you please take a look?  (CC @codafi @gribozavr)

@shahmishal could you please look into the triggering issue?  This actually would have caught the regression (the previous run definitely identified the issue)

This was triggered and commit was updated - https://ci-external.swift.org/job/swift-PR-windows/826/

This seems to have caused a regression on Windows. Could you please take a look? (CC @CodaFi @gribozavr)

Sorry about the breakage. This is the relevant build bot, correct?

Right. These logs contain an example of the failure.  Enums are default to being backed by signed on windows, so the check lines for the dump need to have generalized matches, the test needs to be special cased for Windows, or an explicit type bound should be provided to force the importer’s hand.
Up to you.

I’ve got no idea why the headers are leaking C++ 17 code into the test, but that seems more pressing.

Right. These logs contain an example of the failure. Enums are default to being backed by signed on windows, so the check lines for the dump need to have generalized matches, the test needs to be special cased for Windows, or an explicit type bound should be provided to force the importer’s hand.
Up to you.

Thanks for explaining -- that had me scratching my head.
In the meantime, I see this PR is being reverted (and you've taken care of issues that occurred during the revert -- thanks!), so there's no rush here, correct?
I'm a bit confused by another of the failures (the one in confusables.swift) because it doesn't even use interop -- and I'm not changing anything outside of ClangImporter. Relevant snippet in the logs:
// expected-note @-1 {{required by referencing operator function '==' on 'BinaryInteger' where 'Self' = '(Int, Int)'}}

                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                       required by operator function '==' where 'Base' = '(Int, Int)'

Any ideas why that might have happened?

I’ve got no idea why the headers are leaking C++ 17 code into the test, but that seems more pressing.

Can you explain? I'm not sure exactly what you're referring to?
This isn't the issue related to PathCch.h though? That also seems like a fundamental issue to solve. What I think is happening is that this module is marked as "extern c" in the module map, so is being imported in C mode, but in -enable-cxx-interop mode, the __cplusplus is still being defined, so Clang is rightly complaining about conflicts between the const and non-const overloads of the functions. Does that sound plausible? I'll take a closer look at what's going on there.

That said, I'm confused why my test would be pulling in PathCch.h in the first place... but it seems like a problem that needs fixing in any case.

Having thought about the PathCch.h issue some more, I've realized my earlier comment didn't make a lot of sense.
PathCch.h is a header that contains its own extern "C" block (conditioned by an #if __cplusplus) for the C API that it exports and then provides additional C++-only APIs (again conditioned by an #if __cplusplus).
Because the entire WinSDK module is marked with the [extern_c] attribute, the whole of PathCch.h (which is contained in a submodule of the WinSDK module) is effectively wrapped in an extern "C" block. Of course, this doesn't work -- the C++-only APIs can't be placed in an extern "C" block because then they won't be name-mangled, and they'll conflict with any C APIs of the same name.
I think the right solution is to remove the [extern_c] attribute from the main WinSDK module and apply it only to those submodules that don't have extern "C" blocks in their headers already. I'll prepare a PR that does this.

https://github.com/apple/swift/pull/30527 for the PathCch.h issue -- pretty sure this is the right fix.

authors: CodaFi compnerd gribozavr martinboehme shahmishal


text:
Windows Build: Add notes for multi-line commands when using PowerShell

On Windows, we have two shells:

Command Prompt
PowerShell

The use of PowerShell is increasing. Since all the commands of this file is written in Command Prompt, we need to add a note for whose who do not know this difference.

I'm not opposed to the change, but would like to understand how that confusion comes about as Microsoft does not provide a x64 PowerShell Developer Command Prompt AFAIK (or at least did not when I last installed VS).  Has that changed since?

@compnerd Thanks for your question!
If my understanding is correct, users are likely to user PowerShell by default so there would be confusion. According to this documentation,

Windows PowerShell comes installed by default in every Windows, starting with Windows 7 SP1 and Windows Server 2008 R2 SP1.

In addition, in popular terminal apps such as Windows Terminal, PowerShell should be the default one.
(I am not working on this as an employer and my primary working machine is MacBook. Just thinking of this while I was trying to compile Swift on my personal computer)

@imWildCat even better :) I think that having clear instructions to enable others to easily work on the project is important.
Your clarification relates more towards a justification for using PowerShell.  I'm not really tied to cmd or PowerShell.  However, the thing is, the changes to build with PowerShell here are going to be insufficient.  The commands that are listed further along are dependent on the handling of variables in CMD as well as the default environment variables setup by VsDevEnv, which gives you CMD.
Is there a way to get a x64 Developer PowerShell?

@compnerd You're right. I did a bit research and cannot find a good way to use VsDevEnv in PowerShell.
Moreover, mklink commands also need to be replaced with PowerShell alternatives.
Given this fact, I am closing this PR now.

authors: compnerd imWildCat


text:
Canonicalize single value forwarding insts that only have debug_value and destroy_value uses.

E.x.:
  %1 = unchecked_ref_cast %0
  destroy_value %1
->
  destroy_value %0

I am doing this only in non-Raw SIL to ensure that I do not disturb the
mandatory passes.

@swift-ci smoke test

A non-ossa version of this is in SILCombine. I realized that instead of doing it in SILCombine, I can just do it here (and slim down my SILCombine patch). Its a pretty simple canonicalization so I think it makes sense.

@swift-ci benchmark

I think simplifyDeadCast also handles this case

Performance: -O
Code size: -O
Performance: -Osize

Improvement
OLD
NEW
DELTA
RATIO

FlattenListLoop
1579
1042
-34.0%
1.52x (?)

Code size: -Osize
Performance: -Onone

Improvement
OLD
NEW
DELTA
RATIO

ObjectiveCBridgeStubNSDateRefAccess
3885
3567
-8.2%
1.09x (?)

DataAppendArray
4200
3900
-7.1%
1.08x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: 6-Core Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

@meg-gupta it handles some of these cases, but only release_value. I decided to do it here in a more general way for OSSA.

@swift-ci test windows platform

authors: gottesmm meg-gupta swift-ci


text:
BatchModeBalancer: Jobs assigned to BatchPartitions using weight-hints

BatchMode today assigns a Job to a BatchPartition without paying attention to the complexity of the Job, i.e, some Jobs take longer time to compile than others. This often leads to imbalance among Batch executions as some batches may complete execution earlier than others. Furthermore, it leads to increased build times for BatchMode. BatchSeed may alleviate this problem but is random in nature. This PR proposes BatchModeBalancer where the developer supplies weights for jobs and then the driver assigns jobs to batches using these weight hints. The core idea during assignment is that the next job is assigned to a BatchPartition with the lowest total current weight. This should ensure that Batches have roughly equal weights after assignment. In terms of determining the weights, developers are free to use simple "LOCs" or use more complex approaches such as profile time of "Primary-File" execution.
We have compared BatchModeBalancer vs. BatchMode on a 2019 MacBook Pro.
Compilation_mode | num_threads | time_in_sec
WMO | 8 | 5.889000
BatchMode |  8 | 2.989000
BatchMode_Balancer |  8 | 2.719000
WMO | 10 | 5.871000
BatchMode | 10  | 2.652000
BatchMode_Balancer | 10 | 2.360000

I regret to say that committing code into the legacy driver is not a productive avenue. Would it be possible to port this to the new swift driver?

@CodaFi is right. But I have deeper reservations about this idea. How is the user supposed to determine the weights? What percentage of time reduction are you looking at? If it's only about 10% I can't help but wonder if it's worth the added complexity.￼￼ Have you considered automating￼ the weights with feedback? What about a hill climbing approach?
I'm sorry, but I'm pretty skeptical about manually determined weights.￼

@davidungar Just adding a bit more context around why 10-15% matters for iOS developers. At Uber, we have a large Swift codebase (please see our  blog around code size optimization to get a sense of why they are large: https://eng.uber.com/how-uber-deals-with-large-ios-app-size/). Frequent iOS developer surveys have suggested "local build-times" as the top pain-point. We are not only improving our internal tools & module structures but also taking a hard look at the compiler to uncover inefficiencies within the compiler.
Re. automating weight computation, I strongly believe that any sophisticated weight computation technique should reside outside of the core compiler codebase (that includes hill-climbing strategies etc.). Ideally, BatchMode should embed a work-stealing like runtime to address the imbalance between Jobs, but that would be stretch. BatchModeBalancer design is a middle-ground which lets developers feed their own weight computation strategies to the compiler and at the same time eliminates imbalances as best as it can. Please keep in mind that you can use PrimaryFile execution time using a previous run as weights to get near-optimal balancing.
Re. 10-15% and why not more:  10-15% uses a simple lines-of-code in a file  as weights which I believe is fairly easy to feed to the compiler. As I mentioned earlier, it is definitely possible to use sophisticated weights such as profiled execution time per file (using PrimaryFile mode), which we have seen to yield higher gains.

@rajbarik Very fair points. Let me reconsider out loud:

@davidungar Just adding a bit more context around why 10-15% matters to iOS developers. At Uber, we have a large Swift codebase (please see our blog around code size optimization to get a sense of why they are large: https://eng.uber.com/how-uber-deals-with-large-ios-app-size/). Frequent iOS developer surveys have suggested "local build-times" as the topmost pain-point. We are not only improving our internal tools & module structures etc. but also taking a hard look at the compiler to uncover inefficiencies within the compiler.

Yes, I am not unaware. Since joining Apple, I've worked on reducing incremental build times, and if you follow my PRs (as well as @CodaFi 's) you may get a sense of where we are trying to go. I hope that batch mode is helping. The Swift Driver project is particularly exciting. (https://github.com/apple/swift-driver)

Re. automating weight computation, I strongly believe that any sophisticated weight computation technique should reside outside of the core compiler codebase (that includes hill-climbing strategies etc.).

Very interesting, and I'd like to hear more about why.

Ideally, BatchMode should embed a work-stealing like runtime to address the imbalance between Jobs, but that would be a stretch.

Yes, absolutely.

BatchModeBalancer design is a middle-ground which lets developers feed their own weights to the compiler and at the same time eliminate imbalances. Please keep in mind that you can use PrimaryFile execution times using a previous run as weights to get near-optimal balancing among batches.

Well, but then wouldn't you want the compiler to just do that? The driver knows those times. Why not have the driver perform the feedback on the weights?

Re. 10-15% and why not more: 10-15% uses a simple lines-of-code in a file as weights which I believe is fairly easy to feed to the compiler. As I mentioned earlier, it is definitely possible to use sophisticated weights such as profiled execution time per file (using PrimaryFile mode [Do you mean "batch mode" or just one primary file per frontend job?]), which we have seen to yield higher gains. Within the compiler, we could also augment file size as the default weight, if we absolutely have to.

I have also just reread your changes and @CodaFi 's comments.  Looks like about 350 lines of code. Let me try to sum up with I'm thinking/feeling:

Yes, compile times must be a real issue, for you to do this PR. I'm so sorry.

Weights are an interesting idea, but why not add a more general batch-strategy hook to the compiler?

The right answer, we both agree, would be work-stealing. I'm wondering if the effort to do these weights and to maintain this code--e.g. how do you test it?--means that the cost/benefit ratio wouldn't be better to just do the work-stealing? (I have a feeling it wouldn't be hugely difficult. There's a place in the frontend where it gets the next primary file out of a collection. That could be turned into a query back to the driver.)

As @CodaFi wrote, this driver isn't really where you want to be working. The new driver (in Swift) would be a much more rewarding place to invest in.

That said, I feel for you and I'll change my review from changes required to comments made. I really can't approve of these changes--sorry!--but I won't block them. I hope you might reconsider the notion of adding this facility to this driver.

Re. automating weight computation, I strongly believe that any sophisticated weight computation technique should reside outside of the core compiler codebase (that includes hill-climbing strategies etc.).

Very interesting, and I'd like to hear more about why.

Primarily due to profitability, i.e., the cost of computing weights should outweigh the benefit we can get.

BatchModeBalancer design is a middle-ground which lets developers feed their own weights to the compiler and at the same time eliminate imbalances. Please keep in mind that you can use PrimaryFile execution times using a previous run as weights to get near-optimal balancing among batches.

Well, but then wouldn't you want the compiler to just do that? The driver knows those times. Why not have the driver perform the feedback on the weights?

I had thought about this too. I was thinking along the lines of sharing/uploading the aggregated weight files in cloud.

The right answer, we both agree, would be work-stealing. I'm wondering if the effort to do these weights and to maintain this code--e.g. how do you test it?--means that the cost/benefit ratio wouldn't be better to just do the work-stealing? (I have a feeling it wouldn't be hugely difficult. There's a place in the frontend where it gets the next primary file out of a collection. That could be turned into a query back to the driver.)

Are you aware of work-stealing implementations (in Swift) readily available?

As @CodaFi wrote, this driver isn't really where you want to be working. The new driver (in Swift) would be a much more rewarding place to invest in.

Can you share some timeline for this new driver?

That said, I feel for you and I'll change my review from changes required to comments made. I really can't approve of these changes--sorry!--but I won't block them. I hope you might reconsider the notion of adding this facility to this driver.

No worries, it was a tiny PR anyways!

Can you share some timeline for this new driver?

We cannot speak to release timelines. However, it is irrelevant when we ship, as we are ceasing work on the legacy driver to focus our efforts on the new one. This will need to land in the new driver at some point.

authors: CodaFi davidungar rajbarik


text:
[Sema] Fix crash when retrieving typeContextInfo for a partially bound generic type

In the following test case, we are crashing while building the generic signature of someGenericFunc, potentially invoked on model in line 11.
struct MyBinding<BindingOuter> {
  func someGenericFunc<BindingInner>(x: BindingInner) {}
}

struct MyTextField<TextFieldOuter> {
  init<TextFieldInner>(text: MyBinding<TextFieldInner>) {}
}

struct EncodedView {
    func foo(model: MyBinding<String>) {
        let _ = MyTextField<String>(text: model)
    }
}

Because we know that model has type MyBinding<TextFieldInner>, we substitute the BindingOuter generic parameter by TextFieldInner. Thus, someGenericFunc has the signature <TextFieldInner /* substitutes BindingOuter */, BindingInner>. TextFieldInner and BindingOuter both have depth = 1, index = 0. Thus the verification in GenericSignatureBuilder is failing.
After discussion with @slavapestov, the root issue appears to be that we shouldn’t be calling subst on a GenericFunctionType at all. Instead we should be using substGenericArgs which doesn’t attempt to rebuild a generic signature, but instead builds a non-generic function type.

We slightly regress in code completion results by showing two collidingGeneric twice in the following case.
protocol P1 {
  func collidingGeneric<T>(x: T)
}
protocol P2 {
  func collidingGeneric<T>(x: T)
}
class C : P1, P2 {
  #^COMPLETE^#
}

Previously, we were representing the type of collidingGeneric by a generic function type with generic param T that doesn’t have any restrictions. Since we are now using substGenericArgs instead of subst, we receive a non-generic function type that represents T as an archetype. And since that archetype is different for the two function signatures, we show the result twice in code completion.
One could also argue that showing the result twice is intended (or at least acceptable) behaviour since, the two protocol may name their generic params differently. E.g. in
protocol P1 {
  func collidingGeneric<S>(x: S)
}
protocol P2 {
  func collidingGeneric<T>(x: T)
}
class C : P1, P2 {
  #^COMPLETE^#
}

we might be expected to show the following two results
func collidingGeneric<S>(x: S)
func collidingGeneric<T>(x: T)

Resolves rdar://76711477 [SR-14495]

@swift-ci Please test

@swift-ci Please test


text:
Fix OSSA Outliner for scoped guaranteed values

While outlining, the new uses of scoped guaranteed values maybe beyond the lifetime ends. For this reason use the new api makeGuaranteedValueAvailable which is built on top of OwnershipLifetimeExtender to create new guaranteed values that are correctly scoped and use as arg for the outlined call.
This ends up creating copy_value + borrow_value that are additional to the non-OSSA outliner. When CopyPropagation with lexical lifetimes are enabled, these additional instructions will be removed to get performance parity with the non-OSSA Outliner.

@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - 2b0e101a789fb0118e522a038602660943702afe

@swift-ci test Linux platform

@swift-ci test and merge

@swift-ci clean test linux platform

@swift-ci clean test linux platform

@swift-ci test macOS platform

@swift-ci test windows platform

Build failed
Swift Test OS X Platform
Git Sha - 2b0e101a789fb0118e522a038602660943702afe

@swift-ci test macOS platform

@swift-ci test windows platform

authors: meg-gupta swift-ci


text:
[syntax-map] Fix array-of-object-literal syntax map, argument label keywords

What's in this pull request?

Argument labels are allowed to use keywords, in which case we want to
treat them as identifiers in the syntax map (except for '_'). This
commit moves calculation of that into the original lexing instead of
in the model walker, which makes it much more robust, since the model
walker was only guessing about what was next on the the TokenNodes list.
This fixes a bug where arrays of object literals would only have the
first object correct (the following ones were identifiers), as well as
some incorrect cases where we treated keywords as identifiers.
rdar://problem/27726422
Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

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

A smoke test on macOS does the following:

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

A smoke test on Linux does the following:

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

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

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

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

@swift-ci Please smoke test OS X platform


text:
[Distributed] SerializationReq must be associated type on DA

Resolves rdar://91664256
In order to support   public protocol DistributedActor<ID, SerializationRequirement> in the future, we must make SerializationReq an associated type. Thankfully, synthesis of it is pretty simple.

The typealias must be synthesized for every concrete DA.
Current users won't even notice it changed.

@swift-ci please smoke test and merge


text:
[Build Scripts] Enable OS X build when Xcode is located in a path con…

…taining spaces
Applied a combination of explicitly quoted paths and bash's string escaping facilities to allow a build to complete successfully.

This code is the issue, it should be fixed instead:
  # Convert variables to space-separated strings.
  string(REPLACE ";" " " c_compile_flags "${c_compile_flags}")
  string(REPLACE ";" " " link_flags "${link_flags}")

https://github.com/apple/swift/commit/ba6643c7a4b851a131cd84616069f932747b5a7b is the first step.  The build passes, tests still have issues.

I'm content that Dmitri's approach above has addressed the issues this pull request was intended to solve.  Thanks!  Solving the remaining test issues would definitely be appreciated.


text:
[5.7][stdlib] Duration: Fix rare overflow trap in Int128.multipliedFullWidth

(cherry picked from #59959)

Explanation: Int128.multipliedFullWidth fails to account for an overflow case, which results in Duration.components trapping when the duration is a multiple of 512s.
Scope: Duration in the Standard Library.
Origination: Duration is a new type in Swift 5.7.
Risk: Low
Reviewers: tbd
Testing: New regression tests.
Issue: rdar://96362510

@swift-ci test


text:
[Macros] Improve parsing, representation, and serialization of role attributes

Parse compound and special names in the macro role attributes (@freestanding and @attached). This allows both compound names and initializers, e.g., init(coding:).
Fixes rdar://107967344.

@swift-ci please smoke test


text:
[test] Add REQUIRES: assert to moveonly_addressors using experimental feature

moveonly_addressors.swift (added in #70475) uses the experimental feature NonescapableTypes, which requires an asserts compiler to work, so requires marking the test as REQUIRES: asserts.

@swift-ci please test


text:
CMake: on Darwin be explicit about inclusion in the dyld shared cache

This entails passing a linker flags to Apple linkers when the standard library is not meant for inclusion in such cache.
For this to have effect on every library, propagate link flags when building _Concurrency and Observation.
This is needed for Apple internal configurations.
Addresses rdar://120653968

@swift-ci please test

@swift-ci please build toolchain

@swift-ci please test

@swift-ci please build toolchain

I used generator expressions based on the feedback on a past PR that dealt with linker flags, assuming it was the preferred approach going forward -- likely I missed the context there and thought I could apply that verbatim here.
Reworked this in fc60c6c
To answer your second question: yes, I'm using configuration-time booleans.

@swift-ci please test

@swift-ci please build toolchain

@swift-ci please test

@swift-ci please build toolchain

Good point, I totally forgot to check Synchronization when marking this PR as ready to review -- tackling that in https://github.com/apple/swift/pull/70856/commits/d84140d1d331b7c665bb8ea72c79be297191444d (and adding a missing newline while I'm at it)

@swift-ci please test

@swift-ci please build toolchain

@swift-ci please build toolchain Windows


text:
NCGenerics: restrict conditional Copyable reqs

It doesn't really make sense for a conditional conformance requirement for Copyable to depend on any other requirement other than other Copyable conformance requirements.
resolves rdar://124967739

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test linux

@swift-ci smoke test


text:
[swiftc (46 vs. 5451)] Add crasher in swift::TypeBase::getCanonicalType(...)

Add test case for crash triggered in swift::TypeBase::getCanonicalType(...).
Current number of unresolved compiler crashers: 46 (5451 resolved)
Stack trace:
0 0x00000000038db698 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/path/to/swift/bin/swift+0x38db698)
1 0x00000000038dbdd6 SignalHandler(int) (/path/to/swift/bin/swift+0x38dbdd6)
2 0x00007f9b5c1d03e0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x113e0)
3 0x00007f9b5ab36428 gsignal /build/glibc-Qz8a69/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
4 0x00007f9b5ab3802a abort /build/glibc-Qz8a69/glibc-2.23/stdlib/abort.c:91:0
5 0x0000000003877dbd llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) (/path/to/swift/bin/swift+0x3877dbd)
6 0x00000000014314af swift::TypeBase::getCanonicalType() (/path/to/swift/bin/swift+0x14314af)
7 0x0000000001283aa0 (anonymous namespace)::FindCapturedVars::checkType(swift::Type, swift::SourceLoc) (/path/to/swift/bin/swift+0x1283aa0)
8 0x0000000001283f0a (anonymous namespace)::FindCapturedVars::walkToExprPre(swift::Expr*) (/path/to/swift/bin/swift+0x1283f0a)
9 0x00000000013b350e swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Expr*) (/path/to/swift/bin/swift+0x13b350e)
10 0x00000000013b22db swift::Expr::walk(swift::ASTWalker&) (/path/to/swift/bin/swift+0x13b22db)
11 0x0000000001284f20 (anonymous namespace)::FindCapturedVars::walkToDeclPre(swift::Decl*) (/path/to/swift/bin/swift+0x1284f20)
12 0x00000000013b27d4 (anonymous namespace)::Traversal::doIt(swift::Decl*) (/path/to/swift/bin/swift+0x13b27d4)
13 0x00000000013b5978 swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Stmt*) (/path/to/swift/bin/swift+0x13b5978)
14 0x00000000013b235e swift::Stmt::walk(swift::ASTWalker&) (/path/to/swift/bin/swift+0x13b235e)
15 0x0000000001282ca1 swift::TypeChecker::computeCaptures(swift::AnyFunctionRef) (/path/to/swift/bin/swift+0x1282ca1)
16 0x0000000001285637 (anonymous namespace)::FindCapturedVars::propagateCaptures(swift::AnyFunctionRef, swift::SourceLoc) (/path/to/swift/bin/swift+0x1285637)
17 0x000000000128430a (anonymous namespace)::FindCapturedVars::walkToExprPre(swift::Expr*) (/path/to/swift/bin/swift+0x128430a)
18 0x00000000013b5dd9 swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Stmt*) (/path/to/swift/bin/swift+0x13b5dd9)
19 0x00000000013b59e0 swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Stmt*) (/path/to/swift/bin/swift+0x13b59e0)
20 0x00000000013b235e swift::Stmt::walk(swift::ASTWalker&) (/path/to/swift/bin/swift+0x13b235e)
21 0x0000000001282ca1 swift::TypeChecker::computeCaptures(swift::AnyFunctionRef) (/path/to/swift/bin/swift+0x1282ca1)
22 0x0000000001285637 (anonymous namespace)::FindCapturedVars::propagateCaptures(swift::AnyFunctionRef, swift::SourceLoc) (/path/to/swift/bin/swift+0x1285637)
23 0x000000000128430a (anonymous namespace)::FindCapturedVars::walkToExprPre(swift::Expr*) (/path/to/swift/bin/swift+0x128430a)
24 0x00000000013b58e9 swift::ASTVisitor<(anonymous namespace)::Traversal, swift::Expr*, swift::Stmt*, bool, swift::Pattern*, bool, void>::visit(swift::Stmt*) (/path/to/swift/bin/swift+0x13b58e9)
25 0x00000000013b235e swift::Stmt::walk(swift::ASTWalker&) (/path/to/swift/bin/swift+0x13b235e)
26 0x0000000001282ca1 swift::TypeChecker::computeCaptures(swift::AnyFunctionRef) (/path/to/swift/bin/swift+0x1282ca1)
27 0x00000000011b837b typeCheckFunctionsAndExternalDecls(swift::TypeChecker&) (/path/to/swift/bin/swift+0x11b837b)
28 0x00000000011b8b55 swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int, unsigned int) (/path/to/swift/bin/swift+0x11b8b55)
29 0x0000000000f0ccf6 swift::CompilerInstance::performSema() (/path/to/swift/bin/swift+0xf0ccf6)
30 0x00000000004a51d6 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) (/path/to/swift/bin/swift+0x4a51d6)
31 0x0000000000464337 main (/path/to/swift/bin/swift+0x464337)
32 0x00007f9b5ab21830 __libc_start_main /build/glibc-Qz8a69/glibc-2.23/csu/../csu/libc-start.c:325:0
33 0x00000000004619d9 _start (/path/to/swift/bin/swift+0x4619d9)

@swift-ci please test and merge


text:
IDE: Fix USR mangling for unnamed subscript parameters

Fixes https://bugs.swift.org/browse/SR-4286.

@swift-ci Please smoke test

@swift-ci Please smoke test


text:
SFrame performance degrades significantly when there are lots of columns.

Adding columns to an SFrame degrades significantly when there are numerous tiny columns.  Observe:
In [1]: import turicreate as tc

In [2]: def run(n):
   ...:     X = tc.SFrame()
   ...:     for i in range(n):
   ...:         X["X%d" % i] = tc.SArray([i])
   ...:     return X
   ...:

In [3]: %timeit run(100)
10 loops, best of 3: 40.1 ms per loop

In [4]: %timeit run(1000)
1 loop, best of 3: 1.76 s per loop

In [5]: %timeit run(1500)
1 loop, best of 3: 4.36 s per loop

In [6]: %timeit run(2000)
1 loop, best of 3: 7.81 s per loop

In [7]: %timeit run(5000)
1 loop, best of 3: 1min 9s per loop

Upgrading this to a P1.  More issues are coming up around this.

repo: apple/turicreate


text:
Suppress GPU usage in TensorFlow when TC num_gpus set to 0

Fixes #2651

Well, I’m going to Italy. @shreyajain17 I hereby bequeath this PR to you!

Before this I trained an image classifier using gpus.

In [2]: data = tc.SFrame('breakfast-data.sframe/')

In [3]: tc.config.set_num_gpus(0)

In [4]: model = tc.image_classifier.create(data, 'prominent_object')
WARNING:tensorflow:From /miniconda/lib/python2.7/site-packages/tensorflow_core/python/compat/v2_compat.py:65: disable_resource_variables (from tensorflow.python.ops.variable_scope) is deprecated and will be removed in a future version.
Instructions for updating:
non-resource variables are not supported in the long term
2019-11-23 07:07:34.006682: E tensorflow/stream_executor/cuda/cuda_driver.cc:318] failed call to cuInit: CUDA_ERROR_NO_DEVICE: no CUDA-capable device is detected```


text:
chore: 絵文字Seqの調整

Type of Change:

新規追加
改善

Details of implementation (実施内容)

腹切り の り の部分の更新
絵文字が削除された雪留年のSeqを削除
以下のSeqを追加
　 - 留年
　 - 最悪
　 - 黙れ
　 - 腹切れよ

Codecov Report

Merging #419 (a1b4f21) into main (f38fa84) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #419   +/-   ##
=======================================
  Coverage   71.12%   71.12%
=======================================
  Files          57       57
  Lines        3851     3851
  Branches      360      360
=======================================
  Hits         2739     2739
  Misses        752      752
  Partials      360      360

Flag
Coverage Δ

unittests
71.12% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

license: MIT


text:
[Bug]: Parametred qry do not correctly load on load page due  on bad incoming entities response

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
My main qry is like this:
select  {{Qry_centrale6_somme.data.find(el => el.centrale6==="MAXEDA").sum}} as value
from dim_date b
where ......

run qry on page load is setted for both qry
on refresh page or app start the main qry return blank lines
the problem is that this main qry is launched before the result of {{Qry_centrale6_somme.data.find(el => el.centrale6==="MAXEDA").sum}}
so the result is undefined and i get the correct line number but not the correct data
I recently migrated to1.6.8 and this pbm does not exist in the previous version 1.5.9
Steps To Reproduce

Environment
Production
Version
Self-Hosted

@cdoudet I'm not able to reproduce this on our end. Could you share a an example application where you can reproduce this behavior?

@cdoudet we're closing this as we're not able to reproduce it. Do let us know if you can help us with the steps

authors: Nikhil-Nandagopal cdoudet

repo: appsmithorg/appsmith


text:
[Feature]: Merge two applications into one

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
I have page "A" inside one application and page "B" inside another application. I would like to have page A and B on the same application. This feature would allow to merge two applications together by adding all pages from app 2 to app 1.
Why should this be worked on?
Say you're building two internal apps alongside each other. As time goes on, the two projects start to align and share more data. At some point, it's obvious that they should be in the same application, but to do that you have to manually copy over every page, query, and JSObjects. It would be much better to have a built in workflow for this.

There are two distinct problems here. One, move/copy/clone a page in one application to another application. Second, merge two applications, potentially producing a new one (or not), that contains pages from both applications.
The first at least, seems like a very useful feature.

@sharat87 agreed, I believe it's the first too

Actually its the mix of both. The user is asking to merge pages of two applications. Its similar to what we doing with templates.

@hiteshjoshi but the use case is not to create a 3rd app from 2 apps. It's always to copy or move some part of an existing app to an existing app like in templates right?

Yes @Nikhil-Nandagopal, the use case is such. The only problem I feel is, if the apps are connected to Git. It will create a lot of changes and might require steps to ask which branch to merge on etc. Hence creating a third app based on default branch seems like a safest option to start with and later we can iterate.

@hiteshjoshi ah from that perspective I understand but the problem in creating new apps is that now all the teams need to be notified that the usual URL they use, must be changed to the new URL. That's a big overhead in companies and they prefer that URLs don't change

I think this will be solved by reusability so I'm closing it in favor of #5229

authors: Nikhil-Nandagopal ghost hiteshjoshi sharat87


text:
[Feature]: Audio Player in table

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
I have the url of audio files. If I go to the url, it would show the audio player.
It would be nice to play the audio directly from the table rows. (Play , pause, etc on the row itself)
Why should this be worked on?
It would make the table more useful.

@AdithyaSanjay This will be convenient for the user for sure, thanks for the feature request.
Suggestion:
For now why dont you use the audio widget and use the table widget selected row to auto play the audio? Would that be a better UX for you?

Sure, that's a good idea too. I'll try it out. And thank you for accepting
my request. 😊
On Thu, 8 Sep, 2022, 12:51 pm Somangshu Goswami, @.***>
wrote:

@AdithyaSanjay https://github.com/AdithyaSanjay This will be convenient
for the user for sure, thanks for the feature request.
Suggestion:
For now why dont you use the audio widget and use the table widget
selected row to auto play the audio? Would that be a better UX for you?
—
Reply to this email directly, view it on GitHub
https://github.com/appsmithorg/appsmith/issues/16602#issuecomment-1240326411,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZ2FXTLH4T5C5QTBD2LJHKDV5GHV3ANCNFSM6AAAAAAQGO4MAA
.
You are receiving this because you were mentioned.Message ID:
@.***>

authors: AdithyaSanjay somangshu


text:
feat: WDS key-value display mode for input widgets

Cheap solution: a boolean readonly on inputs, that turns off borders and backgrounds, sets foreground to neutral and turns of editability.

Hey team! Please add your planning poker estimate with Zenhub @KelvinOm @dhruvikn @jsartisan

authors: KelvinOm ichik


text:
[Bug]: On upgrading to a higher version, all of the previous commits are seen as uncommitted changes.

Is there an existing issue for this?

[X] I have searched the existing issues

Description
On upgrading to a higher version, all of the previous commits are seen as uncommitted changes.
Steps To Reproduce

Create an app and connect it to git. (Ensure that the app is created on an old version of appsmith. v1.9.35 in this case)
Make changes to the app and commit them
Next, either upgrade the instance or import the app onto latest release release
Notice that the previously committed changes are seen as uncommitted changes

Public Sample App
No response
Environment
Deploy Preview
Issue video log
https://www.loom.com/share/7faa5876c9574d84afefd7858415f3c7?sid=737185f2-6aac-4aa0-b268-8f85388f4ed4
Version
Release

In step 3, how you are importing the app to latest release? Is it import from Git?

Bumping this issue up to prod because it should have made it's way there by now if it was not fixed

This issue was occurring because of a feature flag issue. It is now resolved. Closing this for now, feel free to open if it re-occurs

This issue has been resolved

authors: Nikhil-Nandagopal brayn003 laveena-en nayan-rafiq


text:
[Feature]: Login (Authentication) that actually works (!?)

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
The bot answered me about the authentication, and something or someone else warned me the bot was wrong. Then, in the chat, I was required to fill out these forms here.
// In a JSObject
export default {
checkAuthAndRedirect: () => {
if (appsmith.user.isLoggedIn) {
// User is logged in, navigate to the main page
navigateTo('MainPage');
} else {
// User is not logged in, keep them on or send them to the login page
navigateTo('LoginPage');
}
}
}
It gave me this answer about having an authentication that actually works and makes sense because I need the user to enter the page only if he made the correct login, and for safe coding if a user is somehow on a page not logged, return to the login. The most crucial part is that the other pages get blocked if the user has not entered them. The user must have the correct credentials or cannot go to the different pages.
Why should this be worked on?
Well, I need a login feature, this is fundamental for any app that has credentials. I was also required by chat to ask here, so this is a basic procedure. I'm kinda confused if Appsmith doesn't have this yet or If I'm just dumb and don't know how to implement xD. As I was warned on chat, I imagine that it doesn't.
For any app with a login, the user must only access the following pages if logged in.

@danieltkw if you are using SSO or the Appsmith in-built login, then you only require to use our RBAC feature (business edition) to control which pages a user has access to and the platform will take care of the rest.
https://docs.appsmith.com/advanced-concepts/granular-access-control/reference/custom-roles#restrict-access-to-page
If you have a custom authentication backend which you must integrate with then you can follow this guide
https://docs.appsmith.com/advanced-concepts/custom-authentication
Hope this helps!

authors: Nikhil-Nandagopal danieltkw


text:
pr for testing. Don't merge

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

Description

Please include a summary of the changes and which issue has been fixed. Please also include relevant motivation
and context. List any dependencies that are required for this change.

Fixes # (issue)

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

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)
This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions, so we can reproduce.
Please also list any relevant details for your test configuration.

Test A
Test B

Checklist:

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

/ok-to-test sha=f840282


text:
feat: use hideWatermark from tenantConfig

Description
Instead of using the env file to get the value for hideWatermark, we are moving it to the tenantConfig. Makes it easier to manage and does not need a server restart while changing the value.
PR fixes following issue(s)
Fixes #27922
https://github.com/appsmithorg/appsmith-ee/pull/2628
Type of change

Please delete options that are not relevant.

New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
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

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


text:
Enable toggle for params encoding

Description

Add toggle param to ActionConfiguration class.
Add TCs to test toggle on/off/null.

Fixes #2897
Type of change

New feature (non-breaking change which adds functionality)
This change requires a documentation update

How Has This Been Tested?
Tested via Junit TCs. Add 3 TC:

for toggle set to true.
for toggle set to false.
for toggle see to null.

Checklist:

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

@sumitsum : If I understood the problem clearly, this was for body of content type form url encoded, NOT the url itself. Could you please confirm the requirements?

LGTM. Can be merged.

authors: sumitsum trishaanand