envconfig: fix unhandled exception when cross-file lacks required keys

[XueSongTap]

Problem

When users forget to specify the required endian parameter in a cross-compilation configuration file, Meson currently throws an unhandled KeyError exception. This creates confusion as the error message doesn't clearly indicate what's missing, and instead suggests that this is a Meson bug that should be reported.

Solution

Modified the condition check in the MachineInfo.from_literal method from:

if set(literal) < minimum_literal:

to:

if minimum_literal - set(literal):

This ensures that when mandatory fields are missing, users receive a clear error message explicitly stating which fields are missing, rather than encountering an unhandled exception.

Related Issue

Fixes #14385

[bonzini]

Thanks for the nice commit message! The change is fine but if you want to add a unit test, it would be nice to have.

[eli-schwartz]

Can you update the commit message to mention that this regressed in commit b0d2a92

The commit message doesn't really explain why this is a fix (the context from that commit will help, and the comment I left on the linked ticket). This will make it hard to tell from the commit log, why the change was made.

[XueSongTap]

@eli-schwartz Thank you for your feedback. I've amended the commit message to include the information about regression in commit b0d2a92 and provided more context on why this fix works.

I've force-pushed the amended commit with the updated message. Could you please review and confirm if the commit message is now acceptable?

Once we agree on the commit message, I plan to add a separate commit with unit tests as suggested by @bonzini.

[eli-schwartz]

Nit:

After adding optional keys, minimum_literal contained non-required optional keys,

This isn't really true. The minimum (required) literal doesn't contain non required optional keys, that's why it can still be used in the fix. But the previous check was that the provided keys were a strict subset of the minimum required keys.

The strict subset logic broke down once the provided keys aren't a strict subset anymore, but an overlapping set with disjoint elements on both sides of the comparison.

Rewriting the logic to use "present in required but not present in provided" fixed that, and in effect removed the accidental implicit check "and not any {{ present in provided but not present in required }}"

[XueSongTap]

@eli-schwartz Thank you for the feedback. I've updated the commit message to more accurately reflect the technical nature of the issue:

The revised message now properly explains that:

1. The problem stemmed from a change in the set relationship - from "strict subset" to "overlapping sets with disjoint elements"
2. The original check (set(literal) < minimum_literal) was validating that provided keys were a strict subset of required keys
3. The new check (minimum_literal - set(literal)) specifically identifies keys that are "present in required but not present in provided"
4. This change also removes the implicit requirement that prohibited additional keys in the provided configuration

This better reflects the actual fix implemented, which addresses the logical issue where validation failed when dealing with overlapping key sets instead of strict subsets.

[eli-schwartz]

Thanks, lgtm.