text:
Command implementation

CC @nastevens
This includes a decent chunk of changes, the bulk of which are updates to the config to clean up how parsing there work, catch a few extra edge conditions, etc.  Using the included configuraiton for the BBB, I have verified that I can export GPIOs and read GPIOs fine.  The other commands should be relatively easy to add now that the structure and config parsing is all in place:
root@beaglebone:~# ./gpio -c beaglebone.toml export-all
root@beaglebone:~# ls -al /var/run/gpio/
total 0
drwxr-xr-x  2 root root 5440 Apr 18 05:48 .
drwxr-xr-x 22 root root  600 Apr 18 05:48 ..
lrwxrwxrwx  1 root root   17 Apr 18 05:48 CLKOUT2 -> /sys/class/gpio20
lrwxrwxrwx  1 root root   16 Apr 18 05:48 ECAPPPWM0 -> /sys/class/gpio7
lrwxrwxrwx  1 root root   17 Apr 18 05:48 EHRPPWM2A -> /sys/class/gpio22
lrwxrwxrwx  1 root root   17 Apr 18 05:48 EHRPWM0A -> /sys/class/gpio49
lrwxrwxrwx  1 root root   17 Apr 18 05:48 EHRPWM1A -> /sys/class/gpio40
lrwxrwxrwx  1 root root   17 Apr 18 05:48 EHRPWM1A_2 -> /sys/class/gpio80
lrwxrwxrwx  1 root root   17 Apr 18 05:48 EHRPWM1B -> /sys/class/gpio51
lrwxrwxrwx  1 root root   17 Apr 18 05:48 EHRPWM1B_2 -> /sys/class/gpio81
lrwxrwxrwx  1 root root   17 Apr 18 05:48 EHRPWM2A_2 -> /sys/class/gpio70
lrwxrwxrwx  1 root root   17 Apr 18 05:48 EHRPWM2B -> /sys/class/gpio23
lrwxrwxrwx  1 root root   17 Apr 18 05:48 EHRPWM2B_2 -> /sys/class/gpio71
lrwxrwxrwx  1 root root   16 Apr 18 05:48 EHRPWMB -> /sys/class/gpio3
lrwxrwxrwx  1 root root   18 Apr 18 05:48 eQEP0B -> /sys/class/gpio115
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_10 -> /sys/class/gpio10
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_11 -> /sys/class/gpio11
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO01_17 -> /sys/class/gpio49
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_12 -> /sys/class/gpio12
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_13 -> /sys/class/gpio13
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_14 -> /sys/class/gpio14
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_15 -> /sys/class/gpio15
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO0_2 -> /sys/class/gpio2
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_20 -> /sys/class/gpio20
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_22 -> /sys/class/gpio22
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_23 -> /sys/class/gpio23
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_26 -> /sys/class/gpio26
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_27 -> /sys/class/gpio27
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO0_3 -> /sys/class/gpio3
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_30 -> /sys/class/gpio30
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO0_31 -> /sys/class/gpio31
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO0_4 -> /sys/class/gpio4
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO0_5 -> /sys/class/gpio5
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO0_7 -> /sys/class/gpio7
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO0_8 -> /sys/class/gpio8
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO0_9 -> /sys/class/gpio9
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_10 -> /sys/class/gpio10
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_0 -> /sys/class/gpio32
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_11 -> /sys/class/gpio11
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_1 -> /sys/class/gpio33
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO_110 -> /sys/class/gpio110
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO_111 -> /sys/class/gpio111
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO_112 -> /sys/class/gpio112
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_12 -> /sys/class/gpio44
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO_113 -> /sys/class/gpio113
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_13 -> /sys/class/gpio45
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_14 -> /sys/class/gpio46
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO_115 -> /sys/class/gpio115
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_15 -> /sys/class/gpio47
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_16 -> /sys/class/gpio48
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO_117 -> /sys/class/gpio117
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_18 -> /sys/class/gpio40
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_19 -> /sys/class/gpio51
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_12 -> /sys/class/gpio12
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_2 -> /sys/class/gpio34
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_28 -> /sys/class/gpio60
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_29 -> /sys/class/gpio61
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_13 -> /sys/class/gpio13
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_3 -> /sys/class/gpio35
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_30 -> /sys/class/gpio62
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_31 -> /sys/class/gpio63
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_14 -> /sys/class/gpio14
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_4 -> /sys/class/gpio36
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_15 -> /sys/class/gpio15
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_5 -> /sys/class/gpio37
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_6 -> /sys/class/gpio38
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO1_7 -> /sys/class/gpio39
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO_2 -> /sys/class/gpio2
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_20 -> /sys/class/gpio20
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_1 -> /sys/class/gpio65
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_10 -> /sys/class/gpio74
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_11 -> /sys/class/gpio75
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_12 -> /sys/class/gpio76
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_13 -> /sys/class/gpio77
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_14 -> /sys/class/gpio78
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_15 -> /sys/class/gpio79
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_16 -> /sys/class/gpio80
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_17 -> /sys/class/gpio81
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_22 -> /sys/class/gpio22
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_2 -> /sys/class/gpio66
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_22 -> /sys/class/gpio86
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_23 -> /sys/class/gpio87
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_24 -> /sys/class/gpio88
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_25 -> /sys/class/gpio89
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_23 -> /sys/class/gpio23
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_3 -> /sys/class/gpio67
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_4 -> /sys/class/gpio68
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_5 -> /sys/class/gpio69
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_26 -> /sys/class/gpio26
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_6 -> /sys/class/gpio70
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_27 -> /sys/class/gpio27
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_7 -> /sys/class/gpio71
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_8 -> /sys/class/gpio72
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO2_9 -> /sys/class/gpio73
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO_3 -> /sys/class/gpio3
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO30 -> /sys/class/gpio30
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_31 -> /sys/class/gpio31
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO3_12 -> /sys/class/gpio110
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO3_14 -> /sys/class/gpio112
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO3_15 -> /sys/class/gpio111
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO3_17 -> /sys/class/gpio113
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO3_19 -> /sys/class/gpio115
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_32 -> /sys/class/gpio32
lrwxrwxrwx  1 root root   18 Apr 18 05:48 GPIO3_21 -> /sys/class/gpio117
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_33 -> /sys/class/gpio33
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_34 -> /sys/class/gpio34
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_35 -> /sys/class/gpio35
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_36 -> /sys/class/gpio36
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_37 -> /sys/class/gpio37
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_38 -> /sys/class/gpio38
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_39 -> /sys/class/gpio39
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO_4 -> /sys/class/gpio4
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO40 -> /sys/class/gpio40
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_44 -> /sys/class/gpio44
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_45 -> /sys/class/gpio45
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_46 -> /sys/class/gpio46
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_47 -> /sys/class/gpio47
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_48 -> /sys/class/gpio48
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_49 -> /sys/class/gpio49
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO_5 -> /sys/class/gpio5
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_51 -> /sys/class/gpio51
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_60 -> /sys/class/gpio60
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_61 -> /sys/class/gpio61
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_62 -> /sys/class/gpio62
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_63 -> /sys/class/gpio63
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_65 -> /sys/class/gpio65
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_66 -> /sys/class/gpio66
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_67 -> /sys/class/gpio67
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_68 -> /sys/class/gpio68
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_69 -> /sys/class/gpio69
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO_7 -> /sys/class/gpio7
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_70 -> /sys/class/gpio70
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_71 -> /sys/class/gpio71
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_72 -> /sys/class/gpio72
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_73 -> /sys/class/gpio73
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_74 -> /sys/class/gpio74
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_75 -> /sys/class/gpio75
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_76 -> /sys/class/gpio76
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_77 -> /sys/class/gpio77
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_78 -> /sys/class/gpio78
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_79 -> /sys/class/gpio79
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO_8 -> /sys/class/gpio8
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_80 -> /sys/class/gpio80
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_81 -> /sys/class/gpio81
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_86 -> /sys/class/gpio86
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_87 -> /sys/class/gpio87
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_88 -> /sys/class/gpio88
lrwxrwxrwx  1 root root   17 Apr 18 05:48 GPIO_89 -> /sys/class/gpio89
lrwxrwxrwx  1 root root   16 Apr 18 05:48 GPIO_9 -> /sys/class/gpio9
lrwxrwxrwx  1 root root   16 Apr 18 05:48 I2C1_SCL -> /sys/class/gpio5
lrwxrwxrwx  1 root root   16 Apr 18 05:48 I2C1_SDA -> /sys/class/gpio4
lrwxrwxrwx  1 root root   17 Apr 18 05:48 I2C2_SCL -> /sys/class/gpio13
lrwxrwxrwx  1 root root   17 Apr 18 05:48 I2C2_SDA -> /sys/class/gpio12
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_AC_BIAS -> /sys/class/gpio89
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA0 -> /sys/class/gpio70
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA1 -> /sys/class/gpio71
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA10 -> /sys/class/gpio80
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA11 -> /sys/class/gpio81
lrwxrwxrwx  1 root root   16 Apr 18 05:48 LCD_DATA12 -> /sys/class/gpio8
lrwxrwxrwx  1 root root   16 Apr 18 05:48 LCD_DATA13 -> /sys/class/gpio9
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA14 -> /sys/class/gpio10
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA15 -> /sys/class/gpio11
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA2 -> /sys/class/gpio72
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA3 -> /sys/class/gpio73
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA4 -> /sys/class/gpio74
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA5 -> /sys/class/gpio75
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA6 -> /sys/class/gpio76
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA7 -> /sys/class/gpio77
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA8 -> /sys/class/gpio78
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_DATA9 -> /sys/class/gpio79
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_HSYNC -> /sys/class/gpio87
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_PCLK -> /sys/class/gpio88
lrwxrwxrwx  1 root root   17 Apr 18 05:48 LCD_VSYNC -> /sys/class/gpio86
lrwxrwxrwx  1 root root   17 Apr 18 05:48 MMC1_CLK -> /sys/class/gpio62
lrwxrwxrwx  1 root root   17 Apr 18 05:48 MMC1_CMD -> /sys/class/gpio63
lrwxrwxrwx  1 root root   17 Apr 18 05:48 MMC1_DAT0 -> /sys/class/gpio32
lrwxrwxrwx  1 root root   17 Apr 18 05:48 MMC1_DAT1 -> /sys/class/gpio33
lrwxrwxrwx  1 root root   17 Apr 18 05:48 MMC1_DAT2 -> /sys/class/gpio34
lrwxrwxrwx  1 root root   17 Apr 18 05:48 MMC1_DAT3 -> /sys/class/gpio35
lrwxrwxrwx  1 root root   17 Apr 18 05:48 MMC1_DAT4 -> /sys/class/gpio36
lrwxrwxrwx  1 root root   17 Apr 18 05:48 MMC1_DAT5 -> /sys/class/gpio37
lrwxrwxrwx  1 root root   17 Apr 18 05:48 MMC1_DAT6 -> /sys/class/gpio38
lrwxrwxrwx  1 root root   17 Apr 18 05:48 MMC1_DAT7 -> /sys/class/gpio39
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_10 -> /sys/class/gpio68
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_11 -> /sys/class/gpio45
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_12 -> /sys/class/gpio44
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_13 -> /sys/class/gpio23
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_14 -> /sys/class/gpio26
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_15 -> /sys/class/gpio47
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_16 -> /sys/class/gpio46
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_17 -> /sys/class/gpio27
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_18 -> /sys/class/gpio65
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_19 -> /sys/class/gpio22
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_20 -> /sys/class/gpio63
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_21 -> /sys/class/gpio62
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_22 -> /sys/class/gpio37
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_23 -> /sys/class/gpio36
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_24 -> /sys/class/gpio33
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_25 -> /sys/class/gpio32
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_26 -> /sys/class/gpio61
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_27 -> /sys/class/gpio86
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_28 -> /sys/class/gpio88
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_29 -> /sys/class/gpio87
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_3 -> /sys/class/gpio38
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_30 -> /sys/class/gpio89
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_31 -> /sys/class/gpio10
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_32 -> /sys/class/gpio11
lrwxrwxrwx  1 root root   16 Apr 18 05:48 P8_33 -> /sys/class/gpio9
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_34 -> /sys/class/gpio81
lrwxrwxrwx  1 root root   16 Apr 18 05:48 P8_35 -> /sys/class/gpio8
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_36 -> /sys/class/gpio80
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_37 -> /sys/class/gpio78
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_38 -> /sys/class/gpio79
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_39 -> /sys/class/gpio76
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_4 -> /sys/class/gpio39
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_40 -> /sys/class/gpio77
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_41 -> /sys/class/gpio74
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_42 -> /sys/class/gpio75
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_43 -> /sys/class/gpio72
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_44 -> /sys/class/gpio73
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_45 -> /sys/class/gpio70
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_46 -> /sys/class/gpio71
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_5 -> /sys/class/gpio34
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_6 -> /sys/class/gpio35
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_7 -> /sys/class/gpio66
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_8 -> /sys/class/gpio67
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P8_9 -> /sys/class/gpio69
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_11 -> /sys/class/gpio30
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_12 -> /sys/class/gpio60
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_13 -> /sys/class/gpio31
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_14 -> /sys/class/gpio40
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_15 -> /sys/class/gpio48
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_16 -> /sys/class/gpio51
lrwxrwxrwx  1 root root   16 Apr 18 05:48 P9_17 -> /sys/class/gpio5
lrwxrwxrwx  1 root root   16 Apr 18 05:48 P9_18 -> /sys/class/gpio4
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_19 -> /sys/class/gpio13
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_20 -> /sys/class/gpio12
lrwxrwxrwx  1 root root   16 Apr 18 05:48 P9_21 -> /sys/class/gpio3
lrwxrwxrwx  1 root root   16 Apr 18 05:48 P9_22 -> /sys/class/gpio2
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_23 -> /sys/class/gpio49
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_24 -> /sys/class/gpio15
lrwxrwxrwx  1 root root   18 Apr 18 05:48 P9_25 -> /sys/class/gpio117
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_26 -> /sys/class/gpio14
lrwxrwxrwx  1 root root   18 Apr 18 05:48 P9_27 -> /sys/class/gpio115
lrwxrwxrwx  1 root root   18 Apr 18 05:48 P9_28 -> /sys/class/gpio113
lrwxrwxrwx  1 root root   18 Apr 18 05:48 P9_29 -> /sys/class/gpio111
lrwxrwxrwx  1 root root   18 Apr 18 05:48 P9_30 -> /sys/class/gpio112
lrwxrwxrwx  1 root root   18 Apr 18 05:48 P9_31 -> /sys/class/gpio110
lrwxrwxrwx  1 root root   17 Apr 18 05:48 P9_41 -> /sys/class/gpio20
lrwxrwxrwx  1 root root   16 Apr 18 05:48 P9_42 -> /sys/class/gpio7
lrwxrwxrwx  1 root root   17 Apr 18 05:48 PWM0_SYNC0 -> /sys/class/gpio27
lrwxrwxrwx  1 root root   17 Apr 18 05:48 PWM_TRIPZ_IN -> /sys/class/gpio48
lrwxrwxrwx  1 root root   17 Apr 18 05:48 SER -> /sys/class/gpio14
lrwxrwxrwx  1 root root   17 Apr 18 05:48 SER1_TX -> /sys/class/gpio15
lrwxrwxrwx  1 root root   18 Apr 18 05:48 SPI1_CS0 -> /sys/class/gpio113
lrwxrwxrwx  1 root root   18 Apr 18 05:48 SPI1_D1 -> /sys/class/gpio112
lrwxrwxrwx  1 root root   18 Apr 18 05:48 SPI1_MISO -> /sys/class/gpio111
lrwxrwxrwx  1 root root   18 Apr 18 05:48 SPI1_SCLK -> /sys/class/gpio110
lrwxrwxrwx  1 root root   17 Apr 18 05:48 TIMER4 -> /sys/class/gpio66
lrwxrwxrwx  1 root root   17 Apr 18 05:48 TIMER5 -> /sys/class/gpio69
lrwxrwxrwx  1 root root   17 Apr 18 05:48 TIMER6 -> /sys/class/gpio68
lrwxrwxrwx  1 root root   17 Apr 18 05:48 TIMER7 -> /sys/class/gpio67
lrwxrwxrwx  1 root root   16 Apr 18 05:48 UART2_RX -> /sys/class/gpio2
lrwxrwxrwx  1 root root   16 Apr 18 05:48 UART2_TX -> /sys/class/gpio3
lrwxrwxrwx  1 root root   16 Apr 18 05:48 UART4_CTS -> /sys/class/gpio8
lrwxrwxrwx  1 root root   16 Apr 18 05:48 UART4_RTS -> /sys/class/gpio9
lrwxrwxrwx  1 root root   17 Apr 18 05:48 UART4_RX -> /sys/class/gpio30
lrwxrwxrwx  1 root root   17 Apr 18 05:48 UART4_TX -> /sys/class/gpio31
lrwxrwxrwx  1 root root   17 Apr 18 05:48 UART5_CTS -> /sys/class/gpio10
lrwxrwxrwx  1 root root   17 Apr 18 05:48 UART5_RTS -> /sys/class/gpio11
lrwxrwxrwx  1 root root   17 Apr 18 05:48 UART5_RX -> /sys/class/gpio79
lrwxrwxrwx  1 root root   17 Apr 18 05:48 UART5_TX -> /sys/class/gpio78
root@beaglebone:~# ./gpio -c beaglebone.toml read P9_11
0
root@beaglebone:~# ./gpio -c beaglebone.toml read P9_11
1

No time result just to rub it in? 😄

This looks great! 💯

And here's some really rough time results.  Keep in mind that this is with a quite involved toml configuration on the BBB:
root@beaglebone:~# time ./gpio -c beaglebone.toml export-all

real    0m0.108s
user    0m0.040s
sys     0m0.030s
root@beaglebone:~# time ./gpio -c beaglebone.toml read P9_11
1

real    0m0.068s
user    0m0.030s
sys     0m0.000s

Just checking... @homu r=nastevens

authors: nastevens posborne

repo: rust-embedded/gpio-utils


text:
Newsletter 42: Jan 2023

Newsletter 42: Jan 2023
tags: newsletter
Editors: @AngelOnFira, @ozkriff
Another month has gone by, so it's time to put together the Rust Gamedev newsletter with TODO's news!
Current Schedule
The soft deadline for all section PRs is 10 Feb 2023.
We may still accept PRs that are submitted later than this, as long as they're ready before the newsletter's release, but this isn't guaranteed. If you want your section to be included, don't leave it till the last minute!
How to Contribute
If you want to help writing the newsletter:

Read CONTRIBUTING.md.
Choose one or more of the "🆓 free" sections listed below, and leave a comment letting us know you want to work on them.

The links in brackets (like "1, 2, 3") are suggestions of links to include in the section. Feel free to add more!
The username listed next to the section (like "@ozkriff?") is a suggestion of who may want to pick up the work (usually the project's developer, or someone who has expressed interest in the past).
You are not obligated to write a section if you're tagged or your project is listed! You're welcome to ask someone else to write the section, or to ask for your project to be excluded from this month's post.
Extra sections not listed in the plan are welcomed - just leave a comment and open a PR!

Write a short overview in the newsletter's Markdown file, making sure to follow the style guidelines (see below).
Send a PR to the source branch (example: #336).
Mention this issue in your PR's description to link it all together.

Style Guidelines
The full style guide is in CONTRIBUTING.md, but here are the most important rules:

Write in third-person perspective.
Each line must be 80 characters or less, for ease of reviewing/diffing.
Only one image per section is allowed.

The maximum size is 300kb for static images and 2.5mb for GIFs.
The image should come before the text, and must have alt text for accessibility.
Prefer static images to GIFs, to keep the page load times down.

Each section should be under 1000 characters, and under 6 paragraphs.

This only applies to the rendered text, not the markup.

Keep formatting minimal - no bold/italics/etc.
Avoid long/nested bullet point lists - no changelogs!

Please use these templates as a starting point:
Games/apps/libraries:
### [Game name]

![alt text](img)
_optional image label_

[Game name] ([GitHub], [Discord], [Twitter]) by [@nickname]
is... {short project description in one sentence}.

{An overview of the recent updates with links to more details}.

_Discussions: [/r/rust_gamedev](link), [Twitter](link), [etc](link)_

[Game name]: http://example.com

Articles/blog posts/videos/etc:
### [Article name]

![alt text](img)
_optional image label_

[@nickname] published an [article] about...
{overview what the resource is about}.

_Discussions: [/r/rust_gamedev](link), [Twiter](link), [etc](link)_

[Article name]: http://example.com

Current Structure & Status
Below is our current planned structure for the newsletter, and the status of each PR (which we'll try to keep updated).
This is not an exhaustive list - if you have your own project that you want to write about, just make a comment on this issue and open a PR!

Rust Gamedev Meetup

[ ] Details of this month's meetup - 🚧 WIP by @AngelOnFira

Game Updates

[ ] Veloren (1) - 🚧 WIP by @AngelOnFira
[ ] Hydrofoil Generation (1) - 🆓 free (@kunos?)
[ ] Tiny Glade (1) - 🆓 free (@anopara?)
[ ] Thetawave (1) - 🆓 free (@cdsupina?)
[ ] 8bit Duels (1) - 🆓 free (@ThousandthStar?)
[x] Cargo Space (1, 2) - ✔ done by @johanhelsing
[ ] Combine And Conquer (1) - 🆓 free (@I3ck?)
[ ] Your Only Move is Hustle (1) - 🆓 free (@uzkbwza?)
[x] Digital Extinction (1) - ✔ done by @Indy2222
[ ] TheGrimsey’s devlog (1) - 🆓 free (@TheGrimsey?)
[ ] Flesh (1, 2) - 🆓 free (@Im-Oab?)
[ ] DGS (1) - 🆓 free (@Dominux?)
[ ] Idu (1, 2, 3, 4) - 🚧 WIP by @logicsoup
[ ] triverse (1) - 🆓 free (@bcarruthers?)
[ ] Combine And Conquer (1) - 🆓 free (@I3ck?)
[ ] Fish Folk: Punchy (1) - 🆓 free (@erlend-sh?)
[ ] Life Code (1) - 🆓 free (@pinkponk?)
[ ] digg (1) - 🆓 free (@Defernus?)
[ ] Revolver Time (1, 2) - 🆓 free
[ ] canal mania (1, 2) - 🆓 free (@lee-orr?)

Learning Material Updates

[ ] Native iOS Touch Events w/ Rust (1) - 🆓 free (@wadez?)
[ ] Bevy Basics video series (1) - 🆓 free (@PhaestusFox?)
[ ] Platformer in Bevy video series (1) - 🆓 free (@PhaestusFox?)
[ ] Introduction to the Entity Component System (1) - 🚧 WIP by @theredfish

Engine Updates

[ ] fyrox (1, 2, 3, 4) - 🚧 WIP by @MrDimas
[ ] alkahest-rs (1) - 🆓 free (@AnthonyUtt?)
[ ] godot-rust (1, 2) - 🆓 free (@Bromeon?)
[ ] piston (1) - 🆓 free (@bvssvni?)
[ ] petrichor64 (1, 2) - 🆓 free (@Auxnon?)

Tooling Updates

[ ] Graphite - 🚧 WIP by @Keavon
[x] Foxtrot (1) - ✔ done by @janhohenheim
[ ] Ten Minute Physics (1, 2) - 🆓 free (@cerrno?)
[ ] rgis (1) - 🆓 free (@frewsxcv?)

Library Updates

[ ] wgpu v0.15, naga v0.11 (1) - 🆓 free (@cwfitzgerald?)
[ ] raster_fonts (1) - 🆓 free (@teryror?)
[x] torchbearer (1) - ✔ done by @redwarp
[ ] nvtt (1, 2) - 🆓 free (@mijalk0?)
[ ] oxidized_navigation (1, 2) - 🆓 free (@TheGrimsey?)
[ ] Matchbox (1) - 🚧 WIP by @johanhelsing
[ ] VPlugin (1) - 🆓 free (@AndroGR?)
[ ] egui_glium (1) - 🆓 free (@emilk?)
[x] tween (1) - ✔ done by @sanbox-irl
[x] scene-graph (1) - ✔ done by @sanbox-irl
[ ] direct-storage (1) - 🆓 free (@hasenbanck?)
[x] rustysynth (1) - ✔ done by @sinshu
[x] big-brain (1) - ✔ done by @zkat
[ ] bones (1, 2) - 🆓 free (@elrend-sh @erlend-sh?)
[ ] airsim-client (1) - 🆓 free (@Sollimann?)
[ ] Rapier (1) - 🆓 free (@sebcrozet?)
[ ] miniquad (1) - 🚧 WIP by @not-fl3
[ ] bevy-magic-light-2d (1, 2, 3) - 🆓 free (@zaycev?)
[ ] notan v0.9 (1) - 🆓 free (@Nazariglez?)

Other News

[ ] Bullet points of any interesting news that doesn't have its own section - 🆓 free (@AngelOnFira?)

Discussions

[ ] "Is it a good idea to start learning game development with rust?" (1)
[ ] "Tech stack for a turn-based roguelike in Rust" (1)
[ ] "Pain points using Rust for gamedev?" (1)
[ ] "I want to make a game that’s compatible with Nintendo switch" (1)

Publishing Steps

[ ] Final review - by everyone
[ ] Publish - by @AngelOnFira
[ ] Post on /r/rust, /r/rust_gamedev, /r/gamedev, URLO, twitter.com/rust_gamedev - by @AngelOnFira
[ ] Pin thread on Twitter - by @ozkriff
[ ] Add comment links - by @AngelOnFira
[ ] Add a draft of next month's newsletter - by @AngelOnFira

Hi, I'm the author of rustysynth. I found out about this newsletter through a GitHub notification that my name was included in this issue. Would it be possible for me to write a description of rustysynth?

@sinshu of course, we would appreciate a PR! Here are our contributing guidelines but don't worry about them too much, we'll fix all the style/formatting issues during the PRs review. :)

I'll comment on torchbearer then 😉

Yeah I'll write something up on tween. I'm also working on a library called scene-graph that i'd like to write up as well

hope its not too late, I'll take miniquad update!

I'll take Cargo Space and Matchbox. Cargo space is nearly done, matchbox hopefully within a day.

Is the newsletter a good place for this article I wrote? https://indiedevcasts.com/posts/ecs-introduction . If yes, should I put it in other news?

@theredfish yes! I've added to the "Learning Material Updates" group - feel free to send a PR with a full section!

Thanks @ozkriff I will send it soon !

Hi! I'm the developer for Petrichor64. I'm not sure how you figured out my github when the repo is currently private, good sleuthing! I would like to write an article but I'm slammed with dayjob/parent stuff this month. The rust side of project is also unfortunately closed source at this time, so the coding/api layer is entirely in lua. For this reason Im not sure the project belongs here or not, but I'd love to give some insight or tips with wgpu or something next time!

The final review is up! I'll hopefully release it in the next several hours.
https://github.com/rust-gamedev/rust-gamedev.github.io/pull/1284
Live site

source: gharchive/issue

authors: AngelOnFira Auxnon johanhelsing not-fl3 ozkriff redwarp sanbox-irl sinshu theredfish

license_type: permissive

license_source: github-api


text:
N20: Gargoyle's Quest

Part of #531

Thanks for the PR!

source: gharchive/pull-request

authors: ShamylZakariya ozkriff


text:
compile broken by newest version of backtrace crate (0.3.10)

failure crate will no longer compile with backtrace 0.3.10
It seems to have to do with some new added definition for fmt

Compiling failure v0.1.3
error[E0034]: multiple applicable items in scope
--> src/backtrace/mod.rs:132:20
|
132 |                 bt.fmt(f)
|                    ^^^ multiple fmt found
|
= note: candidate #1 is defined in an impl of the trait std::fmt::Debug for the type backtrace::backtrace::Backtrace
= note: candidate #2 is defined in an impl of the trait std::fmt::Display for the type backtrace::backtrace::Backtrace
error[E0034]: multiple applicable items in scope
--> src/backtrace/mod.rs:140:20
|
140 |                 bt.fmt(f)
|                    ^^^ multiple fmt found
|
= note: candidate #1 is defined in an impl of the trait std::fmt::Debug for the type backtrace::backtrace::Backtrace
= note: candidate #2 is defined in an impl of the trait std::fmt::Display for the type backtrace::backtrace::Backtrace
error: aborting due to 2 previous errors
For more information about this error, try rustc --explain E0034.
error: Could not compile failure.
To learn more, run the command again with --verbose.

See also https://github.com/rust-lang-nursery/failure/pull/279

Oh nice. It looked like something small like that.
I'll close this issue then.

authors: BurntSushi lavifb

repo: rust-lang-nursery/failure


text:
config: Rename Replace WriteMode variant to Backup

The new variant name more closely matches its purpose. The rustfmt
binary is modified to accept --write-mode replace as a synonym for the
new name.

r? @marcusklaas

NB the change in rustfmt binary does not pick up an explicit write-mode in the rustfmt.toml file. Projects with write_mode = "replace" in their project file will see a decode failure. I think this is acceptable, as it's not really a setting that belongs in the project file anyway (cf #871). If you prefer, I can implement rustc_serialize::Decodable directly or mess with the macros to make it work.

I don't feel confident enough about this to merge it. What do you think, @nrc?

I'm not really sure about this change, since backup is a side effect of the main action (which is overwriting). I guess the ideal would be OverwriteWithBackup, but that is unpleasantly verbose.
While I agree that the replace/overwrite distinction is vague and annoying, I don't think it is worth changing unless we have a really superior alternative.

authors: kamalmarhubi marcusklaas nrc

repo: rust-lang-nursery/rustfmt


text:
Bug: Workspace giving two different behaviors in Rust

As explained here :
System:
$uname -r
4.8.0-30-generic

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.10
Release:        16.10
Codename:       yakkety

~$ rustc --version && cargo --version
rustc 1.13.0 (2c6933acc 2016-11-07)
cargo 0.13.0-nightly (eca9e15 2016-11-01)

Steps to reproduce:
Top-level:
    [package]
    name = "workspacer"
    version = "0.1.0"
    authors = ["ustulation <zzzzzz@gmail.com>"]

    [workspace]
    members = ["safe_core", "safe_authenticator", "safe_app"]

    # If this is removed then each of the sub-projects will have thier own Cargo.lock file
    # will build binaries/objects in their own target/ directories. With this present, it's
    # always the parent-projects Cargo.lock and target/ directory used. Need to check if this
    # is standard behaviour or some bug about to be fixed.
    [lib]
    crate_type = ["rlib", "cdylib", "staticlib"]

A lib called safe_core which only needs to produce a .rlib
    [package]
    authors = ["ustulation <zzzzzz@gmail.com>"]
    name = "safe_core"
    version = "0.1.0"

    [dependencies]
    maidsafe_utilities = "~0.10.0"

A lib called safe_app which depends on safe_core and needs to produce all 3 .rlib, .a and .so:
    [package]
    name = "safe_app"
    version = "0.1.0"
    authors = ["ustulation <zzzzzz@gmail.com>"]

    [dependencies]
    maidsafe_utilities = "~0.10.0"
    safe_core = { path = "../safe_core" }

    [lib]
    crate_type = ["rlib", "cdylib", "staticlib"]

A lib called safe_authenticator which depends on safe_core and needs to produce all 3 .rlib, .a and .so:
    [package]
    name = "safe_authenticator"
    version = "0.1.0"
    authors = ["ustulation <zzzzzz@gmail.com>"]

    [dependencies]
    safe_core = { path = "../safe_core" }

    [lib]
    crate_type = ["rlib", "cdylib", "staticlib"]

The tree looks like:
    workspacer
    ├── Cargo.toml
    ├── safe_app
    │   ├── Cargo.toml
    │   └── src
    │       └── lib.rs
    ├── safe_authenticator
    │   ├── Cargo.toml
    │   └── src
    │       └── lib.rs
    └── safe_core
        ├── Cargo.toml
        └── src
            └── lib.rs

If I go to safe_core and build, it creates a target/ folder and Cargo.lock files inside the top level workspacer/, which is good.
If I go to safe_authenticator folder and build that it too uses the same target/ and Cargo.lock files and hence does not recompile safe_core which is what I want too. Same with safe_app.
However if I remove the [lib] section from the top-level workspacer/Cargo.toml, each of the sub-projects start creating their own Cargo.lock files and their own /target directories inside their respective sub-directories. I have mentioned this in the inline comment in the Cargo.toml of workspacer above (the 1st snippet above).
So remove the [lib] section from workspacer/Carg.toml as the question says in the inline comment, cd to safe_app/, run cargo test. It will produce safe_app/Cargo.lock and safe_app/target/.... instead of in project dir workspacer.
In-case anyone want to try out, here's the POC repository snapshot at the commit producing the problem.

Okey, so without [lib] section workspacer/Cargo.toml is an invalid manifest. If you run cargo build in the workspacer dir, you'll get
error: failed to parse manifest at `/home/user/trash/workspacer/Cargo.toml`

Caused by:
  no targets specified in the manifest
  either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present

And because of this, safe_app does not think that it is within the workspace.
The workaround would be to remove the [package] key from  workspacer/Cargo.toml, such that it is a valid so called virtual manifest:
[workspace]
members = ["safe_core", "safe_authenticator", "safe_app"]

However this looks like a bug. Perhaps we should not ignore errors here: https://github.com/rust-lang/cargo/blob/d902f594a672c43c911bb6ea3e5d6d0ec1dde120/src/cargo/core/workspace.rs#L245

authors: matklad ustulation

repo: rust-lang/cargo


text:
Support for clone subcommad

Describe the problem you are trying to solve
I'd like a sub command (cargo clone) to exist that fetches a crate source.
Describe the solution you'd like
This would be very similar to cargo vendor but would accept an arbitrary crate and version and not require a manifest. Perhaps https://github.com/ehuss/cargo-clone-crate or https://github.com/JanLikar/cargo-clone could be integrated or something entirely new created from existing code. Cargo obviously has the ability to fetch crate source from a registry, I'd just like to be able to specify what exactly to fetch from a customizable registry and where to put it.
Notes
This request is partially related to https://github.com/rust-lang/cargo/issues/8708 and inspired by https://github.com/google/cargo-raze/issues/218. Cargo-raze now handles binary dependencies in a unique way this is fine for the time being but the ability to use cargo to fetch a crate's source from a registry would simplify things.

Closing as a duplicate of #1545, though feel free to leave a comment if I misunderstood the request.

Ah thanks, I missed that ticket. Closing as duplicate is the right thing to do here. 🙏

authors: UebelAndre ehuss


text:
credential: rename cargo:basic to cargo:token-from-stdout

Multiple people have said that the name of the cargo:basic credential provider is confusing, since it's not doing HTTP Basic authentication.
Rename cargo:basic to cargo:token-from-stdout, which more accurately describes what it does.

@bors r+

:pushpin: Commit 1065f213e3fcf89df34e2324bc7651081c32fa6a has been approved by epage
It is now in the queue for this repository.

:hourglass: Testing commit 1065f213e3fcf89df34e2324bc7651081c32fa6a with merge b6254cae483fcb4961fc4bfab6b9ad5b049839f9...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing b6254cae483fcb4961fc4bfab6b9ad5b049839f9 to master...

authors: arlosi bors epage


text:
Prep for automating MSRV management

What does this PR try to resolve?
These are the simpler / less controversial parts of #12654 ensuring we get them in now, reducing the chance for conflicts and getting some of the benefits
How should we test and review this PR?
CI
Additional information

:pushpin: Commit e78486dacaef360d3b9f0c8bbfce2d094b181fb2 has been approved by weihanglo
It is now in the queue for this repository.

@bors r+

:pushpin: Commit 29fde12f29d705ba5d712c51881aad0448ade689 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit 29fde12f29d705ba5d712c51881aad0448ade689 with merge 794d0a82547f3081044c0aca7b6083733ce51344...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing 794d0a82547f3081044c0aca7b6083733ce51344 to master...

authors: bors epage weihanglo


text:
Fix typo in test

The typo was introduced in https://github.com/rust-lang/cargo/pull/13257, it only produced a warning, so it didn't break the test.
Noticed here.

:pushpin: Commit 262e31e9fdb06094b4fe90d1f12e0e54859cf1b2 has been approved by epage
It is now in the queue for this repository.

:hourglass: Testing commit 262e31e9fdb06094b4fe90d1f12e0e54859cf1b2 with merge b2e1d3b6235c07221dd0fcac54a7b0c754ef8b11...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing b2e1d3b6235c07221dd0fcac54a7b0c754ef8b11 to master...

authors: Kobzol bors


text:
Move Cargo onto stable Rust

This commit moves Cargo onto 100% stable Rust now that the necessary fs features
have been stabilized. The tests were updated to understand when they're running
with a non-nightly compiler and disable all plugin-related tests. The only major
feature here is that the calls to fs::set_file_times were reimplemented
manually in the tests that Cargo has.
Cargo still requires a nightly compiler due to the stable features not having
made their way into the stable channel yet, but it will soon work on all of the
stable, beta, and nightly compilers once 1.1 is released!

r? @huonw
(rust_highfive has picked a reviewer for you, use r? to override)

r=me with @chris-morgan's comment addressed.

@bors: r=brson dab6e56

:hourglass: Testing commit dab6e56 with merge 832d9f6...

:broken_heart: Test failed - cargo-win-gnu-64

@bors: r=brson 8453a90

:hourglass: Testing commit 8453a90 with merge 3bfcc7b...

:broken_heart: Test failed - cargo-win-gnu-32

@bors: r=brson
On Tue, Jun 16, 2015 at 10:16 PM, bors notifications@github.com wrote:

[image: :broken_heart:] Test failed - cargo-win-gnu-32
http://buildbot.rust-lang.org/builders/cargo-win-gnu-32/builds/43
—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/cargo/pull/1712#issuecomment-112654027.

:pushpin: Commit 7c2d1a5 has been approved by brson

:hourglass: Testing commit 7c2d1a5 with merge 08199c0...

:broken_heart: Test failed - cargo-win-gnu-64

:pushpin: Commit 23762e4 has been approved by brson

@bors: r=brson
On Tue, Jun 16, 2015 at 10:30 PM, bors notifications@github.com wrote:

[image: :broken_heart:] Test failed - cargo-win-gnu-64
http://buildbot.rust-lang.org/builders/cargo-win-gnu-64/builds/46
—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/cargo/pull/1712#issuecomment-112655276.

:hourglass: Testing commit 23762e4 with merge 35c05ae...

:sunny: Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64

authors: alexcrichton bors brson rust-highfive


text:
add --no-vcs option to cargo package

If cargo package is run for a crate that is not version controlled in
a way that cargo expects, git2 will overreach upwards and grab a
irrelevant .git repo. This change adds --no-vcs as an option to
cargo package to prevent this.

r=me, but there are general concerns on introducing too many flags to cargo and also there's a soft feature freeze in effect, so I'm not sure if we should land this.
But the change itself makes sense and looks reasonable! 🙂

This isn't so much adding a feature as it is removing a feature that was introduced in an August commit. The latest cargo introduced this vcs behavior in cargo package and ended up breaking our continuous integration of Rust packages in Chrome OS. It's incredibly important that CI for rust packages works on Chrome OS, so I ask that you may an exception to the soft feature freeze. I would be happy to discuss this further, if need be.

@zachreizner, Do you happen to know what PR caused the problem? (You say it is from August so I thought you may know.) Can you make a reproducible example, so that we can track it down? Do you have more information on what problems the current behavior is causing you? Can you add a test to this PR?

The PR was #5886. I don't have a good example, but I will work on one if that helps.
The problem with the behavior of cargo package today is that it violates the portage ebuild sandbox used to verify that a package (in the linux package manage sense) is only using files inside of its own working directory during the build phase. The way the sandbox works is by checking what files get touched by the build process, rather than outright preventing such invalid access. I know this system sounds rather fragile, but it's important for saving headaches later down the line with non-reproducible builds. Also, every other build system is able to stay within its working directory, and I think cargo should be no different.

I think we should be able to fix this by pushing the check_repo_state call under opts.list (which early returns) and under if !opts.allow_dirty.  Wouldn't that fix your use cases @zachreizner?  Can anyone spot any drawbacks?

Soft echo that accompanying this the change with a test would be 🔝.

When you say under if !opts.allow_dirty, do you mean that if --allow-dirty is passed in, no vcs info checking will occur? If so, that seems like it would solve the issue.

Want to try a local build with that change to confirm?

Thanks for the PR @zachreizner! I think we're always up for taking PRs that fix bugs!
I would personally be inclined, though, to fix this perhaps not with an option to cargo publish but rather with better inference behavior on behalf of Cargo. This seems like a flag that would only be passed in pretty niche use cases, so it'd be best if we didn't have to add a new flag at all!
For example I think we could improve our inference and say something like:

Take the current package being published and its workspace root. The manifests of these two packages have a common path as an ancestor.
Walk up the filesystem looking for a git repository to at most that common ancestor, but look no further.

I think that would help prevent reaching too high in your case perhaps? (most crates are their own workspace so they wouldn't look much farther than that directory)

I apologize, but my analysis of the problem our build system was facing is slightly incorrect. The issue is actually that the ~/trunk/src/platform2 directory, which is where many of our Rust and non-Rust packages are placed, has a .git directory that looks like this:
~/trunk/src/platform2 $ ls -lh .git
-rw-r--r-- 1 zachr eng 1.2K Nov  8 16:45 COMMIT_EDITMSG
lrwxrwxrwx 1 zachr eng   48 Oct 30  2015 config -> ../../../.repo/projects/src/platform2.git/config
lrwxrwxrwx 1 zachr eng   67 Oct 30  2015 description -> ../../../.repo/project-objects/chromiumos/platform2.git/description
-rw-r--r-- 1 zachr eng  128 Oct  3 16:08 FETCH_HEAD
-rw-r--r-- 1 zachr eng   32 Nov  7 11:29 HEAD
lrwxrwxrwx 1 zachr eng   61 Oct 30  2015 hooks -> ../../../.repo/project-objects/chromiumos/platform2.git/hooks
-rw-r--r-- 1 zachr eng 573K Nov  8 16:45 index
lrwxrwxrwx 1 zachr eng   60 Oct 30  2015 info -> ../../../.repo/project-objects/chromiumos/platform2.git/info
lrwxrwxrwx 1 zachr eng   46 Oct 30  2015 logs -> ../../../.repo/projects/src/platform2.git/logs
-rw-r--r-- 1 zachr eng    0 Nov  8 16:45 MERGE_RR
lrwxrwxrwx 1 zachr eng   63 Oct 30  2015 objects -> ../../../.repo/project-objects/chromiumos/platform2.git/objects
-rw-r--r-- 1 zachr eng   41 Nov  7 11:29 ORIG_HEAD
lrwxrwxrwx 1 zachr eng   53 Oct 30  2015 packed-refs -> ../../../.repo/projects/src/platform2.git/packed-refs
lrwxrwxrwx 1 zachr eng   46 Oct 30  2015 refs -> ../../../.repo/projects/src/platform2.git/refs
lrwxrwxrwx 1 zachr eng   64 Oct 30  2015 rr-cache -> ../../../.repo/project-objects/chromiumos/platform2.git/rr-cache
lrwxrwxrwx 1 zachr eng   49 Oct 30  2015 shallow -> ../../../.repo/projects/src/platform2.git/shallow
lrwxrwxrwx 1 zachr eng   59 Oct 30  2015 svn -> ../../../.repo/project-objects/chromiumos/platform2.git/svn

All of those symlinks are outside the sandbox, which is what triggers our problem. Therefore anything that preempts searching inside of the .git directory prevents the sandbox violation. My original PR with --no-vcs does this, as would @dwijnand's suggestion to have allow_dirty preempt any vcs_info checking. @alexcrichton's suggestion to only search as high as the workspace and package's common ancestor would also prevent searching this .git directory, I think. Am I correct in assuming that the simple case for this hypothetical ceiling directory would be the same directory as where the package's Cargo.toml is?
For example, we have a package in ~/trunk/src/platform2/vm_tools/9s with a Cargo.toml file at ~/trunk/src/platform2/vm_tools/9s/Cargo.toml. Assuming no explicit workspace, the ceiling for searching for a .git directory is simply ~/trunk/src/platform2/vm_tools/9s. Does that sound reasonable?

If someone is publishing with allow_dirty and a dirty tree then what good is the cargo_vcs_info? So +1 for  reusing the allow_dirty flag.

Is there an error message available from cargo for the original issue, here?  Is it just that the found parent repo is in fact dirty?  I don't follow how #5886 (I authored) would have changed that behavior?
@Eh2406: specifically, if check_repo_state finds a repo that is dirty, then cargo_vcs_info is not generated.

Ok thanks for the explanation @zachreizner, makes sense that my previous suggestion wouldn't work. I think we can't say, though, that a git directory is only searched for in the Cargo.toml directory because crates are often located throughout a git repository (and aren't always in a workspace).
At this point the best solution may be to update cargo and/or git2 to respect env vars like GIT_CEILING_DIRECTORIES, which I believe is already a standard-ish env var in with git, and in this system I imagine y'all could configureGIT_CEILING_DIRECTORIES to be beneath the git root here.

Sorry I should also elaborate more as well. I would personally prefer to not add a new feature (flag) for this since it seems like a pretty niche feature. I'm trying to brainstorm other ideas we can adapt existing concepts and/or existing ideas to avoid adding a new feature/flag.
I'd personally be ok with the adaptation of --allow-dirty as well, it seems slightly odd to me but so do all the various routes here

it seems slightly odd to me but so do all the various routes here

given GIT_CEILING_DIRECTORIES is in the official docs it seems like the less ad-hoc solution.

LGTM. Invoking with --allow-dirty means that the state of the vcs is not relevant to what is being packaged, so it makes sense not to look at the vcs state.

Title has been updated. Do we want an update added to https://github.com/rust-lang/cargo/pull/6280#issue-229191337 as well?

Thanks @zachreizner!
@bors: r+

:pushpin: Commit fd5fb6e2dc4c6b06402d4c14df270edf6cd56b57 has been approved by dwijnand

:hourglass: Testing commit fd5fb6e2dc4c6b06402d4c14df270edf6cd56b57 with merge e70bccff8b3aee537d28dd14d4205df319e3260e...

:sunny: Test successful - status-appveyor, status-travis
Approved by: dwijnand
Pushing e70bccff8b3aee537d28dd14d4205df319e3260e to master...

authors: Eh2406 alexcrichton bors dekellum dtolnay dwijnand zachreizner


text:
Make clippy happy

It is already a reference.

r? @ehuss
(rust-highfive has picked a reviewer for you, use r? to override)

Thanks!
@bors r+

:pushpin: Commit 657a24bf7df6ded1f0ebe6115f93128fdfafb4b6 has been approved by ehuss

:hourglass: Testing commit 657a24bf7df6ded1f0ebe6115f93128fdfafb4b6 with merge e8855d69d614e679abd1b82a674b125ec046f5e8...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing e8855d69d614e679abd1b82a674b125ec046f5e8 to master...

authors: bors ehuss hi-rustin rust-highfive


text:
Support for discovering cross crate implementation of a Trait for types present in a foreign crates.

This idea came to my mind while opening my 19th tab for searching a implementation of the trait in my current crate I was working with, here is basically what I thought.
let's say you have a crate metrics, this crate has a amazing trait named Layer<R> and with some method present inside of it.
now let's say I wish to discover crates which implement this trait on it self, therefore instead of manually scrounging docs.rs maybe we have a tiny little button which helps us do that, directly from the page of the crate itself, in my understanding this can save redundant tab spawning as well.
Let me know what you guys think.

Thank you for the idea,
this sounds like #1467, or am I missing something?

Hi @syphar my initial idea & #1467 are pretty close, what I think would be amazing to have if it can indexed on the docs.rs server itself and also to show a distinct filtering regarding whether the crate who are implementing this have it implemented internally or is it public in on the object types of the crate.

That's a tough one, but both would depend on the same JSON processing & similar storage requirements, so I would propose we merge these.
Could you add a comment to #1467 description the additional feature idea? Then we can close this one.

moved the last point to #1467

authors: artech-git syphar

license: MIT


text:
Compatibility between 1.0 and 0.3 streams

This is a tracking issue on how to handle stream trait compatibility between 0.3 and 1.0.
I said that it's okay to use something like semver trick in #2335, but we need to investigate and consider whether it should actually be introduced or not.
Context
@tesaguri said in https://github.com/rust-lang/futures-rs/pull/2335#issuecomment-782517459

That could mean we don't ever publish a v1.0.0 of futures-core

Even if futures-core v0.3 decides to re-export std's Stream, futures-core can just publish a v1.0.0 release and apply the semver trick in a v0.3.x release, as long as the MSRV remains the same, so it does not need to stick to v0.3.x.

@taiki-e said in https://github.com/rust-lang/futures-rs/pull/2335#issuecomment-782619466

As for futures-core, I'm okay with using the tricks like that @Nemo157 and @tesaguri said. However, if the std Stream's signature becomes incompatible with futures 0.3 Stream, the 1.0 release will be breaking change and we will not introduce this trick.

If t-libs and wg-async-foundations decide to stabilize Stream with a different signature than futures 0.3 Stream, futures team can't do anything about it. Actually, in the first proposal by wg-async-foundations, it was an incompatible signature.

@taiki-e said in https://github.com/rust-lang/futures-rs/pull/2335#issuecomment-782872311

Well, as for semver tricks, rand used it and caused problems many times, so I can't guarantee that it will be done even if the trait signatures are exactly the same.
If that adversely affects users of 0.3, I don't want to use it.

cc @cramertj @Nemo157 @seanmonstar
FYI @yoshuawuyts @rust-lang/wg-async-foundations

Hey all-- I've been a bit behind on catching up here. I'm reading the comments, but I have a few thoughts.

Given that this decision is controversial, I think we should establish who makes the final decision here in case that becomes necessary. Given that this is a Rust project, it has to be a Rust team. I would call this a joint decision of @rust-lang/libs and @rust-lang/lang I believe it is probably @rust-lang/libs -- though in consultation with @rust-lang/lang, given how central Stream is.
That said, I think that before those teams weigh in, it would be appropriate for @rust-lang/wg-async-foundations to prepare a summary. I believe this should take the form of a Collaborative Summary Document. I volunteer to kick that off, it'll be a good way for me to get up to speed. Part of this document is a kind of "best case" pro and con, written in terms of the values we've established, so that will help the teams to make an ultimate decision. (Of course we may also come to a recommendation over the course of working on that.)
Finally, I can confirm that the semver story around futures-io has absolutely been a matter of consideration. I'm sorry @taiki-e if we gave the opposite impression! For example, if you skim the minutes from the Stream design meeting, you'll see that we talked about semver and the next method there.

As a meta point, improving the coordination around this crate has been lacking and is something we should change. I would like to incorporate the overall role and vision for the futures crate into the async vision doc process. @taiki-e or others, perhaps we can sync up on Zulip about what shape that might take?

Also, @taiki-e, thanks for the excellent summary!

Given that this is a Rust project, it has to be a Rust team. I would call this a joint decision of @rust-lang/libs and @rust-lang/lang, though probably more libs than lang.

Agreed.

I volunteer to kick that off

❤

I can confirm that the semver story around futures-io

Did you mean futures-core?

I'm sorry @taiki-e if we gave the opposite impression!

No problem, I'm happy to know that is my misunderstanding.

For example, if you skim the minutes from the Stream design meeting, you'll see that we talked about semver and the next method there.

I felt it's very optimistic and I didn't think it's something we could trust to be a blocker.

improving the coordination around this crate has been lacking and is something we should change.

Agreed.

@taiki-e or others, perhaps we can sync up on Zulip about what shape that might take?

Due to the time zone and work, I can't attend something like sync meetings, but I'm happy to attend any asynchronous discussions.

As far as I know, this is the only issue that has been controversial and not fully been resolved, except for release timing.
So, for other areas, we will proceed with the development of futures 0.4 as planned.
Ideally, at the timing of libs and lang have decided on this, all the other issues have already been resolved and we can just adjust the version number or apply something like a semver trick to release the next version. (Even if they decide to keep futures-core at 0.3 forever, it's very easy to adjust because we can just use the 0.3 branch.)
I merged #2335 without the approval of other maintainers because (in addition to what I said in #2335) I think the decision on this issue took a very long time and could very delay the release as in 0.3 if this issue blocks all other issues. If this issue blocks all other 0.4 work, I think they'll have to make a decision about it at least 6 months before stream stabilization.
Of course, if there are other controversial issues like this, I'm happy to treat them the same. But I don't think libs and lang's decisions are needed to make API decisions for utilities like futures-util and futures-channel.

I'd like to hash out the compatibility issues some here. Starting with adding Stream::next, which we considered adding as a provided method to the trait. Let me know if I'm off base here, I find these issues difficult to reason about!
Problems with adding Stream::next
I don't think adding Stream::next (either before or after stabilization) would technically break semver compatibility, but it can still cause major problems. Simply adding a provided method to a trait doesn't break semver compatibility. However, two things make this more complicated: the existing StreamExt::next method, and the re-export situation.
StreamExt
Adding Stream::next would break lots of code in practice because of method resolution ambiguity. This is a real problem, not only because of inconvenience, but because if we did this in a point release it could actually break your dependencies which you have no control over.
Mitigations
I recall there being some discussions with the lang team around adding "resolution helpers," probably as attributes, to resolve this problem. As I recall basic idea is that you can declare some traits/methods to be lower priority to resolve ambiguities.
So far I haven't seen a concrete proposal for this, but I think it would solve this issue completely. However, it does come at the cost of adding complexity to the language.
Re-exports
If the next method is added, that change could be mirrored in a point release of futures-core. The key point is that anyone using that method will have to depend on that version of futures-core if they want to avoid bumping their MSRV.
The problem is, if this developer is still using an old version of futures-core on a new version of rustc that has stabilized Stream, they will pick up the version from std and not notice any problem. Therefore they can fail to bump their version of futures-core. This would then break users of their crate who attempt to build it on older versions of rustc.
I'm not entirely sure how big of a deal this is. Downstream crate authors could catch it with their own testing on their advertised MSRV, and if the problem does happen it could be easily fixed in a point release. That said, it is worth getting in front of if we can.
Mitigations
Catching this case is tricky. We could consider adding a lint to the compiler directly for this case, but it would be a lot of work. We'd have to "taint" any use of Stream that went through a crate named futures and I don't know if the compiler is architected to do that.

One probably-bad idea
I was thinking that we could somehow leverage the method ambiguity error above. Since we're already reporting an error, it's easy to add a special case error message to remind them to bump their version of futures-core. But if we manage to make that error go away entirely, it wouldn't work :). It also isn't perfect in that they could ignore the error message, and it doesn't catch new uses of next (after removing the StreamExt import) that round trip through an old version of futures-core.

Another mitigation is to hold off on stabilization until Stream::next has been added to futures-core and a significant part of the ecosystem had already migrated to that version.

OK, I've created a dropbox paper document to use as a collaborative summary doc. I'm going to spend a bit of time filling it in, but I realize that I have a lot of catching up to do on the details here. I included some instructions in the doc.
@tmandry I'm not sure whether this discussion of stream compatibility belongs in the same doc or not? Maybe :)

Status update: I filled in what I see as the 'basic facts' of the situation in that doc. I'd love it if people would read it over and check if I've got things right. I have to stop for now but I'll circle back at some point. People can also feel free to continue adding things to the doc and I'll try to sort it out later -- if you want, create a new section with your name or something and dump thoughts in there.
Some things I think would be useful to add:

What are the options for resolving these sorts of conflicts?
Am I missing some implications for users?
What are the reasons to care or not care about the implications for users that we've listed?

Also, I'm now pretty sure that the content from @tmandry's comment belongs in there -- in particular, one thing I would note is that I think we expect to move more methods from StreamExt to Stream over time. If/when we start doing that, we hit the same problems we're discussing now, right?

authors: nikomatsakis taiki-e tmandry

repo: rust-lang/futures-rs


text:
Crates dependent on libgit2-sys fail to link when libiconv is installed via MacPorts

How to reproduce:

Use a machine running macOS 11 with MacPorts installed
Install libiconv using MacPorts: sudo port install libiconv
Note: many common ports depend on libiconv so it is usually installed indirectly
Build a crate which depends (directly or indirectly) on libgit2-sys e.g. cargo:git clone https://github.com/rust-lang/cargo.git
cd cargo
cargo build

Expected result:
The crate builds successfully
Actual result:

In my case cargo is cloned to /Users/david/Code/cargo
I believe this issue is not specific to the arm64 architecture

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-arch" "arm64" "-L" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/david/Code/cargo/target/debug/deps/cargo.13dqm6cx88ih8d7v.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.13fag48fin0k9e60.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.13k5sy4x5ct7uc76.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.13mvacfztkpqoulz.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.17o1oyr8zzw4fskw.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.17velqna0uus6jym.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1bqtvubbafsow4tm.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1bzcfj2o6vziubl8.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1cdjzrhuo6413him.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1d13nnm6m5msm11z.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1di4cbgimehpmvur.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1ewnbnxbu5269t71.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1fbsx00hgypemiqb.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1fpjo2ev3up3z6gx.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1gg1zbd89v1t343t.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1hi4rpkj556ckt0k.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1hk74un040a2hsy0.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1ihnus2jzs3rfv1l.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1j5a6o5uvbzlkp1.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1kbxkaaq5ilwuoyx.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1kg9hdnqq21l0urr.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1lpyrztjrjtk3ycn.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1nemwliycchkdlda.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1nz9dpxims4nycy1.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1o7da8olj20a0so5.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1obnebwavryx9c0x.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1oyvqq6952xmyzm0.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1ragwe75jk8j3pjj.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1sysxi7mk8x3vtf1.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1uu8ki05mmuhlzn9.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1v48v2pzmjcoe8cx.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1whvy6zbssdhcx31.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1xio4r50sbl2xg6g.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1y8i7tddclz230n0.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1ylxb1bv5h1gtqxd.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1zmudcy43srqyx7c.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.1zwvkzzugyuqtpjv.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.20w04wb3ctytwmqr.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.211m9001ij88m11d.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.21pxmmszxsjyk15l.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.22dqc0n30cgrwbj5.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.22loqaw7ofw714ki.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2381efbjop3fqyrz.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.23irw1fwh0nv3y20.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.23m46uvr0sodzm2s.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.24jrbumrns7sa91n.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.253zihf4kirdbdgb.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.26k4nt4071rddrx.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.26x25jd1vjfvjpgh.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.27w8ebjapmrr2d6s.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.295rue6tsjlrpcxs.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.29ns25yaadau3zs.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2ax8tl47s7wiut3b.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2bphaej1r91fga6d.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2c4xwrlu3y7ghtqu.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2di685r6i1vt06x2.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2g3xjtktswwkc0p3.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2jg1pb5mmw5i34u1.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2lq6oo0lz1fs1wzu.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2mtsyynqa8n5y1p5.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2o9fpint62fjruax.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2pmeiaf21k0ktxe5.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2rqdg19mew2myggo.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2rutq3pqp1ot0p14.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2sdln7x49b6s477r.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2ske7zf999vzx8as.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2ubj89dr4ikvgfoz.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2vl8dpolduynodi8.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2yambozehzla2gco.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2ywl5qfgnf235l2j.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.2zw6zuw86iqms8di.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.320nx8mhb6zg9i36.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.32dckb77scrnjbw0.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.330h2mhqj17cowfl.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.331i6cvncra615vq.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.336603t06bhesml3.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.33grf1n0e4hho7wz.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.35wiaubdbijrsf6m.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.35x3pyz4a1p4jdf6.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.36jb8awmgix4zbad.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.36tt0ut5j031wyy2.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.385h0ifdvl94nms1.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.38dnz1isw60tjy9a.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.39c7mpaauwer1wu3.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.39s6k2gtqserz8oy.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.39y2lb3o5tifi9qi.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3b894tf0sgg1qult.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3bjxbc3flhwdrpjo.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3bvrsd782v9luhiu.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3ccyhkvod9mcujf0.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3cjqcqczew2axko1.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3d7j41lvracrrux6.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3ehfnt537mx7v6rl.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3fog5tr939ulh7fp.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3hzfna0d6ahexocd.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3i6crh0a81s7dm5k.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3il040lzsqab1zt.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3iuwhfd3fy9v8w0g.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3khj6ejlqso8fyts.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3mb73z06adx8vyl9.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3mfmzlyaj1k6riha.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3o476lnowziaqnxr.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3o95dwd7defb2h8b.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3oqmfq2ol3ldz0z2.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3oqtjt3k87t1fk74.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3ozd4v0hj99p6zpx.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3pfvy7jvy3q94a8f.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3qpeq241tsask0jc.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3qqzvqi6pgz8xjgs.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3r83k55q6ch3bm2e.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3rnt4l9gsixx44d2.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3s0rs45d23r49266.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3u0uwp4urnpm5xdw.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3x6e328thza8wfcz.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3x6kpx8ajj8xpusq.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3xkleg3bak9eqjg.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3y17x74gv3y4nts6.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.3zlc39tcaya7imyn.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.41uc47v0micmodlk.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.421kpxpfl8qxi4qb.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.42ul3o21xupkw9s8.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.446r117o3d1ca6rp.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.44tfv3p7po3vy8gc.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.461zqqdn9anqhu78.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.462qhi6zg3zqykg5.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.46mtui0b29npi0ty.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.46rvdomu0cw04q6j.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.46x2uoseh1qtog4z.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.47eigf9j7jgmy5vb.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.47mxk42ag1ghnm6t.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.48730dwzridg9ng6.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.49fjbome75lbtwlw.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4a2z3amiys0zy7e3.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4ar4jfgxh09fddej.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4bcuhil4w9wutcdw.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4bg1aipmt8rvfgby.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4cg5t1iznnolmga9.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4d2xjyrz7yqqnpej.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4ddnhc10gt4w40ty.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4fq493q7ggub90ph.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4i5vsh13mx2dyf0d.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4izxsoa1e247sh8u.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4jad9bci3o3i5tpv.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4jkzsmu0qca16c5w.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4koajf9qnh22hcn2.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4mqcig9rm0iwfkkn.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4n8fbei6du63yvlv.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4ndhvlib49sqc1ev.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4o1prqtzdpahgb8f.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4o8mjzyd83lv82jh.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4t3aqqy4pcy9yfpu.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4tcc9426p5mkewin.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4thpi5mh4lo33kef.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4tmwv4vp33e1tc97.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4tr2ym0j4se7ahmk.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4vxk1amwlwjl0qzx.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4xy2i3hrao02zwo.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.4zozruz2a9pwyl1f.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.53jvmoa9ely7klx7.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.541drxc9a2t5ybkq.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.54yq9zz5y73wbq15.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.569x5hb3m6z8kgey.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.56vuaa0uxpiuoysc.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.56yfj6e0h4y25b8k.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.57x963ep5rstao5m.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.593vmnua2z9djt41.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.5a0rr3rmv5awnsac.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.5amryz7bu4bxygql.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.5bmf81929dho4pa7.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.5du92vsiirzgui0o.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.5fyek06cnoe16phe.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.5gmn65sc79x6g087.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.6zgkkciwlukq3bf.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.78qyax5t0500i1z.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.7dfu3dmufvgjavp.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.7fw60ns5t2xbgdj.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.7iwox8zwhlxo2nl.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.7jgryi55ctd5h0l.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.82z3c49rdr8l5c3.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.8nukepqo6n8ia9i.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.9fzthb2eohe07o8.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.9l2fes3rahgtewu.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.aa9rzjzh66i514g.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.dqdsiqe43afps6q.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.evjzvnssntc58d6.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.g7d6m8mdnaaz8s4.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.i4a068yn1iudw7t.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.ih8dm88a404n3jf.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.ikp431wwul8zlay.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.krmj722iqoqsl5g.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.lbj3o37hk0wen8w.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.lh3h9r0qe0tl7dl.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.m12p0snx90u8tv8.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.m17tbwhy5v97024.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.m6z7az2xt5h5dom.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.n7asbcgv0kv6gtf.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.qyuj4ev50uiutj1.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.s3092bd5ss58aou.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.sio6sv9xjo1k5z4.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.sjxxcy2f4q03yg9.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.sqr3xwogumap9ww.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.t2xf7dqk9tfmdmg.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.t72lzva1547enut.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.udebwomqu6legvf.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.wf5yfxfkh4ior53.rcgu.o" "/Users/david/Code/cargo/target/debug/deps/cargo.x1puqijaady3437.rcgu.o" "-o" "/Users/david/Code/cargo/target/debug/deps/cargo" "/Users/david/Code/cargo/target/debug/deps/cargo.4y519891yq70rrac.rcgu.o" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/david/Code/cargo/target/debug/deps" "-L" "/Library/Developer/CommandLineTools/usr/lib/clang/12.0.5/lib/darwin" "-L" "/Users/david/Code/cargo/target/debug/build/curl-sys-8ec4e424c1e11430/out/build" "-L" "/Users/david/Code/cargo/target/debug/build/libnghttp2-sys-26968c9ba23419c6/out/i/lib" "-L" "/Users/david/Code/cargo/target/debug/build/libgit2-sys-02bb81486a2685bf/out/build" "-L" "/Users/david/Code/cargo/target/debug/build/libssh2-sys-304cc5b9ab40f963/out/build" "-L" "/opt/local/lib" "-L" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/david/Code/cargo/target/debug/deps/libgit2_curl-48e6f2a3cbcc6c7f.rlib" "/Users/david/Code/cargo/target/debug/deps/libenv_logger-65ecff0d5f036d74.rlib" "/Users/david/Code/cargo/target/debug/deps/libcargo-ff94048c2ca20527.rlib" "/Users/david/Code/cargo/target/debug/deps/libhex-a204801606a897e7.rlib" "/Users/david/Code/cargo/target/debug/deps/libhome-c205c8e97b1e6c7c.rlib" "/Users/david/Code/cargo/target/debug/deps/libopener-2d19f21f46d6c438.rlib" "/Users/david/Code/cargo/target/debug/deps/libunicode_xid-06371275c58dd246.rlib" "/Users/david/Code/cargo/target/debug/deps/libim_rc-d757a71ad275ca3b.rlib" "/Users/david/Code/cargo/target/debug/deps/librand_xoshiro-31206bacb078ec35.rlib" "/Users/david/Code/cargo/target/debug/deps/librand_core-a257850599c782c7.rlib" "/Users/david/Code/cargo/target/debug/deps/libsized_chunks-2de1108384a5ef99.rlib" "/Users/david/Code/cargo/target/debug/deps/libbitmaps-77aabc852acc2637.rlib" "/Users/david/Code/cargo/target/debug/deps/libtypenum-493397f0a5c733e4.rlib" "/Users/david/Code/cargo/target/debug/deps/libtoml-5e390efef07fbc0c.rlib" "/Users/david/Code/cargo/target/debug/deps/libstrip_ansi_escapes-d3606b8f54b79cbb.rlib" "/Users/david/Code/cargo/target/debug/deps/libvte-270b97dc43c0f2a3.rlib" "/Users/david/Code/cargo/target/debug/deps/libutf8parse-fb2a496b73b575e4.rlib" "/Users/david/Code/cargo/target/debug/deps/libhumantime-490506bbd5603560.rlib" "/Users/david/Code/cargo/target/debug/deps/libnum_cpus-bdf0ded394e909fc.rlib" "/Users/david/Code/cargo/target/debug/deps/libserde_ignored-1aeb1b80c18100e2.rlib" "/Users/david/Code/cargo/target/debug/deps/libcrypto_hash-058ce49559109ffd.rlib" "/Users/david/Code/cargo/target/debug/deps/libhex-d4e9a461e5d6c691.rlib" "/Users/david/Code/cargo/target/debug/deps/libcommoncrypto-6e50e0aaf15c1c32.rlib" "/Users/david/Code/cargo/target/debug/deps/libcommoncrypto_sys-d01da9692474b6af.rlib" "/Users/david/Code/cargo/target/debug/deps/libshell_escape-6ced22cda46c2dff.rlib" "/Users/david/Code/cargo/target/debug/deps/libcore_foundation-42a29d5a0ab5aa86.rlib" "/Users/david/Code/cargo/target/debug/deps/libcore_foundation_sys-3d3e7488acc1f2cf.rlib" "/Users/david/Code/cargo/target/debug/deps/libclap-38c300e60319441f.rlib" "/Users/david/Code/cargo/target/debug/deps/libvec_map-26f397d03e5bd92b.rlib" "/Users/david/Code/cargo/target/debug/deps/libtextwrap-e2f8f053d14bee83.rlib" "/Users/david/Code/cargo/target/debug/deps/libunicode_width-f2a4e2d98c3b8467.rlib" "/Users/david/Code/cargo/target/debug/deps/libstrsim-fc88185f7489f6ba.rlib" "/Users/david/Code/cargo/target/debug/deps/libatty-df6817caa83edac8.rlib" "/Users/david/Code/cargo/target/debug/deps/libansi_term-5902dde1c48edbd0.rlib" "/Users/david/Code/cargo/target/debug/deps/libignore-3375918c853617de.rlib" "/Users/david/Code/cargo/target/debug/deps/libwalkdir-a59818ea75329318.rlib" "/Users/david/Code/cargo/target/debug/deps/libsame_file-c930306024bd679c.rlib" "/Users/david/Code/cargo/target/debug/deps/libglobset-a06a5f612f56be6a.rlib" "/Users/david/Code/cargo/target/debug/deps/libregex-8998a9ba9f666e18.rlib" "/Users/david/Code/cargo/target/debug/deps/libthread_local-2dc266936926fd78.rlib" "/Users/david/Code/cargo/target/debug/deps/libonce_cell-b11736acede769ed.rlib" "/Users/david/Code/cargo/target/debug/deps/libregex_syntax-130efbd2c2179e78.rlib" "/Users/david/Code/cargo/target/debug/deps/libfnv-f4608877e2778108.rlib" "/Users/david/Code/cargo/target/debug/deps/libbstr-0188ce7c653b8a9a.rlib" "/Users/david/Code/cargo/target/debug/deps/libaho_corasick-7d8c7615ea72d7b5.rlib" "/Users/david/Code/cargo/target/debug/deps/libmemchr-a4cfd5bf01ee3bf6.rlib" "/Users/david/Code/cargo/target/debug/deps/libcrates_io-0f3c40ea91159368.rlib" "/Users/david/Code/cargo/target/debug/deps/librustfix-6b99cca02c21fe65.rlib" "/Users/david/Code/cargo/target/debug/deps/libserde_json-c8874a6a36aaa867.rlib" "/Users/david/Code/cargo/target/debug/deps/libryu-b45f5b7d32e296e9.rlib" "/Users/david/Code/cargo/target/debug/deps/libitoa-4a2a17ac09666cf6.rlib" "/Users/david/Code/cargo/target/debug/deps/libtar-837ab3f2ae69b8f5.rlib" "/Users/david/Code/cargo/target/debug/deps/libflate2-c2f7256a345ef33b.rlib" "/Users/david/Code/cargo/target/debug/deps/libcrc32fast-dcf1473ca7229ec6.rlib" "/Users/david/Code/cargo/target/debug/deps/libgit2-74a6ffbf798fc1d5.rlib" "/Users/david/Code/cargo/target/debug/deps/liblibgit2_sys-2871391079a10068.rlib" "/Users/david/Code/cargo/target/debug/deps/liblibssh2_sys-56139f46197c53be.rlib" "/Users/david/Code/cargo/target/debug/deps/libopenssl_sys-378a642789bf7123.rlib" "/Users/david/Code/cargo/target/debug/deps/libbitflags-c4d6018c8c3d5b8d.rlib" "/Users/david/Code/cargo/target/debug/deps/libtempfile-ca5aeedb101e2675.rlib" "/Users/david/Code/cargo/target/debug/deps/librand-591f7f18dbd0ce25.rlib" "/Users/david/Code/cargo/target/debug/deps/librand_chacha-dec9ab5bc1981099.rlib" "/Users/david/Code/cargo/target/debug/deps/libppv_lite86-20a4652d4c36bdef.rlib" "/Users/david/Code/cargo/target/debug/deps/librand_core-6bc24f6b19929924.rlib" "/Users/david/Code/cargo/target/debug/deps/libgetrandom-f2ce991d4b4b7d09.rlib" "/Users/david/Code/cargo/target/debug/deps/libremove_dir_all-6d7be254349bbd5c.rlib" "/Users/david/Code/cargo/target/debug/deps/libglob-fc4fb76425fc757b.rlib" "/Users/david/Code/cargo/target/debug/deps/libtermcolor-0e53c09450884cb4.rlib" "/Users/david/Code/cargo/target/debug/deps/libcurl-639c1b969ba7d243.rlib" "/Users/david/Code/cargo/target/debug/deps/libsocket2-5c52e031b44a937f.rlib" "/Users/david/Code/cargo/target/debug/deps/libcurl_sys-e00511d200e6cecd.rlib" "/Users/david/Code/cargo/target/debug/deps/liblibz_sys-5c0e52dca696cafd.rlib" "/Users/david/Code/cargo/target/debug/deps/liblibnghttp2_sys-df0f499351e9bc89.rlib" "/Users/david/Code/cargo/target/debug/deps/libbytesize-e00ecfb0efe605ff.rlib" "/Users/david/Code/cargo/target/debug/deps/liburl-83b3b1cf630da360.rlib" "/Users/david/Code/cargo/target/debug/deps/libidna-ad80eee6e4f4917e.rlib" "/Users/david/Code/cargo/target/debug/deps/libunicode_normalization-d1f4ce876b0511d0.rlib" "/Users/david/Code/cargo/target/debug/deps/libtinyvec-87e6a49f9732d909.rlib" "/Users/david/Code/cargo/target/debug/deps/libtinyvec_macros-774320fa79233291.rlib" "/Users/david/Code/cargo/target/debug/deps/libunicode_bidi-01991b49c56c8451.rlib" "/Users/david/Code/cargo/target/debug/deps/libform_urlencoded-d08b840b91840ea4.rlib" "/Users/david/Code/cargo/target/debug/deps/libpercent_encoding-0c3f5ebb0c482512.rlib" "/Users/david/Code/cargo/target/debug/deps/libmatches-7c856e8a0da3524a.rlib" "/Users/david/Code/cargo/target/debug/deps/libcrossbeam_utils-431847b6a0e8e762.rlib" "/Users/david/Code/cargo/target/debug/deps/liblazy_static-3d78c4120713bc41.rlib" "/Users/david/Code/cargo/target/debug/deps/liblazycell-fee97b21968aebc6.rlib" "/Users/david/Code/cargo/target/debug/deps/libjobserver-aa766c90fbc71d52.rlib" "/Users/david/Code/cargo/target/debug/deps/libfiletime-1b935a2d785fef1c.rlib" "/Users/david/Code/cargo/target/debug/deps/liblibc-42e18dd4698ca1c9.rlib" "/Users/david/Code/cargo/target/debug/deps/libsemver-af5e730106bfcb90.rlib" "/Users/david/Code/cargo/target/debug/deps/libsemver_parser-b8ab0f17cf2af06c.rlib" "/Users/david/Code/cargo/target/debug/deps/libcargo_platform-c572c43e3b64c3cc.rlib" "/Users/david/Code/cargo/target/debug/deps/libserde-0cdfdd6b891a1a40.rlib" "/Users/david/Code/cargo/target/debug/deps/liblog-a07b5a70b9ae3207.rlib" "/Users/david/Code/cargo/target/debug/deps/libcfg_if-c64ee5e9237a32fe.rlib" "/Users/david/Code/cargo/target/debug/deps/libanyhow-2bbac1184b20c58e.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd-f6f9eec1635e636a.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-07bfff44bf62cf3f.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libobject-e3809bc8b111425e.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libaddr2line-33d64533e0aadcef.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libgimli-31e2a1400703b71d.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_demangle-71c15ba138da3496.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libhashbrown-2204c7cc9a01ef25.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_alloc-d6e5ece9c771a842.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libunwind-565bb23bb41bc8f6.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcfg_if-8895b042fd9d6a9d.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liblibc-cacf286c763defc4.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liballoc-348755f31f5f7b8f.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_core-00b1c5d56c8c46f3.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcore-59ed52fd3946b1c5.rlib" "/Users/david/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcompiler_builtins-d11cefe128d6b458.rlib" "-framework" "CoreFoundation" "-liconv" "-framework" "Security" "-framework" "CoreFoundation" "-lssl" "-lcrypto" "-lclang_rt.osx" "-framework" "Security" "-framework" "CoreFoundation" "-lz" "-lSystem" "-lresolv" "-lc" "-lm"
  = note: Undefined symbols for architecture arm64:
            "_iconv", referenced from:
                _git_path_iconv in liblibgit2_sys-2871391079a10068.rlib(path.o)
               (maybe you meant: _git_path_iconv_init_precompose, _git_path_iconv_clear , _git_path_iconv )
            "_iconv_close", referenced from:
                _git_path_iconv_clear in liblibgit2_sys-2871391079a10068.rlib(path.o)
            "_iconv_open", referenced from:
                _git_path_iconv_init_precompose in liblibgit2_sys-2871391079a10068.rlib(path.o)
          ld: symbol(s) not found for architecture arm64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Additional notes:
This is a reopening of #180 which has started occurring again on macOS 11, due to the following change:

According to the macOS Big Sur 11 Beta Release Notes, "the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem."

This presumably causes the libiconv from MacPorts to take priority over the built-in one, as the built-in one is no longer provided in /usr/lib (which is prioritised over /opt/local/lib).

This happens because of the name mangling that iconv does when installed in "third party" mode, such as via MacPorts. Symbols like _iconv_open become _libiconv_open:
$ nm -gU /opt/local/lib/libiconv.dylib
00000000000fc0a8 D __libiconv_version
0000000000005950 T _iconv_canonicalize
0000000000005168 T _libiconv
000000000000518c T _libiconv_close
0000000000004150 T _libiconv_open
00000000000051a4 T _libiconv_open_into
000000000001a344 T _libiconv_set_relocation_prefix
00000000000055a0 T _libiconvctl
00000000000056d4 T _libiconvlist

Your presumption of why the issue happens seems to be correct — because there's no libiconv.dylib in /usr/lib, the MacPorts one is used, but it doesn't have the right names.
However, the root cause seems to be that the headers from the system iconv are still being used. In /opt/local/include/iconv.h you'll see things like...
#ifndef LIBICONV_PLUG
#define iconv_open libiconv_open
#endif

... which would cause the correct symbols to be used. So if we can get libgit2-sys to use the iconv.h installed by MacPorts as well, all should be fine.

And, indeed, sudo mkdir /opt/local/include/iconv && sudo cp /opt/local/include/iconv.h /opt/local/include/iconv/ and then building something that depends on libgit2 with CFLAGS=-I/opt/local/include/iconv works fine.

So if we can get libgit2-sys to use the iconv.h installed by MacPorts as well, all should be fine.

Or perhaps /opt/local shouldn't be included in the header search paths? That way the compiler would find the dylib, rather than a different one taking priority - I recall from a MacPorts trac issue (possibly this one but I think there was another that I can't find) that MacPorts developers consider it incorrect for other software to use its search paths.

Or perhaps /opt/local shouldn't be included in the header search paths?

Assume you mean library search paths, since the problem seems to be that the library from /opt/local is being picked up whereas the headers from /opt/local are not.
and indeed, the compiler is being invoked with -L /opt/local/lib. I think it has to be, though, because it finds libgit2 and libssh2 there.

Hi. Same here. I have macos ventura.
error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/Users/lkostka/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/bin:/Users/lkostka/Library/Python/3.11/bin:/opt/local/bin:/Users/lkostka/.cargo/bin:/Users/lkostka/.local/bin:/usr/local/bin:/opt/homebrew/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/usr/local/MacGPG2/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands" VSLANG="1033" ZERO_AR_DATE="1" "cc" "-arch" "arm64" "/var/folders/s8/jp4cwfy177d6xwvnrhrhhs800000gn/T/rustcwct8IN/symbols.o" "/var/folders/s8/jp4cwfy177d6xwvnrhrhhs800000gn/T/cargo-install2VA7FA/release/deps/cargo_generate-43ea65447aaa583a.cargo_generate.e0d7671d71a691c6-cgu.1.rcgu.o" "-L" "/var/folders/s8/jp4cwfy177d6xwvnrhrhhs800000gn/T/cargo-install2VA7FA/release/deps" "-L" "/var/folders/s8/jp4cwfy177d6xwvnrhrhhs800000gn/T/cargo-install2VA7FA/release/build/libgit2-sys-ff5da361e4a43d27/out/build" "-L" "/var/folders/s8/jp4cwfy177d6xwvnrhrhhs800000gn/T/cargo-install2VA7FA/release/build/libssh2-sys-837b7a8e53f1c04b/out/build" "-L" "/opt/local/lib" "-L" "/opt/local/lib" "-L" "/Users/lkostka/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/var/folders/s8/jp4cwfy177d6xwvnrhrhhs800000gn/T/rustcwct8IN/liblibgit2_sys-224ffa3f27bcfc19.rlib" "/var/folders/s8/jp4cwfy177d6xwvnrhrhhs800000gn/T/rustcwct8IN/liblibssh2_sys-38639995701abcf6.rlib" "/Users/lkostka/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcompiler_builtins-7bc3106ba9bea571.rlib" "-liconv" "-framework" "Security" "-framework" "CoreFoundation" "-lssl" "-lcrypto" "-lz" "-liconv" "-lSystem" "-lc" "-lm" "-L" "/Users/lkostka/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "-o" "/var/folders/s8/jp4cwfy177d6xwvnrhrhhs800000gn/T/cargo-install2VA7FA/release/deps/cargo_generate-43ea65447aaa583a" "-Wl,-dead_strip" "-nodefaultlibs"
  = note: ld: warning: ignoring duplicate libraries: '-liconv'
          ld: warning: no platform load command found in '/private/var/folders/s8/jp4cwfy177d6xwvnrhrhhs800000gn/T/rustcwct8IN/symbols.o', assuming: macOS
          ld: Undefined symbols:
            _iconv, referenced from:
                _git_fs_path_iconv in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
                _git_fs_path_iconv in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
                _git_fs_path_iconv in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
                _git_fs_path_iconv in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
                _git_fs_path_iconv in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
            _iconv_close, referenced from:
                _git_fs_path_direach in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
                _git_fs_path_iconv_clear in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
                _git_fs_path_diriter_free in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
                _git_fs_path_dirload in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
            _iconv_open, referenced from:
                _git_fs_path_direach in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
                _git_fs_path_iconv_init_precompose in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
                _git_fs_path_diriter_init in liblibgit2_sys-224ffa3f27bcfc19.rlib[112](fs_path.o)
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: could not compile `cargo-generate` (bin "cargo-generate") due to previous error
error: failed to compile `cargo-generate v0.18.4`, intermediate artifacts can be found at `/var/folders/s8/jp4cwfy177d6xwvnrhrhhs800000gn/T/cargo-install2VA7FA`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

Not sure if this is thought to be a rust/libgit2-sys or macports problem, but I just encountered it compiling a rust project exactly as described above. I have macports, libiconv from there, and the same duplicate library, incorrect header, (not finding the macports lib, undefined symbols). This is on Sonoma 14.2.1 (23C71),  with just updated macports and rust.

authors: davidbailey00 eejd jbg luqasz valerie-makes


text:
Remove myself from clippy's highfive rotation.

I'm currently quite busy with my bachelor thesis, and new PR assignments are sadly a great way to procrastinate. Therefore, I'm removing myself from the Clippy rotation for a bit until I have more time again, which should be at the end of February.  I'll try to complete my current assignments, and I'm open for review requests as usual.

r? @Mark-Simulacrum

repo: rust-lang/highfive


text:
add shm support for NetBSD and OpenBSD

initial work from @landryb for OpenBSD, various fixes and NetBSD support from me.
Fixes #1585
shm support is need for firefox building (for slice-deque)
cc @jakllsch @ryoon for NetBSD

r? @gnzlbg
(rust_highfive has picked a reviewer for you, use r? to override)

@bors: r+

:pushpin: Commit 487b454d9f8c73b6a611d85d1e7d6820fece9938 has been approved by gnzlbg

@bors p=100

:hourglass: Testing commit 487b454d9f8c73b6a611d85d1e7d6820fece9938 with merge 5e5c1ee62a52558dee08984bdc3811c6e0072219...

:sunny: Test successful - checks-cirrus-freebsd-10, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, status-azure
Approved by: gnzlbg
Pushing 5e5c1ee62a52558dee08984bdc3811c6e0072219 to master...

authors: bors gnzlbg rust-highfive semarie

repo: rust-lang/libc


text:
build.rs: print rustc stderr if exit status != 0

I was trying to run benchmarks locally with rustc-perf and found that many of them failed to build with a message from libc's build.rs "Failed to get rustc version." I made this change locally to help debug, and I think it would be generally useful. In my case it quickly revealed that rustc was failing to find libLLVM and so rustc --version was emitting nothing on stdout.
I think this may have been part of what was intended with #3000 and might help debug https://github.com/rust-lang/crater/issues/663.

@bors r+

:hourglass: Testing commit 88e27b8df27d0aaa1ade562b01224cdfd6ead8d8 with merge 557f644b3ce773ea4f8e0b089d988d81c735206a...

:broken_heart: Test failed - checks-actions

@bors r+

:pushpin: Commit 52808cef25e8404488e5e8dec9330c90b59df6d0 has been approved by JohnTitor
It is now in the queue for this repository.

:hourglass: Testing commit 52808cef25e8404488e5e8dec9330c90b59df6d0 with merge f3d760791ec35a056de43495dfc03873d150ef83...

:broken_heart: Test failed - checks-actions

Note that you saw the build on PRs, not bors. The bors' build is here: https://cirrus-ci.com/build/5602401026048000
The FreeBSD failure happens on your PR because your branch is old, it's fixed on master so rebasing should resolve it.
The actual error is here (you can find the link from bors comment): https://github.com/rust-lang/libc/actions/runs/4601182601/jobs/8128728585#step:4:237
It's a network failure which means we should: @bors retry

:hourglass: Testing commit 52808cef25e8404488e5e8dec9330c90b59df6d0 with merge b9f037292b144a416a454ca457c6d6f94662a59e...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing b9f037292b144a416a454ca457c6d6f94662a59e to master...

authors: JohnTitor bors jsha