Panic when library specified via upgrade command is not upgradable

[per1234]

Describe the problem

Individual libraries can be specified for upgrade via the arguments to the arduino-cli lib upgrade command.

🐛 If the library is not upgradable, either due to already being at the latest version, or else due to not being installed, Arduino CLI panics.

To reproduce

$ arduino-cli version
arduino-cli.exe  Version: git-snapshot Commit: 3cd782d6 Date: 2022-09-07T17:10:43Z

Upgrade library already at latest version

$ arduino-cli lib install Servo
Downloading [email protected]...
[email protected] already downloaded
Installing [email protected]...
Installed [email protected]

$ arduino-cli lib upgrade Servo
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x8 pc=0xa73ea5]

goroutine 1 [running]:
github.com/arduino/arduino-cli/commands/lib.upgrade(0x163d018, {0xc00244bcf0, 0x1, 0xc0000360f0}, 0x5, 0xc00244bcf8)
        E:/electronics/git-nobackup/arduino-cli/commands/lib/upgrade.go:61 +0x65
github.com/arduino/arduino-cli/commands/lib.LibraryUpgrade({0xc000150770, 0x4}, 0xc0044023c0, 0x1, 0x1)
        E:/electronics/git-nobackup/arduino-cli/commands/lib/upgrade.go:55 +0x9a
github.com/arduino/arduino-cli/cli/lib.runUpgradeCommand(0xc000363b80, {0xc00027bb20, 0x1, 0x1})
        E:/electronics/git-nobackup/arduino-cli/cli/lib/upgrade.go:60 +0x2eb
github.com/spf13/cobra.(*Command).execute(0xc000363b80, {0xc00027bb00, 0x1, 0x1})
        C:/Users/per/go/pkg/mod/github.com/spf13/[email protected]/command.go:860 +0x5f8
github.com/spf13/cobra.(*Command).ExecuteC(0xc000269900)
        C:/Users/per/go/pkg/mod/github.com/spf13/[email protected]/command.go:974 +0x3bc
github.com/spf13/cobra.(*Command).Execute(...)
        C:/Users/per/go/pkg/mod/github.com/spf13/[email protected]/command.go:902
main.main()
        E:/electronics/git-nobackup/arduino-cli/main.go:31 +0x77

🐛 The command panicked even though this operation should simply exit with status 0

Upgrade library that is not installed

$ arduino-cli lib uninstall Servo
Uninstalling [email protected]...

$ arduino-cli lib upgrade Servo
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x8 pc=0xa73ea5]

goroutine 1 [running]:
github.com/arduino/arduino-cli/commands/lib.upgrade(0x163d018, {0xc0024adcf0, 0x1, 0xc0000360f0}, 0x5, 0xc0024adcf8)
        E:/electronics/git-nobackup/arduino-cli/commands/lib/upgrade.go:61 +0x65
github.com/arduino/arduino-cli/commands/lib.LibraryUpgrade({0xc0000d0770, 0x4}, 0xc00437e3c0, 0x1, 0x1)
        E:/electronics/git-nobackup/arduino-cli/commands/lib/upgrade.go:55 +0x9a
github.com/arduino/arduino-cli/cli/lib.runUpgradeCommand(0xc0002ec000, {0xc0001fdb30, 0x1, 0x1})
        E:/electronics/git-nobackup/arduino-cli/cli/lib/upgrade.go:60 +0x2eb
github.com/spf13/cobra.(*Command).execute(0xc0002ec000, {0xc0001fdb10, 0x1, 0x1})
        C:/Users/per/go/pkg/mod/github.com/spf13/[email protected]/command.go:860 +0x5f8
github.com/spf13/cobra.(*Command).ExecuteC(0xc0001edb80)
        C:/Users/per/go/pkg/mod/github.com/spf13/[email protected]/command.go:974 +0x3bc
github.com/spf13/cobra.(*Command).Execute(...)
        C:/Users/per/go/pkg/mod/github.com/spf13/[email protected]/command.go:902
main.main()
        E:/electronics/git-nobackup/arduino-cli/main.go:31 +0x77

🐛 The command panicked instead of clearly communicating the problem to the user.

Expected behavior

Arduino CLI only panics on unexpected (i.e., caused by a bug in the Arduino CLI codebase) failures. Any failure that can result from normal (even if incorrect) usage should be handled gracefully.

Arduino CLI version

3cd782d

Operating system

Windows

Operating system version

Windows 10

Additional context

I bisected the regression to 276b0cc

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the nightly build
• My report contains all necessary details