Eric Blake <ebl...@redhat.com> writes: > On 03/08/2016 09:46 AM, Markus Armbruster wrote: >> Eric Blake <ebl...@redhat.com> writes: >> >>> Every non-implicit entity is associated with an 'info' >>> dictionary, but it is not easy to reverse-engineer the name of >>> the top-most entity associated with that 'info'. Our use of >>> 'case_whitelist' (added in commit 893e1f2) is thus currently >>> tied to the owner of a member instead; but as the previous patch >>> showed with CpuInfo, this requires whitelist exceptions to know >>> how an implicit name will be generated. >> >> Why is that a problem? > > Not necessarily a bad problem, but a bit annoying. If a developer > modifies a .json file and adds an improper name, then they will get an > error message that tells them that they need to fix their naming > conventions (hmm, the error message doesn't even point them to the > whitelist - see args-member-case.err).
I'd consider that a feature :) I don't want anyone adding to that white list. > If the developer figures out > that the whitelist will let them avoid the error, they still have to > figure _what_ name to add to the whitelist, and without this patch, they > have to determine the generated name for the implicit struct Still feature... > (which may > not be constant, since we are discussing about alternative names earlier > in the series other than something that flattens to a public 'struct > _obj_...' in violation of file-local naming scope). Whoever messes with the generated names gets to update the whitelist. > The goal is thus to > make the whitelist tied only to names mentioned in the .json file, > rather than dragging generated implicit names into the mix. > > But it is cosmetic; we could live without the patch and stick to > generated names in the whitelist, just as easily. Let's drop this patch. If we find a truly compelling use for info['name'] later, we can revisit it if you like, because then it's almost free. [...]
