Re: Code Coverage on Phabricator
Of course, sorry for the weird formatting... Here is the right version: Hi everyone, We have recently implemented a solution to integrate code coverage results into Phabricator. Coverage information is uploaded either automatically for revisions after they are landed in mozilla-central (for example for release managers when looking at uplift requests), or on-demand for in-progress revisions. For revisions under review, in order to upload coverage you just need to trigger a try push containing code coverage builds and tests, e.g. by using: $ mach try fuzzy --full and selecting the relevant ccov builds and test suites. In the future, we will also likely automatically trigger coverage try builds for revisions we deem to be risky, alongside the on-demand option. For example you can see my try build at https://treeherder.mozilla.org/#/jobs?repo=try=38213b49dc00cd108dfa9a246045ed677c34de91 which produced the coverage information for my revision at https://phabricator.services.mozilla.com/D14758. Once the try build and linked tests finish, the coverage artifacts get parsed and uploaded to the Phabricator revisions corresponding to the commits in the try push. The analysis works on *all* commits in the try push that are linked to Phabricator revisions. Stacks of revisions are supported as well. The coverage information is shown on Phabricator both at a high-level view, in the "Revision Contents" section, and at a detailed view in the "Diff" section. The "Revision Contents" section contains a list of the files modified by the revision, showing both the coverage percentage of the whole file and the coverage percentage of touched lines. The "Diff" section instead shows the coverage line per line, coloring the bar on the right-hand side. Orange corresponds to "uncovered lines", light blue corresponds to "non-executable lines" (e.g. a comment, a definition, and so on), dark blue corresponds to "covered lines". When hovering the bar, the corresponding line is highlighted in the same color. You can find an alternative version of this email with fancy screenshots at https://marco-c.github.io/2019/01/21/code-coverage-phabricator.html or https://release.mozilla.org/tooling/codecoverage/2019/01/20/code-coverage-on-phabricator.html. Thanks, Marco. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Update on rustc/clang goodness
We've also been running Windows code coverage builds with clang on CI for a while (since December), with almost all tests. - Marco. On Friday, May 11, 2018 at 2:35:57 AM UTC+2, Anthony Jones wrote: > You may already know that the Low-Level Tools team support important tools > and code infrastructure. Lately we’ve also been improving our rustc/clang > (LLVM) story and I’d like bring everyone up to date. > > There are a lot of important and interesting things going on: > > * Michael Woerister and Nathan Froyd recently (mid-March) enabled Rust > incremental compilation for Firefox developers > * Michael is experimenting with cross language inlining[1] (rustc/clang) > using LTO > * Preliminary results show compiling LLVM with clang and using LTO on > rustc improves stylo compilation time by around 15% [on-my-machine > measurements] > * LTO requires more work to support Firefox > * Nick Nethercote has started speeding up rustc[2] and has already had a > number of wins > * David Major has got Windows clang builds working with green tests > * LTO is still buggy (but works well enough to run benchmarks) and > PGO won’t run on Windows > * Win32 - clang with LTO w/o PGO is marginally faster than MSVC with > LTO/PGO > * Win64 - clang with LTO w/o PGO is ~5-10% slower than MSVC with > LTO/PGO > * Windows users can build locally with clang[3] > * Mike Hommey is tracking improvements and regressions in the Rust > compiler (performance regression[4], crash reporting[5] and more crash > reporting[6]) > * Tom Tromey is continuing to work on first class Rust support in GDB and > LLDB > > Note: this a summary of things rustc/clang stuff that is happening only. > > Ultimately, I’d like to see us standardise on clang on all platforms because > it makes Rust/C++ integration better as well as making things simpler for > developers and build system maintainers. We’ll get more done if we make our > own lives simpler. > > I have some specific requests for you: > > Let me know if you have specific Firefox related cases where Rust is > slowing you down (thanks Jeff [7]) > Cross language inlining is coming - avoid duplication between Rust and > C++ in the name of performance > Do developer builds with clang > > Anthony > > [1] https://github.com/rust-lang/rust/issues/49879 > [2] > https://blog.mozilla.org/nnethercote/2018/04/30/how-to-speed-up-the-rust-compiler-in-2018/ > [3] > https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Building_Firefox_on_Windows_with_clang-cl > [4] https://github.com/rust-lang/rust/issues/49873 > [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1456150 > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1448868 > [7] https://github.com/rust-lang/rust/issues/50584 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsAutoConfig
Hey Mike, according to our code coverage report, nsAutoConfig is never executed during tests. As far as I can see, it is actually not tested, as the test you mentioned is not setting the autoadmin.global_config_url pref that would make nsReadConfig instantiate nsAutoConfig. Is that correct? I'd like to understand whether this is a problem in our coverage collection tools that are not picking up this file for some reason or if it actually is not tested. I've opened https://bugzilla.mozilla.org/show_bug.cgi?id=1413600. - Marco. On Tuesday, October 31, 2017 at 4:22:06 PM UTC+1, mka...@mozilla.com wrote: > On Tuesday, October 31, 2017 at 12:10:21 AM UTC-5, Nicholas Nethercote wrote: > > Hi, > > > > I was just looking at the extensions/pref/autoconfig/ directory and trying > > to understand what it does. > > > > As far as I can tell, the code is there to allow custom deployments with > > particular prefs set, as described at > > https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment#Configuration > > > > It's initialized by modules/libpref/Preferences.cpp if a > > "general.config.filename" pref is found: > > http://searchfox.org/mozilla-central/rev/1ebd2eff44617df3b82eea7d2f3ca1b60cc591a0/modules/libpref/Preferences.cpp#3907-3920 > > > > There is also some MozHarness code relating to it here: > > http://searchfox.org/mozilla-central/source/testing/mozharness/mozharness/mozilla/firefox/autoconfig.py > > > > Just to check: is this still supported functionality? > > > > Thanks. > > > > Nick > > Yes, this is very much supported functionality. It is our primary means of > enterprise customization right now. > > The reason there are very few tests is because when it was first developed, > it wasn't possible to write tests that involved putting down files before > startup. There are some tests now: > > http://searchfox.org/mozilla-central/source/extensions/pref/autoconfig/test/unit > > Mike Kaply ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)
It would be interesting to know the specifications of the system running the tests and to run them on systems with differing characteristics (e.g. different graphics card, different amount of RAM, etc.). - Marco. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
