Skip to content
This repository has been archived by the owner on Feb 8, 2024. It is now read-only.

[2.067] MSVCRT 14 (VS 2015) support #29

Closed
wants to merge 3 commits into from

Conversation

kinke
Copy link
Member

@kinke kinke commented May 23, 2015

MS mainly focused on stdio.h in their upcoming C runtime. It provides important C99 fixes, see http://blogs.msdn.com/b/vcblog/archive/2014/06/18/crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1.aspx. E.g., it fixes ldc-developers/ldc#761 with no additional changes.

va_list args;
va_start(args, format);
return vscanf(format, args);
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what porpose all that functiions are added ?
One can use legacy_stdio_definitions library for those functions.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know about that lib. Can you confirm just linking to that lib and omitting these new wrappers works (allowing you to build the druntime and phobos test runners)?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, i can. I'd built ldc with msvc 2015. Only thing i'd changed is new way fo acquiring std(in|out|err) with __acrt_iob_func and also i'd removed _f(put|get)c_nolock because they're already implemented in new msvc runtime.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I've confirmed it too and changed the commit accordingly.
I actually went through the D file and compared it against the VS 2015 C header, so this PR fixes more issues than those you mentioned.

@dnadlinger
Copy link
Member

Nice that we'll finally get something resembling a conforming C99 implementation (it also fixes a couple of annoying C++11 bugs, but of course that's hardly relevant for us). Imho, it would even make sense to focus our efforts on Visual Studio 2015 for now. Once this is stable, we can always go back and add in workarounds for the older versions.

@Daniel-N
Copy link

How far away are we from reviewing/merging this, considering VS2015 is out the door?

@dnadlinger
Copy link
Member

It's up to the Windows folks (@kinke, @redstar) to decide how to best go ahead with this.

@kinke
Copy link
Member Author

kinke commented Jul 27, 2015

I'd be okay with simply uncommenting the line declaring version LDC_MSVCRT14. This way, VS2013 users will still be able to build LDC by commenting the version declaration manually.
In the long term, DMD needs to catch up, and we'll hopefully be able to drop the legacy MS stuff altogether.

@kinke
Copy link
Member Author

kinke commented Aug 3, 2015

The 3rd commit makes VS 2015 the default target for MSVC builds. No objections wrt. merging from my side. ;)

@kinke kinke changed the title [2.067] Experimental MSVCRT 14 (VS 2015) support [2.067] MSVCRT 14 (VS 2015) support Aug 3, 2015
@MartinNowak
Copy link

Wouldn't it be better to let the compiler detect the VC version and provide the version declaration?
Then we could get a druntime lib that is compatible with both VC versions, by importing the correct declarations for the current VC.

@kinke
Copy link
Member Author

kinke commented Aug 9, 2015

That's an option and would be another reasonable use case for integer versions (version(CRuntime_Microsoft >= 14) ...), as things may get easily out of hand if we begin introducing additional predefined versions like CRuntime_Microsoft_C99 to distinguish between different versions or features of a particular C runtime...

@MartinNowak
Copy link

Also see dlang#1341.

@kinke
Copy link
Member Author

kinke commented Aug 26, 2015

Closing this in favor of #32, a direct cherry-pick of dlang#1341, which just got merged upstream.

@kinke kinke closed this Aug 26, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants