This is blocked primarily on bug 1119080. I am sure how to fix bug 1119080, and I can't get past the errors that result from that bug in order to find additional problems.

Here's my understanding of what's *known* to be needed in order to get VS2015 to build Firefox well enough for it to become the release build compiler: * All bugs that this bug depends on must be fixed. It seems very likely that bug 1124017 could be a showstopper that would prevent EVER switching to VS2015, so I recommend that people look into that ASAP. I'd say that bug 1120793 is the second-most likely thing to be a showstopper. * It seems like linking after a clobber always works, but sometimes re-linking after an incremental build fails with a crash within the linker. I didn't file a bug for this either in bugzilla or connect.microsoft.com. * I only ran a small selection of the test suite that is most relevant to the things I hack on. I recommend that others run the entire test suite and file bugs for any failures. I probably won't spend any more time on this beyond what I've already done, due to personal time constraints. But, I do think it is important to resolve whether VS2015 will ever be usable soon, because that affects whether Mozilla needs to switch to clang on Windows or whether Mozilla would always be stuck with the VS2013 C++ feature set.

Is this still the main meta bug for vs2015? apparently all the blockers are resolved here, except bug 1124033, but that bug doesn't _appear_ to me as preventing the build since it appears to try a different solution to the resolved bug 1119072. FWIW, I just failed to build latest m-c with vs2015 (after installing the DX SDK June 2010 and using the non-x64 batch file in latest mozilla-build).

(In reply to Avi Halachmi (:avih) from comment #2) > Is this still the main meta bug for vs2015? apparently all the blockers are > resolved here, except bug 1124033, but that bug doesn't _appear_ to me as > preventing the build since it appears to try a different solution to the > resolved bug 1119072. > > FWIW, I just failed to build latest m-c with vs2015 (after installing the DX > SDK June 2010 and using the non-x64 batch file in latest mozilla-build). Let's make *this* bug be just about getting Visual Studio 2015 support to the point where the build succeeds and the tests pass locally. Bug 1186060 can be used to track future work toward making Visual Studio 2015 the compiler for official releases and dropping Visual Studio 2013 support. I think bug 1120793 is the only bug *I* know about that is blocking VS2015 builds, but it has been months since I tried a VS2015-based build. If there are other build/test failures then please file bugs for them that are blocking this bug.

I moved the dependencies on bug 1121290, 1124017, 1124033 over to bug 1186060, which is the tracking bug I field for making VS2015 the compiler for release builds.

So I've finally managed to get a working VS2015 build! Not all my patches are reviewable but I'll put them up in places the next day or so.

Hooray! VS2015 build succeeds on m-c today! Thanks for working on this! Now I guess we should probably ask someone to add VS2015 to the infra so that we won't break it frequently.

What should be done next to add VS2015 as a tier-2 support platform? It now compiles on m-c, so probably we can mark this bug as fixed?

In 64 Bit version with VS2015 and Windows 10 i have this errors and i cannot compile :-(

(In reply to Sladky Vladimir from comment #8) > Created attachment 8651779 [details] > Error.txt > > In 64 Bit version with VS2015 and Windows 10 i have this errors and i cannot > compile :-( That is comm-central. Please file a bug against thunderbird or seamonkey, whichever is relevant.

This is bug if i compile 64-bit SeaMonkey in VS2015 with start-shell-msvc2015-x64.bat and SDK 10. (SDK 8.1 i have installed too, but previous 64 bit SeaMonkey build i compile in old VS2013) MozillaBuild Install Directory: C:\mozilla-build\ Visual C++ 2015 Directory: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ Windows SDK Directory: C:\Program Files (x86)\Windows Kits\8.1\ Using the MSVC 2015 64-bit toolchain.

I compile 64-bit SeaMonkey in VS2015 ...

I try compile 64-bit Firefox in VS2015: 5:43.72 Poznámka: Včetně souboru: c:\users\vlada\comm-central\mozilla\image\ImageFactory.h 5:43.72 c:/Users/Vlada/comm-central/mozilla/obj-x86_64-pc-mingw32/image/Unified_cpp_image1.cpp(65): fatal error C1090: Volání PDB API selhalo, kód chyby 24: . 5:43.72 5:43.72 \corecrt_wconio.h 5:43.72 Poznámka: Včetně souboru: C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\corecrt_wctype.h

This *.dll files in VS2015 not exist please ??? :-( 46:16.41 install: cannot stat `/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/redist/x64/Microsoft.VC140.CRT/appcrt140.dll': No such file or directory 46:16.41 install: cannot stat `/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/redist/x64/Microsoft.VC140.CRT/desktopcrt140.dll': No such file or directory 46:16.42 Makefile:28: recipe for target 'libs' failed 46:16.42 mozmake.EXE[5]: *** [libs] Error 1

(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #7) > What should be done next to add VS2015 as a tier-2 support platform? It now > compiles on m-c, so probably we can mark this bug as fixed? Usually with new toolchains, new code that doesn't build with it keeps getting checked in, so it's useful to keep the bug open until we get builds with MSVC2015 on the infrastructure.

(In reply to Ehsan Akhgari (don't ask for review please) from comment #14) > Usually with new toolchains, new code that doesn't build with it keeps > getting checked in, so it's useful to keep the bug open until we get builds > with MSVC2015 on the infrastructure. Ehsan, could you please file the appropriate bug for adding MSVC 2015 toolchain to the build infrastructure (e.g. so it works as tryserver). You've done similar things before and I've not, so I'm not sure how to file the bug.

(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #15) > (In reply to Ehsan Akhgari (don't ask for review please) from comment #14) > > Usually with new toolchains, new code that doesn't build with it keeps > > getting checked in, so it's useful to keep the bug open until we get builds > > with MSVC2015 on the infrastructure. > > Ehsan, could you please file the appropriate bug for adding MSVC 2015 > toolchain to the build infrastructure (e.g. so it works as tryserver). > You've done similar things before and I've not, so I'm not sure how to file > the bug. Filed bug 1198374. Mostly we need someone to do this work though.

Be aware of the Windows system requirements for Visual Studio 2015: https://www.visualstudio.com/en-us/downloads/visual-studio-2015-system-requirements-vs.aspx Need at least Windows 7 SP1 or Windows 8.1 with Update 1 [KB2919355] to use.

(In reply to Sladky Vladimir from comment #18) > Created attachment 8660670 [details] > Alaways errors ... Those are comm-central errors which are off-topic for this bug. Please file a new bug in the Thunderbird/Seamonkey products for those.

(In reply to Ehsan Akhgari (don't ask for review please) from comment #19) > > Those are comm-central errors which are off-topic for this bug. Please file > a new bug in the Thunderbird/Seamonkey products for those. That actually already exists: bug 1201803, and they've been cc'ed there long time ago.

https://www.visualstudio.com/news/vs2015-update1-vs "Today, we are happy to announce the release of Visual Studio 2015 Update 1. This release includes our latest feature and functionality updates. "

It'd be worth getting some sort of automated VS2015 build going considering how many people are building on it these days and the impact of breaking it.

(In reply to Bas Schouten (:bas.schouten) from comment #22) > It'd be worth getting some sort of automated VS2015 build going considering > how many people are building on it these days and the impact of breaking it. I believe that is happening in bug 1198374 (though no much progress currently as far as I can see).

(In reply to Xidorn Quan [:xidorn] (UTC+10) (less responsive until Feb 22) from comment #23) > I believe that is happening in bug 1198374 (though no much progress > currently as far as I can see). Oh, I was wrong. It seems there is a good progress in bugs it depends.

Visual Studio 2015 Update 2 RC was released today. It appears to build mozilla-central just fine (including PGO)!

Aside from seldom breakage (because we don't have VS2015 coverage in automation), VS2015 is supported for building Firefox. Switching automation to VS2015 is being tracked in bug 1186060. I don't think this bug is serving much use being open. So closing it. If there are new compiler errors with VS2015 before we have automation coverage, I think it's OK to have them block this bug.