search for: microsoftext

Displaying 5 results from an estimated 5 matches for "microsoftext".

2013 Dec 11
2
[LLVMdev] Switching to the new MingW ABI
I think we need to relax the test cases. MSVC usually prints the calling convention, and it's often useful information. Maybe we can make the diagnostic text smaller by using the __thiscall, __cdecl, __stdcall, etc keywords when printing types with LangOpts.MicrosoftExt, but it will require moving the attribute from after the identifier to before, which is exciting. On Tue, Dec 10, 2013 at 4:20 PM, Hans Wennborg <hans at chromium.org> wrote: > On Tue, Dec 10, 2013 at 3:57 PM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Dec 10, 2013...
2013 Dec 11
0
[LLVMdev] Switching to the new MingW ABI
On Tue, Dec 10, 2013 at 3:57 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> wrote: >> >> It would be nice if we could make the TypePrinter not print the >> calling convention if it's the default one for the ABI, but >> TypePrinter doesn't have a lot of context.. no Sema, no
2013 Dec 11
0
[LLVMdev] Switching to the new MingW ABI
...was going to argue that MSVC doesn't print them, but then I tried, and you're right - it does :) I'll start relaxing the tests then. > Maybe we can make the diagnostic text smaller by using the __thiscall, > __cdecl, __stdcall, etc keywords when printing types with > LangOpts.MicrosoftExt, but it will require moving the attribute from after > the identifier to before, which is exciting. This seems like a nice thing to do, but I'll get the tests going with what we've got for now. - Hans > On Tue, Dec 10, 2013 at 4:20 PM, Hans Wennborg <hans at chromium.org> w...
2013 Dec 10
2
[LLVMdev] Switching to the new MingW ABI
On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> wrote: > It would be nice if we could make the TypePrinter not print the > calling convention if it's the default one for the ABI, but > TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ > Does this patch fix any failures for you? It doesn't fix that test case, unfortunately.
2017 May 11
3
problem (and fix) with -fms-extensions
I've tried to build something that wanted ms-extensions on OpenBSD. Long story short, didn't work so well, because all system includes lead to <machine/_types.h> #ifndef __cplusplus typedef int __wchar_t; #endif and since ms-extensions includes __char_t as a built-in, this did fail abysmally. It would be simple to fix in OpenBSD, assuming clang did tell us it