Re: PSA: Avoid Visual Studio 2017 15.7.0

[Jeff Gilbert]

Consider instead building with clang-cl:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Building_Firefox_on_Windows_with_clang-cl

If you build with clang-cl, you can keep the newest
(gecko-incompatible) version of MSVC installed, which is particularly
useful if you build other modern codebases.

On Fri, May 11, 2018 at 3:01 PM, Matthew N.  wrote:
> On 2018-05-08 6:40 a.m., Ryan VanderMeulen wrote:
>>
>> Yesterday, Microsoft released Visual Studio 2017 15.7.0. Unfortunately, it
>> is currently not usable for building Firefox due to bug 1458247 (internal
>> compiler errors in WebRTC code). The bug was already reported and
>> confirmed
>> upstream during the 15.7 preview cycle, but unfortunately the final
>> release
>> still shipped with the bug present.
>>
>> At this point, there are no workarounds available for this issue, so avoid
>> the update if you want to be able to continue building Firefox.
>
>
> If you need to update to 15.6 but hadn't yet, you can download old versions
> at
> https://docs.microsoft.com/en-us/visualstudio/productinfo/installing-an-earlier-release-of-vs2017
>
> - MattN
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Avoid Visual Studio 2017 15.7.0

[Matthew N.]

On 2018-05-08 6:40 a.m., Ryan VanderMeulen wrote:

Yesterday, Microsoft released Visual Studio 2017 15.7.0. Unfortunately, it
is currently not usable for building Firefox due to bug 1458247 (internal
compiler errors in WebRTC code). The bug was already reported and confirmed
upstream during the 15.7 preview cycle, but unfortunately the final release
still shipped with the bug present.

At this point, there are no workarounds available for this issue, so avoid
the update if you want to be able to continue building Firefox.


If you need to update to 15.6 but hadn't yet, you can download old 
versions at 
https://docs.microsoft.com/en-us/visualstudio/productinfo/installing-an-earlier-release-of-vs2017


- MattN
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Avoid Visual Studio 2017 15.7.0

[Frank-Rainer Grahl]

Make sure you also disable the autoupdate in the task scheduler!

"VSIX Auto Update 14 under Microsoft VisualStudio".

FRG

Ryan VanderMeulen wrote:

Yesterday, Microsoft released Visual Studio 2017 15.7.0. Unfortunately, it
is currently not usable for building Firefox due to bug 1458247 (internal
compiler errors in WebRTC code). The bug was already reported and confirmed
upstream during the 15.7 preview cycle, but unfortunately the final release
still shipped with the bug present.

At this point, there are no workarounds available for this issue, so avoid
the update if you want to be able to continue building Firefox.

-Ryan


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Avoid Visual Studio 2017 15.7.0

[Ryan VanderMeulen]

Yesterday, Microsoft released Visual Studio 2017 15.7.0. Unfortunately, it
is currently not usable for building Firefox due to bug 1458247 (internal
compiler errors in WebRTC code). The bug was already reported and confirmed
upstream during the 15.7 preview cycle, but unfortunately the final release
still shipped with the bug present.

At this point, there are no workarounds available for this issue, so avoid
the update if you want to be able to continue building Firefox.

-Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Visual Studio 2017 15.6 now required to build 61+

[Jeff Gilbert]

Bumping to GCC6 has a tracking bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1444274
This would give us general c++14 capability.

The only blocker I know of is updating Sixgill's (hazard analysis?)
GCC version: https://bugzilla.mozilla.org/show_bug.cgi?id=1444543
If there are no other blockers, upgrading our GCC required version may
follow relatively quickly.


On Tue, Mar 13, 2018 at 1:34 PM, Jeff Gilbert <jgilb...@mozilla.com> wrote:
> The patches have landed. Thanks!
>
> Are we ready to update this page?:
> https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code
>
> On Mon, Mar 12, 2018 at 5:29 PM, Ryan VanderMeulen
> <rvandermeu...@mozilla.com> wrote:
>> While I know I'm tempting fate by sending this out while the patches are
>> still on autoland, I wanted to start giving people a heads-up now that bug
>> 1424281 has been pushed, which will make Visual Studio 2017 15.6 (Update 6)
>> the minimum version required to build Gecko 61+ once it merges to m-c.
>>
>> This change brings a number of improvements over version 15.4, which is
>> what we've been using in automation since Gecko 58, including performance
>> wins and better C++17 support. Release notes for versions 15.5 and 15.6 are
>> linked below with more details:
>> https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes-v15.5#a-idlibimprov-a-visual-c-improvements
>> https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes#CPlusPlus
>> https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-15-5-and-15-6/
>>
>> If you're currently using Visual Studio 2015, you can download the 2017
>> installer from https://www.visualstudio.com/vs/community/. If you already
>> have 2017 installed, you should only need to launch the Visual Studio
>> Installer already on your system and follow the update prompts. Note that
>> the Windows SDK minimum version was also bumped to version 15063 to match
>> what we've been using in automation. It is also installable via the Visual
>> Studio Installer if needed.
>>
>> Enjoy!
>>
>> -Ryan
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Visual Studio 2017 15.6 now required to build 61+

[Jeff Gilbert]

The patches have landed. Thanks!

Are we ready to update this page?:
https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code

On Mon, Mar 12, 2018 at 5:29 PM, Ryan VanderMeulen
<rvandermeu...@mozilla.com> wrote:
> While I know I'm tempting fate by sending this out while the patches are
> still on autoland, I wanted to start giving people a heads-up now that bug
> 1424281 has been pushed, which will make Visual Studio 2017 15.6 (Update 6)
> the minimum version required to build Gecko 61+ once it merges to m-c.
>
> This change brings a number of improvements over version 15.4, which is
> what we've been using in automation since Gecko 58, including performance
> wins and better C++17 support. Release notes for versions 15.5 and 15.6 are
> linked below with more details:
> https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes-v15.5#a-idlibimprov-a-visual-c-improvements
> https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes#CPlusPlus
> https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-15-5-and-15-6/
>
> If you're currently using Visual Studio 2015, you can download the 2017
> installer from https://www.visualstudio.com/vs/community/. If you already
> have 2017 installed, you should only need to launch the Visual Studio
> Installer already on your system and follow the update prompts. Note that
> the Windows SDK minimum version was also bumped to version 15063 to match
> what we've been using in automation. It is also installable via the Visual
> Studio Installer if needed.
>
> Enjoy!
>
> -Ryan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Visual Studio 2017 15.6 now required to build 61+

[Mike Hommey]

On Tue, Mar 13, 2018 at 09:05:50AM +0200, Henri Sivonen wrote:
> On Tue, Mar 13, 2018 at 2:29 AM, Ryan VanderMeulen
> <rvandermeu...@mozilla.com> wrote:
> > While I know I'm tempting fate by sending this out while the patches are
> > still on autoland, I wanted to start giving people a heads-up now that bug
> > 1424281 has been pushed, which will make Visual Studio 2017 15.6 (Update 6)
> > the minimum version required to build Gecko 61+ once it merges to m-c.
> >
> > This change brings a number of improvements over version 15.4, which is
> > what we've been using in automation since Gecko 58, including performance
> > wins and better C++17 support.
> 
> Thank you!
> 
> It seems that 
> https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code
> doesn't match this information. Also, it seems that last week Gecko
> stopped compiling with clang 3.8 even though that page says clang 3.6
> is supported.
> 
> To be clear, I'm not arguing that we should support old compilers, but
> it would be good to keep that page up-to-date.
> 
> On the topic of old compilers, it looks like we could get more C++
> features if we changed the minimum gcc requirement. Is Debian
> oldstable the current reason for keeping gcc at 4.9?

No, the reason we're stuck with 4.9 is that hazard builds are still
using 4.9. The GCC plugin used for those builds needs to be updated, and
hopefully that will happen soon.

> In particular, C++17 structured bindings (gcc 7) would make working
> with tuple return values more ergonomic than working with them is
> today and more ergonomic than working with outparams. Instead of

The best we can bump to right now is GCC 6, which is what we currently
use to build the releases. GCC 7 may or may not require more work.

>   uint32_t result;
>   size_t read;
>   size_t written;
>   bool hadErrors;
>   Tie(result, read, written, hadErrors) = mDecoder->DecodeToUTF16(...);
> 
> one would write
> 
>   auto [result, read, written, hadErrors] = mDecoder->DecodeToUTF16(...);
> 
> bringing ergonomics closer to Rust's ergonomics.

I'm not sure type inference in C++ is something to look forward to. In
rust, although it can be painful to figure out what type a binding has,
at least there's not too many possible coercions. In C++ my gut reaction
is that that looks like a foot-chaingun.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Visual Studio 2017 15.6 now required to build 61+

[Henri Sivonen]

On Tue, Mar 13, 2018 at 2:29 AM, Ryan VanderMeulen
<rvandermeu...@mozilla.com> wrote:
> While I know I'm tempting fate by sending this out while the patches are
> still on autoland, I wanted to start giving people a heads-up now that bug
> 1424281 has been pushed, which will make Visual Studio 2017 15.6 (Update 6)
> the minimum version required to build Gecko 61+ once it merges to m-c.
>
> This change brings a number of improvements over version 15.4, which is
> what we've been using in automation since Gecko 58, including performance
> wins and better C++17 support.

Thank you!

It seems that 
https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code
doesn't match this information. Also, it seems that last week Gecko
stopped compiling with clang 3.8 even though that page says clang 3.6
is supported.

To be clear, I'm not arguing that we should support old compilers, but
it would be good to keep that page up-to-date.

On the topic of old compilers, it looks like we could get more C++
features if we changed the minimum gcc requirement. Is Debian
oldstable the current reason for keeping gcc at 4.9? Considering that
other LTS distros have occasionally backported gcc in order to keep
building Firefox with an in-archive compiler and that Debian is going
to need to backport Rust to build the next ESR using in-archive
compilers, would it be appropriate for us to require a newer gcc?

In particular, C++17 structured bindings (gcc 7) would make working
with tuple return values more ergonomic than working with them is
today and more ergonomic than working with outparams. Instead of

  uint32_t result;
  size_t read;
  size_t written;
  bool hadErrors;
  Tie(result, read, written, hadErrors) = mDecoder->DecodeToUTF16(...);

one would write

  auto [result, read, written, hadErrors] = mDecoder->DecodeToUTF16(...);

bringing ergonomics closer to Rust's ergonomics.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Visual Studio 2017 15.6 now required to build 61+

[Ryan VanderMeulen]

While I know I'm tempting fate by sending this out while the patches are
still on autoland, I wanted to start giving people a heads-up now that bug
1424281 has been pushed, which will make Visual Studio 2017 15.6 (Update 6)
the minimum version required to build Gecko 61+ once it merges to m-c.

This change brings a number of improvements over version 15.4, which is
what we've been using in automation since Gecko 58, including performance
wins and better C++17 support. Release notes for versions 15.5 and 15.6 are
linked below with more details:
https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes-v15.5#a-idlibimprov-a-visual-c-improvements
https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes#CPlusPlus
https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-15-5-and-15-6/

If you're currently using Visual Studio 2015, you can download the 2017
installer from https://www.visualstudio.com/vs/community/. If you already
have 2017 installed, you should only need to launch the Visual Studio
Installer already on your system and follow the update prompts. Note that
the Windows SDK minimum version was also bumped to version 15063 to match
what we've been using in automation. It is also installable via the Visual
Studio Installer if needed.

Enjoy!

-Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Build bustage with Visual Studio 2017 15.6

[Ryan VanderMeulen]

As an update, the fix for bug 1443367 has been merged to m-c. There doesn't
appear to be any other bustage lurking behind it, so updating should be
less fraught with peril now.

-Ryan

On Mon, Mar 5, 2018 at 7:41 PM, Ryan VanderMeulen <rvandermeu...@mozilla.com
> wrote:

> Today, Microsoft released version 15.6 of Visual Studio 2017:
> https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes
>
> After updating and attempting to build with it locally, I encountered
> build bustage that I've filed as bug 1443367. I don't know if there will be
> further issues lurking behind that, so I would advise avoiding this update
> for the time being until all known issues are resolved and an update is
> sent to this thread.
>
> -Ryan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Build bustage with Visual Studio 2017 15.6

[Ryan VanderMeulen]

Today, Microsoft released version 15.6 of Visual Studio 2017:
https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes

After updating and attempting to build with it locally, I encountered build
bustage that I've filed as bug 1443367. I don't know if there will be
further issues lurking behind that, so I would advise avoiding this update
for the time being until all known issues are resolved and an update is
sent to this thread.

-Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Randell Jesup]

>2017-10-30 19:19 GMT+01:00 Kris Maglione :
>
>> Our static analysis tools are pretty good at catching a lot of lambda
>> capture bugs at this point, though. I'd be much less comfortable using them
>> if they weren't.
>>
>> It's probably worth considering whether we need to write static analysis
>> tools for a new feature before we turn it on, though...
>
>We can probably help with introducing more static analysis to avoid
>incorrect usages of C++{11,14,17} features.

Sure - but in most cases we've only realized that a static-analysis bit
was needed after hitting and solving a few (or a bunch of) crashes/sec bugs --
static-analysis tends to be reactive.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Sylvestre Ledru]

2017-10-30 19:19 GMT+01:00 Kris Maglione :

> Our static analysis tools are pretty good at catching a lot of lambda
> capture bugs at this point, though. I'd be much less comfortable using them
> if they weren't.
>
> It's probably worth considering whether we need to write static analysis
> tools for a new feature before we turn it on, though...

We can probably help with introducing more static analysis to avoid
incorrect usages of C++{11,14,17} features.

Don't hesitate to report suggestions here:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Rewriting%20and%20Analysis

Cheers,
Sylvestre
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[smaug]

On 10/30/2017 10:03 PM, Kris Maglione wrote:

On Mon, Oct 30, 2017 at 08:28:39AM -0700, Jim Blandy wrote:

Okay, this is half the argument. The second half would be:

- Does auto cause such mistakes more often than it prevents them? The
benefit claimed for auto is that it usually makes code more legible.
Hopefully that prevents mistakes, on the balance.


My feeling is that these features generally prevent more errors than they cause.


My gut feeling while having my reviewer's hat on, is that I haven't really seen 
them preventing issues, but they have definitely caused issues.



The case for `auto` probably isn't as strong as the cases for other features, 
but I don't think the case against it is as strong either. And there are
places where, without `auto`, the extra qualified type noise spreads a simple 
assignment across multiple, dense lines, and makes the code much more
difficult to
follow. And makes refactoring the specific types of (e.g.,) smart pointer 
arrays more complicated, and somewhat more dangerous.

Also, I'm quite looking forward to the time when I can write:

 GetString(char*, nsContentUtils::PropertiesFile aBundle = 
auto::eBRAND_PROPERTIES)

rather than:

 GetString(char*, nsContentUtils::PropertiesFile aBundle = 
nsContentUtils::PropertiesFile::eBRAND_PROPERTIES)


- Is ranged-for more prone to iterator invalidation errors than the older
form? I believe I've seen .Length() calls hoisted out of old-form loop
conditions pretty frequently. The advantage of ranged-for is claimed to be
that it depends on the operand's iteration API, instead of requiring the
programmer to invent an iteration technique each time they write a loop.


Again, my feeling here is that the opposite is true. If we have a single, de 
facto way of writing for loops, it makes it much easier to make sure we
have the correct behavior everywhere. The alternative is separate, ad-hoc 
implementations everywhere we iterate over a collection, many of which will
make their own sets of mistakes.


- Are closures more prone to ownership mistakes than the pre-closure
technique? How does this compare with their benefits to legibility?


I think this is the clearest case where the benefits far outweigh the risks. 
There are definitely easy-to-overlook lambda capture footguns, but our
static analysis tools are good at preventing those. But there are also huge 
benefits.

The ScopeExit class is the best example I can think of. Before we had that 
helper, in the best cases, we wound up writing tons of special-purpose RAII
helpers that were hard to think about and maintain. In the worst cases, we 
wound up with tons of code that either did not handle early return
correctly at all, or added fragile, duplicated cleanup code in every failure 
check `if`. ScopeExit makes our code much safer and more maintainable.

And in the more general case, our pre-lambda code tends to wind up with logic 
and data ownership spread across multiple methods and special-purpose
classes (e.g., Runnables), that often get separated in the source, and become 
difficult to follow and reason about. Post-lambda, we have abstractions
like MozPromise that make async code much easier to follow, and the data it 
owns much more obvious.

For example, this code that I wrote fairly recently:

   RefPtr self(this);
   RunOnMainThread(FUNC, [=] {
 self->mChannel->Resume();

 RunOnActorThread(FUNC, [=] {
   if (self->IPCActive()) {
 self->CheckResult(self->SendResumed());
   }
 });
   });

Pre-lambda, in the best case would have expanded to something like:

IPCResult
StreamFilterParent::RecvResume()
{
 RunOnMainThread(
   NewRunnableMethod("StreamFilterParent::Resume1",
 this,
 StreamFilterParent::Resume1));
 return IPC_OK();
}

void
StreamFilterParent::Resume1()
{
 mChannel->Resume();
 RunOnActorThread(
   NewRunnableMethod("StreamFilterParent::Resume2",
 this,
 StreamFilterParent::Resume2));
}

void
StreamFilterParent::Resume2()
{
 if (IPCActive()) {
   CheckResult(SendResumed());
 }
}

Which is much more difficult to follow (which function runs on which thread? 
what data is kept alive across the entire event chain? where do we check
for errors?) and maintain (what happens when I want to add a new event in the 
middle of the chain? do I renumber everything and add a new method
declaration to the header?). And that's for a fairly simple case where the only 
object held alive is `this`.


When evaluating the impact of new features, we should not let the
familiarity of the mistakes we've been making in C++98 for twenty years
cause us to focus only on the risks from change. That misjudgment would
hurt the quality of the code.


+1


On Mon, Oct 30, 2017 at 8:03 AM, smaug  wrote:


On 10/30/2017 04:52 PM, Simon Sapin wrote:


On 30/10/17 15:05, smaug wrote:


And let's be careful with the new C++ features, pretty please. We
managed to not be careful 

Re: Visual Studio 2017 coming soon

[Kris Maglione]

On Mon, Oct 30, 2017 at 08:28:39AM -0700, Jim Blandy wrote:

Okay, this is half the argument. The second half would be:

- Does auto cause such mistakes more often than it prevents them? The
benefit claimed for auto is that it usually makes code more legible.
Hopefully that prevents mistakes, on the balance.


My feeling is that these features generally prevent more errors 
than they cause.


The case for `auto` probably isn't as strong as the cases for 
other features, but I don't think the case against it is as 
strong either. And there are places where, without `auto`, the 
extra qualified type noise spreads a simple assignment across 
multiple, dense lines, and makes the code much more difficult to
follow. And makes refactoring the specific types of (e.g.,) 
smart pointer arrays more complicated, and somewhat more dangerous.


Also, I'm quite looking forward to the time when I can write:

 GetString(char*, nsContentUtils::PropertiesFile aBundle = 
auto::eBRAND_PROPERTIES)

rather than:

 GetString(char*, nsContentUtils::PropertiesFile aBundle = 
nsContentUtils::PropertiesFile::eBRAND_PROPERTIES)


- Is ranged-for more prone to iterator invalidation errors than the older
form? I believe I've seen .Length() calls hoisted out of old-form loop
conditions pretty frequently. The advantage of ranged-for is claimed to be
that it depends on the operand's iteration API, instead of requiring the
programmer to invent an iteration technique each time they write a loop.


Again, my feeling here is that the opposite is true. If we have a single, de 
facto way of writing for loops, it makes it much easier to make sure we have 
the correct behavior everywhere. The alternative is separate, ad-hoc 
implementations everywhere we iterate over a collection, many of which will 
make their own sets of mistakes.



- Are closures more prone to ownership mistakes than the pre-closure
technique? How does this compare with their benefits to legibility?


I think this is the clearest case where the benefits far outweigh the risks. 
There are definitely easy-to-overlook lambda capture footguns, but our static 
analysis tools are good at preventing those. But there are also huge benefits.


The ScopeExit class is the best example I can think of. Before we had that 
helper, in the best cases, we wound up writing tons of special-purpose RAII 
helpers that were hard to think about and maintain. In the worst cases, we 
wound up with tons of code that either did not handle early return correctly 
at all, or added fragile, duplicated cleanup code in every failure check `if`. 
ScopeExit makes our code much safer and more maintainable.


And in the more general case, our pre-lambda code tends to wind up with logic 
and data ownership spread across multiple methods and special-purpose classes 
(e.g., Runnables), that often get separated in the source, and become 
difficult to follow and reason about. Post-lambda, we have abstractions like 
MozPromise that make async code much easier to follow, and the data it owns 
much more obvious.


For example, this code that I wrote fairly recently:

   RefPtr self(this);
   RunOnMainThread(FUNC, [=] {
 self->mChannel->Resume();

 RunOnActorThread(FUNC, [=] {
   if (self->IPCActive()) {
 self->CheckResult(self->SendResumed());
   }
 });
   });

Pre-lambda, in the best case would have expanded to something like:

IPCResult
StreamFilterParent::RecvResume()
{
 RunOnMainThread(
   NewRunnableMethod("StreamFilterParent::Resume1",
 this,
 StreamFilterParent::Resume1));
 return IPC_OK();
}

void
StreamFilterParent::Resume1()
{
 mChannel->Resume();
 RunOnActorThread(
   NewRunnableMethod("StreamFilterParent::Resume2",
 this,
 StreamFilterParent::Resume2));
}

void
StreamFilterParent::Resume2()
{
 if (IPCActive()) {
   CheckResult(SendResumed());
 }
}

Which is much more difficult to follow (which function runs on which thread? 
what data is kept alive across the entire event chain? where do we check for 
errors?) and maintain (what happens when I want to add a new event in the 
middle of the chain? do I renumber everything and add a new method declaration 
to the header?). And that's for a fairly simple case where the only object 
held alive is `this`.



When evaluating the impact of new features, we should not let the
familiarity of the mistakes we've been making in C++98 for twenty years
cause us to focus only on the risks from change. That misjudgment would
hurt the quality of the code.


+1


On Mon, Oct 30, 2017 at 8:03 AM, smaug  wrote:


On 10/30/2017 04:52 PM, Simon Sapin wrote:


On 30/10/17 15:05, smaug wrote:


And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use auto, or ranged-for
or lambdas. I'd prefer to not fix more security critical bugs or
memory leaks just because of fancy hip and cool language features ;)

Re: Visual Studio 2017 coming soon

[Kris Maglione]

On Mon, Oct 30, 2017 at 11:04:10AM -0400, Boris Zbarsky wrote:

On 10/30/17 10:52 AM, Simon Sapin wrote:

How do new language features lead to security bugs?


By making unsafe behaviors easier or more tempting.

For example:

[&]() { /* stuff */ }

is a huge footgun in a language without a borrow checker.  You _could_ 
still do something like that before lambdas by creating a functor 
object, but you had to explicitly give it reference-typed members for 
the things you wanted to use, which might at least make you stop and 
think about whether those references were referencing things that 
lived long enouhg.  With [&] you capture everything by reference by 
default, which is great if the lambda's usage has stack lifetime and 
horrible otherwise...


Our static analysis tools are pretty good at catching a lot of 
lambda capture bugs at this point, though. I'd be much less 
comfortable using them if they weren't.


It's probably worth considering whether we need to write static 
analysis tools for a new feature before we turn it on, though...

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Jim Blandy]

Okay, this is half the argument. The second half would be:

- Does auto cause such mistakes more often than it prevents them? The
benefit claimed for auto is that it usually makes code more legible.
Hopefully that prevents mistakes, on the balance.

- Is ranged-for more prone to iterator invalidation errors than the older
form? I believe I've seen .Length() calls hoisted out of old-form loop
conditions pretty frequently. The advantage of ranged-for is claimed to be
that it depends on the operand's iteration API, instead of requiring the
programmer to invent an iteration technique each time they write a loop.

- Are closures more prone to ownership mistakes than the pre-closure
technique? How does this compare with their benefits to legibility?

When evaluating the impact of new features, we should not let the
familiarity of the mistakes we've been making in C++98 for twenty years
cause us to focus only on the risks from change. That misjudgment would
hurt the quality of the code.



On Mon, Oct 30, 2017 at 8:03 AM, smaug  wrote:

> On 10/30/2017 04:52 PM, Simon Sapin wrote:
>
>> On 30/10/17 15:05, smaug wrote:
>>
>>> And let's be careful with the new C++ features, pretty please. We
>>> managed to not be careful when we started to use auto, or ranged-for
>>> or lambdas. I'd prefer to not fix more security critical bugs or
>>> memory leaks just because of fancy hip and cool language features ;)
>>>
>>
>> Careful how? How do new language features lead to security bugs? Is new
>> compiler code not as well tested and could have miscompiles? Are specific
>> features easy to misuse?
>>
>>
>
> With auto we've managed to hide the ownership of some objects from
> reader/reviewer (and I guess also from the patch author),
> and this has lead to both to security issues and memory leaks.
>
> Ranged-for lead to security critical crashes when we converted some old
> style
> for (i = 0; i < array.Length(); ++i) to use it, since ranged-for doesn't
> play well when the array changes underneath you.
> These days we crash safely there.
>
> With lambdas understanding who owns what becomes harder, and before some
> checks, we had (I think rather short while) issues when
> there was a raw pointer to a refcounted object captured in a lambda and
> the lambda was then dispatched to the event loop.
> Nothing guaranteed the captured object to stay alive.
>
> Basically, some "new" features have hidden important aspects of the
> lifetime management of objects, and by
> doing that, made it easier to write broken code and harder by the
> reviewers to catch the mistakes.
>
>
>
> -Olli
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[smaug]

On 10/30/2017 04:52 PM, Simon Sapin wrote:

On 30/10/17 15:05, smaug wrote:

And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use auto, or ranged-for
or lambdas. I'd prefer to not fix more security critical bugs or
memory leaks just because of fancy hip and cool language features ;)


Careful how? How do new language features lead to security bugs? Is new 
compiler code not as well tested and could have miscompiles? Are specific
features easy to misuse?




With auto we've managed to hide the ownership of some objects from 
reader/reviewer (and I guess also from the patch author),
and this has lead to both to security issues and memory leaks.

Ranged-for lead to security critical crashes when we converted some old style
for (i = 0; i < array.Length(); ++i) to use it, since ranged-for doesn't play 
well when the array changes underneath you.
These days we crash safely there.

With lambdas understanding who owns what becomes harder, and before some 
checks, we had (I think rather short while) issues when
there was a raw pointer to a refcounted object captured in a lambda and the 
lambda was then dispatched to the event loop.
Nothing guaranteed the captured object to stay alive.

Basically, some "new" features have hidden important aspects of the lifetime 
management of objects, and by
doing that, made it easier to write broken code and harder by the reviewers to 
catch the mistakes.



-Olli
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Boris Zbarsky]

On 10/30/17 10:52 AM, Simon Sapin wrote:

How do new language features lead to security bugs?


By making unsafe behaviors easier or more tempting.

For example:

 [&]() { /* stuff */ }

is a huge footgun in a language without a borrow checker.  You _could_ 
still do something like that before lambdas by creating a functor 
object, but you had to explicitly give it reference-typed members for 
the things you wanted to use, which might at least make you stop and 
think about whether those references were referencing things that lived 
long enouhg.  With [&] you capture everything by reference by default, 
which is great if the lambda's usage has stack lifetime and horrible 
otherwise...



Are specific features easy to misuse?


This, imo.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Alex Gaynor]

I don't know about C++14 specifically, but a good example is C++17's
std::string_view, which allows an implicit cast from std::string&& and can
very easily lead to UAF:
https://github.com/isocpp/CppCoreGuidelines/issues/1038

Alex

On Mon, Oct 30, 2017 at 10:52 AM, Simon Sapin  wrote:

> On 30/10/17 15:05, smaug wrote:
>
>> And let's be careful with the new C++ features, pretty please. We
>> managed to not be careful when we started to use auto, or ranged-for
>> or lambdas. I'd prefer to not fix more security critical bugs or
>> memory leaks just because of fancy hip and cool language features ;)
>>
>
> Careful how? How do new language features lead to security bugs? Is new
> compiler code not as well tested and could have miscompiles? Are specific
> features easy to misuse?
>
> --
> Simon Sapin
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Simon Sapin]

On 30/10/17 15:05, smaug wrote:

And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use auto, or ranged-for
or lambdas. I'd prefer to not fix more security critical bugs or
memory leaks just because of fancy hip and cool language features ;)


Careful how? How do new language features lead to security bugs? Is new 
compiler code not as well tested and could have miscompiles? Are 
specific features easy to misuse?


--
Simon Sapin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[smaug]

And let's be careful with the new C++ features, pretty please.
We managed to not be careful when we started to use auto, or ranged-for or 
lambdas.
I'd prefer to not fix more security critical bugs or memory leaks just because 
of fancy hip and cool
language features ;)


-Olli



On 10/30/2017 05:27 AM, Jim Blandy wrote:

How will this affect the matrix of specific C++ features we can use?
https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code

(At the moment I'm dying for generic lambdas, which are C++14. I'd been
using std::function as a workaround, but I also need control over the
allocation policy, which std::function no longer offers.)


On Wed, Oct 25, 2017 at 2:48 PM, David Major  wrote:


I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
1408789.

VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
improvement on Speedometer. There is also increased support for C++14 and
C++17 language features:
https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance

These days we tend not to support older VS for too long, so after some
transition period you can probably expect that VS2017 will be required to
build locally, ifdefs can be removed, etc. VS2017 Community Edition is a
free download and it can coexist with previous compilers. Installation
instructions are at:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_
guide/Build_Instructions/Windows_Prerequisites#Visual_Studio_2017

If you have concerns, please talk to me or visit the bug. Thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Jim Blandy]

How will this affect the matrix of specific C++ features we can use?
https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code

(At the moment I'm dying for generic lambdas, which are C++14. I'd been
using std::function as a workaround, but I also need control over the
allocation policy, which std::function no longer offers.)


On Wed, Oct 25, 2017 at 2:48 PM, David Major  wrote:

> I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> 1408789.
>
> VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
> improvement on Speedometer. There is also increased support for C++14 and
> C++17 language features:
> https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
>
> These days we tend not to support older VS for too long, so after some
> transition period you can probably expect that VS2017 will be required to
> build locally, ifdefs can be removed, etc. VS2017 Community Edition is a
> free download and it can coexist with previous compilers. Installation
> instructions are at:
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_
> guide/Build_Instructions/Windows_Prerequisites#Visual_Studio_2017
>
> If you have concerns, please talk to me or visit the bug. Thanks!
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[David Major]

This has reached mozilla-central and nightlies are now being built with
VS2017.

The clang-cl builds (which still rely on a VS package for link.exe, among
other things) remain on VS2015 while I work out some issues in clang-cl's
path detection. All other Windows jobs have moved to VS2017.

While I'm here, I want to give a shout out to everyone who helped with the
move to Taskcluster and in-tree job definitions. In previous compiler
upgrades I had to beg for a lot of handholding from busy releng folks. This
time was an absolute piece of cake. Everything was self-explanatory,
self-service, and easily testable on Try. Thank you!


On Wed, Oct 25, 2017 at 5:48 PM, David Major  wrote:

> I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> 1408789.
>
> VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
> improvement on Speedometer. There is also increased support for C++14 and
> C++17 language features: https://docs.microsoft.com/en-
> us/cpp/visual-cpp-language-conformance
>
> These days we tend not to support older VS for too long, so after some
> transition period you can probably expect that VS2017 will be required to
> build locally, ifdefs can be removed, etc. VS2017 Community Edition is a
> free download and it can coexist with previous compilers. Installation
> instructions are at: https://developer.mozilla.org/
> en-US/docs/Mozilla/Developer_guide/Build_Instructions/
> Windows_Prerequisites#Visual_Studio_2017
>
> If you have concerns, please talk to me or visit the bug. Thanks!
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Kevin Brosnan]

On Fri, Oct 27, 2017 at 12:03 AM, Xidorn Quan  wrote:
> On Thu, Oct 26, 2017, at 12:24 PM, Ted Mielczarek wrote:
>> On the other hand, it's easier to
>> justify dropping support if VS is the last compiler holding us back from
>> being able to use new C++ features.
>
> FWIW, it's not at the moment. Currently we are really only blocked on
> GCC for new C++ features.
>
> From the language features table [1] we are still required to support
> GCC 4.9. IIRC it was because of Android build where GCC 4.9 is the
> highest version provided by NDK. Have we switched our Android build to
> Clang? If so, we should probably also bump our GCC requirement to
> unblock more C++ features. This is another topic, though.
>
> [1] https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
>
>
> - Xidorn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Nathan Froyd is working on getting clang builds for Android running in
https://bugzilla.mozilla.org/show_bug.cgi?id=1163171


Kevin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Xidorn Quan]

On Thu, Oct 26, 2017, at 12:24 PM, Ted Mielczarek wrote:
> On the other hand, it's easier to
> justify dropping support if VS is the last compiler holding us back from
> being able to use new C++ features.

FWIW, it's not at the moment. Currently we are really only blocked on
GCC for new C++ features.

>From the language features table [1] we are still required to support
GCC 4.9. IIRC it was because of Android build where GCC 4.9 is the
highest version provided by NDK. Have we switched our Android build to
Clang? If so, we should probably also bump our GCC requirement to
unblock more C++ features. This is another topic, though.

[1] https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code


- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[mhoye]

On 2017-10-26 12:19 PM, Ryan VanderMeulen wrote:

On 10/26/2017 10:14 AM, Milan Sreckovic wrote:
Are we locked into using the same compiler for the ESR updates?  In 
other words, do we need to keep VS2015 for ESR52 builds until they 
are not needed anymore?


Our compiler toolchains are determined with in-tree configs nowadays, 
so this change won't impact any other branches.


I'm pleased to discover that this change shouldn't hurt community 
developers on older hardware. VS2017 drops support for developing on 
some older versions of Windows Server, but doesn't otherwise cause major 
changes in hardware/software requirements.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Ryan VanderMeulen]

On 10/26/2017 10:14 AM, Milan Sreckovic wrote:
Are we locked into using the same compiler for the ESR updates?  In 
other words, do we need to keep VS2015 for ESR52 builds until they are 
not needed anymore?


Our compiler toolchains are determined with in-tree configs nowadays, so 
this change won't impact any other branches.


-Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[David Major]

It would be great to get these speed gains for 58, hot on the heels of the
57 release.

My plan is this: if I can get this landed by Monday, that still leaves two
weeks in the cycle. Based on my positive experience thus far with this
compiler (this update has been much more smooth than past ones), I'm
comfortable with that number. If it goes longer than that, I agree it makes
sense to wait for a new train.



On Thu, Oct 26, 2017 at 3:31 AM, Sylvestre Ledru  wrote:

> Hello,
>
>
> On 25/10/2017 23:48, David Major wrote:
> > I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> > 1408789.
> >
> In which version are you planning to land this change?
> As we are close to the end of the 58 cycle in nightly, it would be great
> to wait for 59.
>
> Thanks,
> Sylvestre
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[David Major]

Agreed, changing compilers of an already-released ESR isn't a good idea.

You could use 2017 to build ESR52 locally though, if that's what you're
asking. Our tree has supported 2017 builds for a good while, since it's the
default VS download from Microsoft and a number of Mozillians have been
using it.

On Thu, Oct 26, 2017 at 10:33 AM, Jonathan Kew  wrote:

> On 26/10/2017 15:14, Milan Sreckovic wrote:
>
>> Are we locked into using the same compiler for the ESR updates?  In other
>> words, do we need to keep VS2015 for ESR52 builds until they are not needed
>> anymore?
>>
>>
> Yes, IMO.
>
> Whether or not we're "locked" in any technical sense, I think we should
> probably lock ourselves there by policy, unless a specific bug in the older
> compiler is directly affecting ESR builds in a serious way, and can only be
> solved by updating.
>
> Short of something like that (which seems pretty unlikely!), the stability
> risk involved in switching compilers doesn't sound like it belongs anywhere
> near the ESR world.
>
> JK
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Jonathan Kew]

On 26/10/2017 15:14, Milan Sreckovic wrote:
Are we locked into using the same compiler for the ESR updates?  In 
other words, do we need to keep VS2015 for ESR52 builds until they are 
not needed anymore?




Yes, IMO.

Whether or not we're "locked" in any technical sense, I think we should 
probably lock ourselves there by policy, unless a specific bug in the 
older compiler is directly affecting ESR builds in a serious way, and 
can only be solved by updating.


Short of something like that (which seems pretty unlikely!), the 
stability risk involved in switching compilers doesn't sound like it 
belongs anywhere near the ESR world.


JK
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Milan Sreckovic]

Are we locked into using the same compiler for the ESR updates?  In 
other words, do we need to keep VS2015 for ESR52 builds until they are 
not needed anymore?


On 26-Oct-17 3:31, Sylvestre Ledru wrote:

Hello,


On 25/10/2017 23:48, David Major wrote:

I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
1408789.


In which version are you planning to land this change?
As we are close to the end of the 58 cycle in nightly, it would be great
to wait for 59.

Thanks,
Sylvestre

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


--
- Milan (mi...@mozilla.com)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Sylvestre Ledru]

Hello,


On 25/10/2017 23:48, David Major wrote:
> I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> 1408789.
>
In which version are you planning to land this change?
As we are close to the end of the 58 cycle in nightly, it would be great
to wait for 59.

Thanks,
Sylvestre

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Ted Mielczarek]

On Wed, Oct 25, 2017, at 05:48 PM, David Major wrote:
> I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> 1408789.

Thanks for doing the work on this!


> VS2017 has optimizer improvements that produce faster code. I've seen
> 3-6%
> improvement on Speedometer. There is also increased support for C++14 and
> C++17 language features:
> https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance
> 
> These days we tend not to support older VS for too long, so after some
> transition period you can probably expect that VS2017 will be required to
> build locally, ifdefs can be removed, etc. VS2017 Community Edition is a
> free download and it can coexist with previous compilers. Installation
> instructions are at:
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites#Visual_Studio_2017

Lately we've settled on maintaining support for ~1 release cycle, which
gives us a buffer before we rip out support in case we need to roll back
because we've found a major compiler bug or something like that. It's
easier to justify maintaining support if we have CI to ensure that we're
not constantly breaking things. On the other hand, it's easier to
justify dropping support if VS is the last compiler holding us back from
being able to use new C++ features.

-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Visual Studio 2017 coming soon

[David Major]

I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
1408789.

VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
improvement on Speedometer. There is also increased support for C++14 and
C++17 language features:
https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance

These days we tend not to support older VS for too long, so after some
transition period you can probably expect that VS2017 will be required to
build locally, ifdefs can be removed, etc. VS2017 Community Edition is a
free download and it can coexist with previous compilers. Installation
instructions are at:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites#Visual_Studio_2017

If you have concerns, please talk to me or visit the bug. Thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017

[Justin Dolske]

Until we officially support it, can we have mach print out a warning (w/
link to a bug number or wiki page) if you try to build with it? (And, of
course, with some opt-in mechanism to use it anyway.)

ISTR in the past it was relatively common for people who upgraded (or were
just installing the latest on a new system) to run into mysterious failures
and get frustrated.

Justin

On Wed, Nov 16, 2016 at 5:26 PM, Gregory Szorc <g...@mozilla.com> wrote:

> Microsoft announced Visual Studio 2017 RC today. As always, there are some
> compelling reasons to support the new version. They have blogged
> extensively about performance improvements around compiling/linking and IDE
> interactions, which are always exciting.
>
> If you install VS2017 RC today, configure won't detect it. Even if you have
> environment variables set, configure still barfs because paths of things
> within the installation have changed.
>
> Bug 1318143 (alias: vs2017) has been established to track making everything
> work with VS2017.
>
> At this time, we have no timeline for transitioning shipped Firefox
> binaries to VS2017. Obviously we need to wait for VS2017 final. After that,
> we'd likely need some compelling reasons to undergo the transition. We
> will, however, stand up VS2017 builds (likely no to few tests) in
> automation as a tier-2 platform so developers have visibility into VS2017
> compatibility. Bug 1318193 tracks that.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Visual Studio 2017

[Gregory Szorc]

Microsoft announced Visual Studio 2017 RC today. As always, there are some
compelling reasons to support the new version. They have blogged
extensively about performance improvements around compiling/linking and IDE
interactions, which are always exciting.

If you install VS2017 RC today, configure won't detect it. Even if you have
environment variables set, configure still barfs because paths of things
within the installation have changed.

Bug 1318143 (alias: vs2017) has been established to track making everything
work with VS2017.

At this time, we have no timeline for transitioning shipped Firefox
binaries to VS2017. Obviously we need to wait for VS2017 final. After that,
we'd likely need some compelling reasons to undergo the transition. We
will, however, stand up VS2017 builds (likely no to few tests) in
automation as a tier-2 platform so developers have visibility into VS2017
compatibility. Bug 1318193 tracks that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform