Displaying 3 results from an estimated 3 matches for "oldlinkage".
2013 May 07
0
[LLVMdev] Feedback required on proper dllexport/import implementation
...nse after
your change). And some contributors who have not caught up with
your change may still submit patches with the old semantics in mind,
which seems prone to errors.
If you really like your approach, I wonder if it makes sense to rename
the existing linkage type to something different, e.g., OldLinkage to
NewLinkage, so that future patches using hasOldLinkage() will have
to check their codes to make sure they work with the new semantics.
> Hm, I don't think so, because dllimported inline functions must never be
> instantiated, or else you get duplicated symbols. They are only allowed t...
2013 Apr 23
2
[LLVMdev] Feedback required on proper dllexport/import implementation
On 23.04.2013 19:10, Gao, Yunzhong wrote:
> I missed the discussion when I implemented dllexport/dllimport for our local tree. I
> essentially implemented your approach#1. I was trying to avoid the various
> external_linkage + some_attribute approaches because it seems that external_linkage
> would imply the external linkage without the dllimport/dllexport semantics, and there
> may
2013 May 07
1
[LLVMdev] Feedback required on proper dllexport/import implementation
...> which seems prone to errors.
This is irrelevant here. They need to submit patches against ToT, so,
they will need to submit already "new" patches.
> If you really like your approach, I wonder if it makes sense to rename
> the existing linkage type to something different, e.g., OldLinkage to
> NewLinkage, so that future patches using hasOldLinkage() will have
> to check their codes to make sure they work with the new semantics.
The point here is that patches should come with tests. And this is how
we will make sure they will work with "new" semantics.
> I agree....