[Bug 302] `function` type UDA postfixes not allowed

[gdc-bugzilla at gdcproject.org]

https://bugzilla.gdcproject.org/show_bug.cgi?id=302

--- Comment #6 from Iain Buclaw <ibuclaw at gdcproject.org> ---
(In reply to ARaspiK from comment #5)
> Perhaps a new extern(MS_ABI) or similar is needed. After all, the spec has
> declared extern(Windows) to be the same as extern(C) except in case of
> 32-bit, where it then uses stdcall.
> 

I'm not sure if it does warrant a new calling convention, but I can see that
there needs to be more careful handling of gcc type attributes through the
codegen pass.  Though only function types are really affected, other kinds of
type either have their own unique type decl (struct, class, enum), or we don't
expose any kind of type attributes to because the language has a feature that
provides for it (i.e vector attributes).

Such examples of careful handling includes emitting a warning if you assign a
function with type attributes to a function pointer that has none.  Of course,
if this information is part of the function type linkage in the frontend, then
a compiler error will happen before the codegen stage.

Alternatively we could start disallowing assigning type attributes to
functions, as there's no simple way to ensure that it will stick.

Explanation:

// Frontend attaches @ms_abi to the fdecl and fptr declarations.
// GCC codegen attaches them to the type, creating a new type variant.
@ms_abi T fdecl();
@ms_abi T function() fptr = &fdecl;

// Frontend will pass the equivalent code: (cast(T)*fptr)();
// Where T is original function type without attributes.
// This is where the information is getting lost.
fptr();


> On other vendors, LDC will use ms_abi when compiled with
> -mtriple=x86_64-unknown-windows-coff, where ms_abi is specified with
> extern(C).

That is the same for gcc also. The suggestion makes a difference only for
non-windows platforms.

-- 
You are receiving this mail because:
You are watching all bug changes.