The same can be said for running commands with sudo (which is something recommended quite often on these forums without any mention of security risk). The only difference is: the authentication for sudo expires after 15 minutes by default, while with --sudoloop, the authentication remains active throughout the entirety of the package prep and install (which could be more than 15 minutes). Granted, that should be kept in mind if you plan to walk away and don't trust the people around you.
(If you're suggesting that --sudoloop remains running indefinitely after cancelling the install, that's both a security issue and a bug that should be reported upstream.)
However, I'll remove it, since it's not needed in this instance when you pass the --nocheck flag (unless you have an extremely old and slow computer, where 2 minute tasks take longer than 15 minutes, in which case you'd just have to watch the install and enter your password when necessary).
That is inaccurate. From makepkg:
--nocheck Do not run the check() function in the PKGBUILD
Which, in the case of libc++ and libc++abi means the following won't be run:
This seems to walk through various compiler functions to make sure they are there and working (correct me if I'm wrong). These are not needed for the build, and already confirmed working on a fresh install of Manjaro. If the build doesn't go correctly, then this could potentially be used to debug what didn't build properly (specifically, by checking if required compiler functions are not available)
As previously pointed out it doesn't...the reason those steps fail is the same reason you can't just use the pamac GUI to install discord. This is what happens when you follow those directions on a fresh install of Manjaro:
$ pamac build discord
To install (7):
compiler-rt 6.0.1-2 2.0 MB
clang 6.0.1-2 14.9 MB
jsoncpp 1.8.4-2 1.1 MB
libuv 1.23.0-1 191.2 kB
rhash 1.3.6-1 115.4 kB
cmake 3.12.1-1 6.3 MB
ninja 1.8.2-1 94.4 kB
To build (3):
Total download size: 24.8 MB
Total installed size: 146.1 MB
Commit transaction ? [y/N] y
llvm-6.0.1.src.tar.xz ... Passed
llvm-6.0.1.src.tar.xz.sig ... Skipped
libcxx-6.0.1.src.tar.xz ... Passed
libcxx-6.0.1.src.tar.xz.sig ... Skipped
libcxxabi-6.0.1.src.tar.xz ... Passed
libcxxabi-6.0.1.src.tar.xz.sig ... Skipped
==> Verifying source file signatures with gpg...
llvm-6.0.1.src.tar.xz ... FAILED (unknown public key A2C794A986419D8A)
libcxx-6.0.1.src.tar.xz ... FAILED (unknown public key A2C794A986419D8A)
libcxxabi-6.0.1.src.tar.xz ... FAILED (unknown public key A2C794A986419D8A)
==> ERROR: One or more PGP signatures could not be verified!
This is a frequent error message and covered in the FAQ. And yet the forums get complaints about this fairly frequently. No harm in mentioning this expected error, so people don't think they did something wrong when they follow your instructions.
The security concern of automatically importing unknown PGP keys is also why I provided the alternative of using the flatpak package instead. Best of both worlds: no potential security concerns of trusting unknown PGP keys, and no issues expected during the install process.