LGTM

A few things:

1. This has conflicts due to Restructure how devices are created and automatically cleaned up. #1035 and needs to be updated
2. Wouldn't we also need a change in api-query.cpp to not abort after calling initializeDevices? This might be something that changed since Restructure how devices are created and automatically cleaned up. #1035
3. The commit message here could be significantly simplified, which would help make it clear what this does. Commit messages shouldn't repeat every change that a commit will make, but instead focus on pointing out why the change is being made. Here, it would suffice to point out the problem (we quit after each device) and the high level of how we're fixing it (collect the errors, report them, and continue on).

2. Wouldn't we also need a change in api-query.cpp to not abort after calling initializeDevices? This might be something that changed since Restructure how devices are created and automatically cleaned up. #1035

Yup, the original claim that Device::initialize() doesn't bail on error no longer holds true, so the flow had to be rewritten slightly to still print errors but not return them out of initializeDevices().

3. The commit message here could be significantly simplified, which would help make it clear what this does. Commit messages shouldn't repeat every change that a commit will make, but instead focus on pointing out why the change is being made. Here, it would suffice to point out the problem (we quit after each device) and the high level of how we're fixing it (collect the errors, report them, and continue on).

@bogner just to make sure we're talking about the same commit message:

Device::initialize() returns early when any backend fails to initialize, preventing subsequent backends from being discovered. For example, a Vulkan initialization failure (e.g. VK_ERROR_INCOMPATIBLE_DRIVER when MoltenVK is not installed) blocks Metal device discovery on macOS.

Collect backend initialization errors with joinErrors() and return them together instead. Also make lit.cfg.py resilient to an empty device list from api-query.

This explains why something is wrong together with an example case of when that has an effect (Vulkan init on MacOS), followed by how it was fixed (using joinError(), and the drive-by note aboutlit.cfg.py not allowing empty yaml lists initially).

Is that still too much?

@bogner just to make sure we're talking about the same commit message:

Device::initialize() returns early when any backend fails to initialize, preventing subsequent backends from being discovered. For example, a Vulkan initialization failure (e.g. VK_ERROR_INCOMPATIBLE_DRIVER when MoltenVK is not installed) blocks Metal device discovery on macOS.
Collect backend initialization errors with joinErrors() and return them together instead. Also make lit.cfg.py resilient to an empty device list from api-query.

This explains why something is wrong together with an example case of when that has an effect (Vulkan init on MacOS), followed by how it was fixed (using joinError(), and the drive-by note aboutlit.cfg.py not allowing empty yaml lists initially).

Is that still too much?

I was looking in the wrong place (this was before our other conversation about PR desciptions matching commit messages). This does look much better. I do still find this a little verbose where it goes into listing the specific APIs that its using, but that's mostly a matter of taste.

Would dropping with joinErrors() solve that? It doesn't seem to mention any other APIs being used, only APIs being changed (Device::initialize(), lit.cfg.py, and the example about VK_ERROR_INCOMPATIBLE_DRIVER being triggered without MoltenVK).