Re: PSA: Visual Studio 2017 15.6 now required to build 61+
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 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 > 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+
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 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: Core::Build Config has moved
Bug 1406536 has the context. I should note that we now have shiny new components for aspects of the build workflow including bootstrapping, linting, static analysis, generated documentation, and CI task configuration. I encourage people to look at those components at https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox%20Build%20System - and possibly even follow components that are relevant to your interests. The new components are still low volume, unlike the main "General" component. On Tue, Mar 13, 2018 at 11:20 AM, Kartikaya Gupta wrote: > I was looking to file a bug in Core::Build Config and discovered it > doesn't exist any more. :mccr8 told me there is now a "Firefox Build > System" product that encompasses what used to be Core::Build Config. > > I'm not a build peer so I don't know anything more than this; if > anybody wants more context hopefully the build peers can answer any > questions. This is just a heads-up in case anybody else goes looking > for the component. > > Cheers, > kats > ___ > 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
PSA: Core::Build Config has moved
I was looking to file a bug in Core::Build Config and discovered it doesn't exist any more. :mccr8 told me there is now a "Firefox Build System" product that encompasses what used to be Core::Build Config. I'm not a build peer so I don't know anything more than this; if anybody wants more context hopefully the build peers can answer any questions. This is just a heads-up in case anybody else goes looking for the component. Cheers, kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review
Also sprach Myk Melez: > For example, XPCOM supports component registration and overriding > at runtime. But it isn't clear that Firefox needs those features, > now that it no longer supports XUL extensions (unless perhaps for > system extensions). I believe this is a feature we rely on for bypassing invalid TLS certificates in Marionette by replacing nsICertOverrideSerivce [1]. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please try out clang-cl and lld-link on Windows
It's really exciting to see such rapid progress being made here. Thanks David! On Tue, Mar 13, 2018 at 7:31 AM, David Major wrote: > Link xul.dll in 20 seconds with this one weird trick! > > > Hi everyone, > > clang-cl builds of Firefox have come a long way, from being a hobby project > of a few developers to running static analysis in CI for more than a year > now. The tools are in really good shape and should be ready for broader use > within Mozilla at this point. > > Bug 1443590 is looking into what it would take to ship official builds with > clang-cl and lld-link, but in the meantime it's possible to do local builds > already. I'd like to invite people who develop on Windows to give it a try. > > *** Reasons to use clang-cl and lld-link locally *** > > - Speed! lld is known for being very fast. I'm serious about 20-second > libxuls. That's a non-incremental link, with identical code folding > enabled. For comparison, MSVC takes me over two minutes. > > - Speed again! clang-cl will integrate with upcoming sccache/icecream work. > > - Much clearer and more actionable error messages than MSVC > > - Make your own ASan and static analysis builds (the latter need an LLVM > before r318304, see bug 1427808) > > - Help ship Firefox with clang-cl by getting more eyes and machines on > these tools > > *** Reasons not to use clang-cl and lld-link locally (yet) *** > > - You are testing codegen-level fixes or optimizations and need to see the > exact bits that will be going out to users > > - lld-link currently doesn’t support incremental linking -- but with full > linking being so fast, this might not matter > > - You do artifact builds that don't use a local compiler > > *** How do I get started? *** > > https://developer.mozilla.org/en-US/docs/Mozilla/Developer_ > guide/Build_Instructions/Building_Firefox_on_Windows_with_clang-cl > > A number of build system changes have landed that make these builds much > easier than before. For example you no longer need to use old versions of > MozillaBuild. > > Note that clang-cl builds still depend on an MSVC installation for headers, > libraries, and auxiliary build tools, so don't go uninstalling your Visual > Studio just yet. > > If you run into any problems, please stop by #build or visit the shiny new > Firefox Build System product in Bugzilla (formerly Core :: Build Config). > > 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: Proposal to replace the NS_ASSERT function in JS with console.assert
This has now landed in Bug 1431050 - remaining consumers were either migrated to console.assert or changed to throw an exception. You can continue to use console.assert instead of NS_ASSERT in JS. If you find a case where console logging from chrome code doesn't do what you expect please let me know. Thanks, Brian On Mon, Feb 26, 2018 at 10:24 AM, Marco Bonardo wrote: > On Mon, Feb 26, 2018 at 7:02 PM, Brian Grinstead > wrote: > > console.assert doesn't throw an exception, and neither does NS_ASSERT. > So I don’t think replacing consumers with exceptions is correct if we want > to keep the current behavior. But I guess the intent for places code in bug > 1431050 is to change the behavior and make those assertions throw? > > By looking at the patch, some consumers used it wrongly expecting it > to interrupt the code (that likely threw a few lines later). While > other code threw an exception explicitly after NS_ASSERT. > Thus the common need seems to be "print a stack somewhere and throw". > For that we can just wrap console.assert into a local util that > throws, it's not a problem. > Afaik, the only other advantage of NS_ASSERT was to make the assertion > very visible to Nightly users, so they could report a bug. But that > also had downsides. > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Web-Feed subscription improvements
Hello dear Firefox development community! As a fond user of the "subscribe to this page" button I sadly acknowledge to see the deprecation of navigator.registerContentHandler(). I'm not here to grouse about it, but rather inquire about any plans to have a user-friendly possibility for adding content handlers (other than editing about:config). Being stuck with "live bookmarks" and "my yahoo" as a default may be enough for some users, but I'd rather use my own. A mechanism I'd like to propose: The pull-down for the subscription page already allows to choose an application on the client's file system; could we supply another entry to add a web application? I'd appreciate that! In general, I find the current state of the "subscribe" page lacking quite some explanations. For example, if I select a local application for feed subscription what arguments will be passed? At least a link for further reading would help immensely, adding a "what is this?" to the page for some context about Web-Feeds could be quite helpful as well. Users without prior knowledge about Web-Feeds might benefit from it, especially when they explore Firefox's customization features. Also, could we maybe include these content handlers in the data synced with Firefox Accounts? It's rather discomforting to add the three lines of properties to about:config manually to every profile I create. best regards, -1 PS: I'm sorry if this post violates any posting guidelines, I'm not accustomed to newsgroups. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Please try out clang-cl and lld-link on Windows
Link xul.dll in 20 seconds with this one weird trick! Hi everyone, clang-cl builds of Firefox have come a long way, from being a hobby project of a few developers to running static analysis in CI for more than a year now. The tools are in really good shape and should be ready for broader use within Mozilla at this point. Bug 1443590 is looking into what it would take to ship official builds with clang-cl and lld-link, but in the meantime it's possible to do local builds already. I'd like to invite people who develop on Windows to give it a try. *** Reasons to use clang-cl and lld-link locally *** - Speed! lld is known for being very fast. I'm serious about 20-second libxuls. That's a non-incremental link, with identical code folding enabled. For comparison, MSVC takes me over two minutes. - Speed again! clang-cl will integrate with upcoming sccache/icecream work. - Much clearer and more actionable error messages than MSVC - Make your own ASan and static analysis builds (the latter need an LLVM before r318304, see bug 1427808) - Help ship Firefox with clang-cl by getting more eyes and machines on these tools *** Reasons not to use clang-cl and lld-link locally (yet) *** - You are testing codegen-level fixes or optimizations and need to see the exact bits that will be going out to users - lld-link currently doesn’t support incremental linking -- but with full linking being so fast, this might not matter - You do artifact builds that don't use a local compiler *** How do I get started? *** https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Building_Firefox_on_Windows_with_clang-cl A number of build system changes have landed that make these builds much easier than before. For example you no longer need to use old versions of MozillaBuild. Note that clang-cl builds still depend on an MSVC installation for headers, libraries, and auxiliary build tools, so don't go uninstalling your Visual Studio just yet. If you run into any problems, please stop by #build or visit the shiny new Firefox Build System product in Bugzilla (formerly Core :: Build Config). Thanks! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: FYI: sccache 0.2.6 released, contains fix for frequent hang in 0.2.5
For macOS users this will hopefully be available from brew shortly: https://github.com/Homebrew/homebrew-core/pull/25164 Alex On Tue, Mar 13, 2018 at 9:21 AM, Ted Mielczarek wrote: > Hello, > > Yesterday I tagged and released sccache 0.2.6: > https://github.com/mozilla/sccache/releases/tag/0.2.6 > > This contains a fix for a hang that users were encountering with sccache > 0.2.5 due to the make jobserver support added in that version. If you are > using 0.2.5 you will want to update. If you were holding off on updating > because of that bug, you should now be able to update without issues. > > -Ted > ___ > 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: incremental compilation for opt Rust builds
On Tue, Mar 13, 2018 at 3:10 AM, Henri Sivonen wrote: > On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd wrote: >> (Our release builds use -O2 for Rust code.) > > What does cargo bench use by default? > (https://internals.rust-lang.org/t/default-opt-level-for-release-builds/4581 > suggests -O3.) As mentioned by Alexis, -O3 is indeed what gets used by default. > That is, is cargo bench for a crate that's vendored into m-c > reflective of that crate's performance when included in a Firefox > release? I do not know. I know that folks working on WebRender were finding that -O3 produces *much* better code for certain things; they filed bugs for rustc that I can't find right now. I don't know if those bugs have been addressed. When Stylo was getting off the ground a year ago, mbrubeck did some -O2 vs. -O3 size analysis, which led to some -O2 vs. -O3 performance analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1328954. The conclusion there is that -O3 wasn't worth it and came with a reasonably large codesize increase. I guess the answer is "probably, but you should measure to make sure"? -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: incremental compilation for opt Rust builds
Oh and here's the one documented in the nightly docs, just for completeness # The benchmarking profile, used for `cargo bench` and `cargo test --release`.[profile.bench]opt-level = 3debug = falserpath = falselto = falsedebug-assertions = falsecodegen-units = 1panic = 'unwind'incremental = falseoverflow-checks = false On Tue, Mar 13, 2018 at 9:24 AM, Alexis Beingessner wrote: > The defaults of the various cargo profiles are documented here: > https://doc.rust-lang.org/cargo/reference/manifest.html > > The relevant entry is: > > # The benchmarking profile, used for `cargo bench` and `cargo test > --release`.[profile.bench]opt-level = 3debug = falserpath = falselto = > falsedebug-assertions = falsecodegen-units = 1panic = 'unwind' > > Note that we always build with panic=abort which improves codegen; not > sure about which conditions we use lto for rust code off the top of my head. > > > On Tue, Mar 13, 2018 at 3:10 AM, Henri Sivonen > wrote: > >> On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd wrote: >> > (Our release builds use -O2 for Rust code.) >> >> What does cargo bench use by default? >> (https://internals.rust-lang.org/t/default-opt-level-for-rel >> ease-builds/4581 >> suggests -O3.) >> >> That is, is cargo bench for a crate that's vendored into m-c >> reflective of that crate's performance when included in a Firefox >> release? >> >> -- >> Henri Sivonen >> hsivo...@hsivonen.fi >> https://hsivonen.fi/ >> ___ >> 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: incremental compilation for opt Rust builds
The defaults of the various cargo profiles are documented here: https://doc.rust-lang.org/cargo/reference/manifest.html The relevant entry is: # The benchmarking profile, used for `cargo bench` and `cargo test --release`.[profile.bench]opt-level = 3debug = falserpath = falselto = falsedebug-assertions = falsecodegen-units = 1panic = 'unwind' Note that we always build with panic=abort which improves codegen; not sure about which conditions we use lto for rust code off the top of my head. On Tue, Mar 13, 2018 at 3:10 AM, Henri Sivonen wrote: > On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd wrote: > > (Our release builds use -O2 for Rust code.) > > What does cargo bench use by default? > (https://internals.rust-lang.org/t/default-opt-level-for- > release-builds/4581 > suggests -O3.) > > That is, is cargo bench for a crate that's vendored into m-c > reflective of that crate's performance when included in a Firefox > release? > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > ___ > 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
FYI: sccache 0.2.6 released, contains fix for frequent hang in 0.2.5
Hello, Yesterday I tagged and released sccache 0.2.6: https://github.com/mozilla/sccache/releases/tag/0.2.6 This contains a fix for a hang that users were encountering with sccache 0.2.5 due to the make jobserver support added in that version. If you are using 0.2.5 you will want to update. If you were holding off on updating because of that bug, you should now be able to update without issues. -Ted ___ 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+
On Tue, Mar 13, 2018 at 09:05:50AM +0200, Henri Sivonen wrote: > 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 (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: incremental compilation for opt Rust builds
On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd wrote: > (Our release builds use -O2 for Rust code.) What does cargo bench use by default? (https://internals.rust-lang.org/t/default-opt-level-for-release-builds/4581 suggests -O3.) That is, is cargo bench for a crate that's vendored into m-c reflective of that crate's performance when included in a Firefox release? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ 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+
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 (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
