IDL: restructure logic handling registration of methods
Methods are registered in one of three different ways on an interface's
prototype object;
1) via an entry in a static array,
2) via custom code in the interface's configure{{class}}Template(), or
3) via custom code in its installPerContextEnabledMethods();
depending on whether the method is static and its extended attributes.
E.g., [RuntimeEnabled] leads to 2 and [PerContextEnabled] leads to 3.
The old method of setting flags on each method signalling how it ought
to be registered, and filtering the single list of methods in the
templates based on these flags, was becoming seriously unwieldy for
complicated cases such as overloaded methods.
To address this, change the logic to instead filter methods into three
lists in the scripts, one for each type of registration. The templates
simply use a different list of methods when generating the different
code blocks.
For overloaded methods, take the attributes of all overloads into
account, instead of looking at only one of them (the first in IDL file
order, as it were.)
Also introduce a compile-time check that a set of overloaded methods
doesn't contain methods with conflicting extended attributes that affect
how the method ought to be registered.
BUG=339000
Review URL: https://codereview.chromium.org/328663003
git-svn-id: svn://svn.chromium.org/blink/trunk@176017 bbb929c8-8fbe-4397-9dbb-9b2b20218538
5 files changed
