midl does not, and this would result in redefinition errors.
An equivalent (and arguably a bit more declarative) way to do this would be to
keep track in the parser whether a type or typedef statement is actually a
definition or not, and record that information in the statement_t. However, this
would require passing additional information alongside the type_t from each
relevant bison rule, which would thrash a lot of code.
This improves error reporting for the following IDL:
interface apple;
[uuid(12345678-1234-1234-1234-123456654321)]
interface apple {void func(void);}
[uuid(12345678-1234-1234-1234-123456654321)]
interface apple {void func(void);}
Previously widl would report:
test2.idl:19:34: error: type apple already defined at test2.idl:2
This changes it to refer to line 5, where the interface is actually defined.
E.g. in cases like
typedef int apple;
struct apple { ... };
allow subsequently using "struct apple" in future expressions.
Note that this already worked for UDT definitions (so the above example by
itself was legal in widl), but any attempt to use the defined type would result
in a syntax error.
I would like to reuse this build image for the Wine Mono CI
process (so that I don't have to separately maintain an image
that can run current Wine), but I need unzip to download and
extract artifacts from Wine's CI process.
This allows while unmangling:
- to avoid considering them as "real" datatypes in other contexts
- to handle better void (which is only supported as single argument
in function args list, while is a fully acceptable datatype
in template args list)
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
This makes builds reproducible, and matches the current MIDL behavior
(except that MIDL's string representation will vary with the build machine
timezone).
This patch fixes a regression in comparison with SLTG generator in wine-staging,
and allows oleview.exe from PSDK correctly load SLTG typelib generated by widl.
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
It looks like the lowest bit in the param name offset actually indicates
whether type description follows the name, and since the name offsets are
always aligned that makes sense.
This makes oleview.exe from PSDK running under Windows7 correctly show mix
of different very complex and relatively simple type descriptions generated
by widl's SLTG generator.
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
