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
On Tuesday, May 8, 2018 at 7:10:47 PM UTC+5:30, 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 rep
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
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 b
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
t; On Mon, Mar 12, 2018 at 5:29 PM, Ryan VanderMeulen
> 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 S
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
hat 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
On Tue, Mar 13, 2018 at 2:29 AM, Ryan VanderMeulen
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 (U
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 t
f 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 lurki
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
furt
>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
>>
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 f
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 l
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 t
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
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 invalidati
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 bec
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 lam
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/1
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
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
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, w
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'
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.
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++ featur
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 determin
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 wo
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),
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
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
proba
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 bui
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
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 als
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/visua
On Thu, Nov 17, 2016 at 02:00:00PM -0800, Justin Dolske wrote:
> 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 r
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 wrote:
> Microsoft announced Visual Studio 2017 RC today. As always, there are some
> compelling reasons to support the new version. They have blogged
> ex
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
39 matches
Mail list logo
