Only the last constructor is returned from .normalized_method_names() regardless of argument

[tabatkins]

Given the following IDL:

interface OfflineAudioContext : BaseAudioContext {
	constructor(OfflineAudioContextOptions contextOptions);
	constructor(unsigned long numberOfChannels, unsigned long length, float sampleRate);
};

If I parse it, then call widl.normalized_method_names("constructor()"), I get only one method name returned - the latter. Even if I'm more specific and call it with "constructor(contextOptions)", it returns the latter.

If I swap the order of the constructors it changes which is returned, so it's definitely some "last wins" thing going on accidentally.

However, if I call .find_all("constructor()"), I get both constructs, so they're definitely both around. But if I then call .find_all("OfflineAudioContext/constructor(contextOptions)") I also get both constructs, so it's not discriminating properly somehow.

(This is messing up some code in Bikeshed that tries to normalize a constructor/method name, then call .find() to get the corresponding construct and do some stuff with its arguments. Since it's returning the wrong constructor, it fails to find the expected arguments and complains a bunch!)

(I haven't yet checked if this affects all methods, or just constructors.)

[plinss]

So normalized_method_names has two behaviors. If you pass in a method definition (including arguments) it only looks at that and computes the possible variations based on the passed arguments.

If you just pass a method name, it searches for matching methods.

So if you call widl.normalized_method_names('constructor') (or widl.normalized_method_names('constructor', 'OfflineAudioContext') to restrict the search to the passed interface) you get the result you're expecting.

For the second issue, find_all doesn't currently filter by passed arguments (at least not in argument syntax), for your example, it only looks for members of 'OfflineAudioContext' named 'constructor'. You could extend the path to 'OfflineAudioContext/constructor/contextOptions', but that'll find the argument, which you could then call .parent on to get the constructor.

Do you need find_all to filter by arguments? That could be added...

[Kangz]

We are hitting a similar issue with the WebGPU specification when using Bikeshed and I traced it to this issue. My understanding is that Bikeshed uses find in that specific case and that would need to handle arguments, but find_all would probably need the same logic. Another couple example names are:

• GPUProgrammablePassEncoder/setBindGroup(index, bindGroup, dynamicOffsets)
• GPUProgrammablePassEncoder/setBindGroup(index, bindgroup, dynamicOffsetsData, dynamicOffsetsDataStart, dynamicOffsetsDataLength)

Looking at Parser.find's code, it's not immediately clear how this could be fixed.