Engineering Effectiveness Newsletter #2
[cross-posting to firefox-dev] Hello fellow Mozillians, The Engineering Effectiveness Team works on a disparate number of topics with the goal of improving every aspect of Firefox development. Since most of our activities are not directly visible, we have decided to regularly write a newsletter to get you up to speed! This is the second iteration of the newsletter for the period of April, May and June. = Highlights = - Andrew Halberstadt and Marco Castelluccio improved the `mach try auto` automatic test selector to run fewer tests and catch more failures <https://groups.google.com/forum/#!topic/mozilla.dev.platform/Eeg7vIvc3kM>, by scheduling (for a subset of suites) at the manifest level. Please use it and report any feedback! - Mike Hommey, Connor Sheehan and others stood up the KaiOS project branch <https://bugzilla.mozilla.org/show_bug.cgi?id=1628832>, a big milestone for the first phase of the project. - Christian Holler wrote a tutorial for libfuzzer-based fuzzing <https://firefox-source-docs.mozilla.org/tools/fuzzing/fuzzing_interface.html>. Feel free to contact him should you need help in adding fuzzing to your module. - Emma Humphries transitioned Bugzilla severities to a new system, using S1...S5 <https://docs.google.com/document/d/1HYPBDePvYX26JOrk6ymsEeViwTdWhCVL-elSwInsMKw/edit>. = Cost savings and performance improvements = - Marco Castelluccio and Andrew Halberstadt enabled the first iteration of machine learning-based scheduling on autoland, which means 20-30% fewer jobs to execute with similar coverage of regressions. - David Major started generating the Clang binary for CI using PGO, which leads to a decrease in build time by 5 to 9% <https://bugzilla.mozilla.org/show_bug.cgi?id=1326486#c17>. - Nicholas Nethercote improved Rust compiler's performance even more (up to 18%) <https://blog.mozilla.org/nnethercote/2020/04/24/how-to-speed-up-the-rust-compiler-in-2020/>. - Simon Fraser built a dashboard <https://datastudio.google.com/reporting/1GVefOEovUP_oxJKiRlsAeoJuxcoDjlK3/page/WOR0> to visualize CI costs by person / manager / team. - The Taskcluster team migrated the community and Firefox CI clusters back-end from Azure to Postgres. It is faster and more reliable, and reduces the number of cloud providers involved in Taskcluster setup. - Joel Maher identified orphaned workers as a significant overhead, and is working to reduce them. - Chris AtLee optimized test packages <https://bugzilla.mozilla.org/show_bug.cgi?id=1632601> to reduce test overhead on Windows 7 by 4-5 minutes. - Nicholas Nethercote landed and enabled fix-stacks on all platforms, which leads to a 100x perf improvement in some log processing <https://blog.mozilla.org/nnethercote/2020/04/15/better-stack-fixing-for-firefox/>. - Jesse Schwartzentruber made significant progress in migrating the fuzzing infrastructure to Taskcluster. = Phabricator and code quality = - Bastien Abadie changed the code review bot to use Phabricator lint results <https://lists.mozilla.org/pipermail/dev-platform/2020-March/025348.html> (example on https://phabricator-dev.allizom.org/D1758), making the issues found by the bot less spammy (issues cleared after diff update) and making it clear when issues would break CI. - David Lawrence reworked our Phabricator extensions to unblock a major Phabricator upgrade, which brings two new interesting features: inline comments on character ranges <https://secure.phabricator.com/phame/post/view/776/quick_look_inline_comments_on_character_ranges/>, and edit suggestions <https://secure.phabricator.com/phame/post/view/777/quick_look_suggesting_edits_with_inline_comments/>. As always Chris Kolosiwsky from the Cloud Operations team was instrumental in getting this deployed. - Andi Bogdan Postelnicu made build failure reporting at review phase use clang-tidy instead of coverity, which results in better error messages and detects more issues. - Linting improvements for Python: pylint was added as a new linter <https://bugzilla.mozilla.org/show_bug.cgi?id=1623024> (issues tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1647263) and flake8 was updated to 3.8.3 <https://phabricator.services.mozilla.com/D80078>. - Bastien Abadie and Sylvestre Ledru wrote a blog post on Hacks <https://hacks.mozilla.org/2020/04/code-quality-tools-at-mozilla/> about Mozilla's tools for code quality. - Sylvestre Ledru wrote a new linter to reject the introduction of new occurrences of some non-inclusive wording <https://bugzilla.mozilla.org/show_bug.cgi?id=1642825>. = Security and stability = - The first security bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1618158> found by PHC (Probabilistic Heap Checker), built by Nicholas Nethercote, was fixed. - Our fuzzing found a security bug in irregexp <https://bugzilla.mozilla.org/show_bug.cgi?id=1638154> which also seems to affect Chrome stabl
Re: Searchfox at All-Hands: Who's interested?
I'd be interested too, in particular about 1 as we'd like to integrate more things into Searchfox (code coverage, static analysis and linting issues to name a few). - Marco. Il 09/01/20 19:43, Andrew Sutherland ha scritto: > Are people interested in a session(s) at the All-Hands on Searchfox? > If you're interested in any of the following things, please email me > here or at as...@mozilla.com or let me know via other channels, and > let me know which of the following you'd be interested in. My goal is > to get a rough count so I can try and book a room if there's interest. > > > 1. Contributing to Searchfox. Want to improve something about > Searchfox? You can! > > We can help you get set up with a local VM and credentials to try your > changes on mozilla-central in the cloud without your laptop melting > down! Already tried contributing and tried to melt your own laptop > down out of frustration with setting up VirtualBox? We can help with > that too! (Also, you can now use libvirt and save yourself a bundle > in new laptops!) > > Already have the VM setup and appreciate the extensive Searchfox > documentation at https://github.com/mozsearch/mozsearch/ and > https://github.com/mozsearch/mozsearch-mozilla/ but want some guidance > on how to implement the thing you want to do? We can help with that > double too! > > > 2. Talking Searchfox UX, especially as it relates to upcoming > features/possibilities on the "fancy" branch. > > I've been doing some hacking to support a more structured > representation of data to support creating diagrams[1] for both > documentation purposes and to make code exploration and understanding > easier. > > This potentially opens up a bunch of new features like > https://clicky.visophyte.org/files/screenshots/20190820-174954.png > demonstrates, providing both the type of a thing you've clicked on, > plus being able to see its documentation or uses without having to > click through. But the more features you try and cram into something, > the more potential for them to get in the way of what the user > actually wanted to do. For example, the helpful popup also probably > hides the code you were trying to look at. Should the information be > in a big box at the bottom of the screen like cs.chromium.org? The > top? Configurable? > > Also, for the diagrams, how to make them most accessible. My current > approach[2] attempts to leverage the inherent hierarchy into a ul/li > tree-structure that directly mirrors the clustering used in the > graphviz diagram, with in and out edges indicated at each node. > Planned work includes figuring out how to best get NVDA to make those > edges traversable so that the traversal is possible with more than > manually using ctrl-f. > > > 3. Talking Searchfox data exposure for your own tools, especially as > it relates to the new data available on the "fancy" branch. > > Do you have a tool that uses Searchfox and wish its result format > wasn't clearly just a data structure pre-baked for presentation > purposes that the receiving JS perform a light HTML-ization on? > > > Andrew > > > 1: Here are some examples of diagrams created during prototyping: > > - Manually creation by clicking on calls/called-by edges in iterative > search results exploration: > https://clicky.visophyte.org/files/screenshots/20190503-133733.png > - Automatic diagram from heuristics based on local same-file control > flow: https://clicky.visophyte.org/files/screenshots/20190821-165907.png > - Blockly based diagramming without rank overrides or colors applied: > https://clicky.visophyte.org/files/screenshots/20191231-214320.png > > 2: > https://github.com/asutherland/mozsearch/blob/00a60f899936559ed4d158999278660eb5c98df5/ui/src/grokysis/frontend/diagramming/class_diagram.js#L480 > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
New coverage frontend and zero coverage checker
Hello everyone, We are switching from relying on codecov.io and coveralls.io to our own backend/frontend to handle coverage data. This will allow us to build more features such as filtering coverage results by OS, filtering by test suite, etc.. Moreover, codecov.io and coveralls.io were not able to handle the load of our large repositories. With a custom backend, we now have consistent performance. The code coverage reports now live at https://mozilla.github.io/code-coverage-reports/ (the URL might change, but we will setup a redirect if it does). You can see a graph of the coverage over time (clicking on one of the points of the graph will bring you to that revision), see coverage summaries by directory, see source code with coverage highlight (green for covered, red for uncovered). In a few days, we will stop uploading coverage data to codecov.io and coveralls.io. On a related note, we have recently enabled a new checker in our Review Bot which will warn you if one of the files in your patch is completely uncovered by tests (which might mean that the file should be tested, https://bugzilla.mozilla.org/show_bug.cgi?id=untestedcode-codecoverage, or that the file is dead code, https://bugzilla.mozilla.org/show_bug.cgi?id=deadcode-codecoverage, or that it is tested in a configuration which is not yet supported by code coverage). As usual, you can also browse our full zero coverage report at https://mozilla.github.io/code-coverage-reports/zero_coverage_report.html. - Marco, on behalf of the team (special thanks to Bastien who has been doing most of the work on the new backend/frontend). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Bot automatically assigning components to Untriaged (and some General) bugs
Hello all, I just wanted to notify you that since a few weeks ago, our release mgmt bot has started automatically assigning components to untriaged bugs. The results look good so far, so we are going to keep it enabled. The bot is using machine learning to select a component, so it isn't 100% perfect. If you see a mistake, please correct it, and the bot will learn from its mistakes. We are assigning product/component to bugs from 'Untriaged'. We are also assigning product/component to bugs from 'General', which is sometimes used as a catch-all component, as in many cases a better component can be found. This is of course much more difficult than the Untriaged case, so we apply the change only when the bot "feels" confident enough. More information about the bot at https://hacks.mozilla.org/2019/04/teaching-machines-to-triage-firefox-bugs/. Thanks, Marco. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using inline variables (C++17) in Gecko
The code coverage build is using GCC 6, if you do a try build don't forget to include that too (you'll need to pass the "--full" argument if you are using mach try fuzzy). The last time I tried, switching to GCC 7 caused a lot of timeouts (https://bugzilla.mozilla.org/show_bug.cgi?id=1410217#c5), but I didn't investigate more. - Marco. Il 20/03/19 10:57, Mike Hommey ha scritto: > Sorry for the late answer. Thanks for prodding me on irc. > > On Sat, Feb 23, 2019 at 06:36:39PM -0800, Emilio Cobos Álvarez wrote: >> Hey, >> >> I have a use-case for inline variables, and it's not 100% clear to me >> how up-to-date is [1], so asking this mailing-list directly. >> >> Looks like they're supported from clang 3.9 [2] and gcc 7 [3]. >> >> We're requiring clang 4.0+ to build already, and IIUC we don't build >> with MSVC anymore. But looks like we still support gcc 6 (which I guess >> means I can't use them right now). >> >> Is that right? If so, how far are we from requiring gcc 7 to build? > According to [1], the only main distro that would have a hard time > _building_ Firefox with such a requirement and that is not EOL is Debian > 9. > > Now, two things that do not appear yet on that table, because I haven't > added them, is rustc and nasm. > > As only the ESR version really has any sort of impact on Debian stable, > and the next ESR is, afaik, going to be 68, the requirements for rustc > and nasm for that version are going to be, respectively, (probably) 1.33 > and 2.13. Neither of those is available in Debian 9, so Debian will have > to backport those anyways. In the process of backporting rustc, they'll > have to backport a recent llvm too (probably 7, maybe 8), which will > mechanically bring a newer version of clang. So, with my Debian hat on, > even if a backport of a more recent version of GCC is not made for ESR68 > (there's precedent on using a "gcc-mozilla" package to build Firefox, so > that's also a possibility), there's going to be a recent enough version > of clang to build Firefox (and even then, Debian 9 has clang-4 too). > > So... with both my Debian and Mozilla hats on, I think we can reasonably > bump the requirement to GCC 7. > > However, there have been hurdles in the past with GCC 7 on Mozilla CI, > but IIRC that was related to trying to _ship_ those builds. We still do > have builds using GCC for various reasons, but we don't ship them, so > that should be fine. We _do_ have jobs that use a GCC plugin that may > not be ready to be updated to GCC 7, though. > > So, I'd say, change all occurrences of linux64-gcc-6 with linux64-gcc-7 > under taskcluster/ci, change the minimum GCC version supported in > build/moz.configure/toolchain.configure, and do a try build including > all the build types you changed the toolchain dependencies of, and see > how it goes. And file bugs if things don't go well :). > > Cheers, > > Mike > > 1. > https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Linux_compatibility_matrix > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running different instances of Firefox side-by-side
What is the bug where you made the initial changes? We should link to the bug the regressions caused by it (I've seen at least a couple regressions filed mentioning this post on dev-platform rather than the bug where the regression was introduced). - Marco. Il 13/03/19 22:14, Dave Townsend ha scritto: > A quick update here. After hearing some feedback from folks I've filed the > following bugs that I should have a patch up for in the next day: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1535021 Don't show the profile > manager when the default profile was selected and an existing instance is > running. > https://bugzilla.mozilla.org/show_bug.cgi?id=1535144 Return -new-instance > to its previous behaviour. > > On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend > wrote: > >> Woah this email got long. How Firefox considers whether to pass off to an >> existing instance of Firefox or continue launching a new one turns out to >> be more complex than you might expect. I'm mostly interested in making >> folks aware of and giving feedback on how this works after I've changed >> some things so feel free to jump down there. But I figured some folks might >> find some context in how things work currently. For that, read on! >> >> One of the goals of pushing to a profile-per-install model for Firefox is >> allowing users to run different versions of Firefox side-by-side without >> the additional hassle of editing shortcut files or running from the command >> line. This has meant changing the "remoting" code, which searches for >> existing instances of Firefox and passes command line arguments to them >> instead of starting up normally. I landed the changes to this a couple of >> days ago and I thought it was worthwhile explaining what has changed since >> it might not be exactly what you expect. And if that is the case figure out >> whether it makes sense to make any changes. >> >> *So first, a quick recap of what remoting has done in the past, because it >> varies from platform to platform...* >> >> OSX is the easy case. Firefox doesn't handle remoting at all. OSX does it >> all, assuming you are running Firefox by running an app bundle or a dock >> icon. OSX sees that an existing Firefox is running and just sends it a >> message, a new Firefox instance doesn't even start. I've made no changes >> here. >> >> Windows is the slightly more complex case. When run Firefox attempts to >> find an already running Firefox. If one exists it passes its command line >> off to it and quits. The -no-remote command line argument is a way to >> bypass this behaviour, running with it will stop the new Firefox from >> attempting to find an existing instance or becoming and instance that can >> be found by other instances. Basically there can only be one Firefox open >> that can be found by future invocations. The -new-instance command line >> argument is parsed on Windows ... and then ignored. >> >> Finally there is Linux. The more exciting case. Unless -no-remote or >> -new-instance are passed on startup linux will search for an existing >> version of Firefox based on a few criteria .. which varies a little >> depending on whether we're using dbus remoting or X remoting. We use X >> remoting if we are using X11 windows, and dbus if not (and dbus is >> supported). In both cases on startup Firefox attempts to find an existing >> instance of Firefox with the same remoting name (or you can provide a >> different remoting name with -a on the command line). dev-edition has one >> remoting name, all other versions of firefox have a different one. If there >> is more than one .. which one wins seems undefined. You can additionally >> pass "-P " in which case Firefox will only select an existing >> instance running the named profile. On X remoting there are a few extras. >> Passing "-a any" on the command line will find any running Firefox >> regardless of remoting name. Passing "-u " will consider >> Firefoxen run by the given user (otherwise it only looks at those run by >> the current user). -no-remote means FIrefox doesn't register itself to be >> found by future instances. -no-remote or -new-instance means we don't look >> for existing instances on startup. >> >> So that's all rather complicated. To make matters more fun the linux and >> windows implementations are handled by totally separate code running at >> different times during startup. The two key problems here were that windows >> completely didn't support more than one instance running, unless all but >> one were -no-remote, and linux was horribly complex and again unless you >> ran with command line arguments didn't support more than one Firefox at a >> time. We wanted something that allowed running Firefox release and Firefox >> beta and Firefox nightly with no special arguments at the same time. >> >> So I have done three things. Removed support for some of the things Linux >> supported. Made the code a lot more shared between windows and linux so >> things happen at
Code Coverage on Phabricator
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](https://treeherder.mozilla.org/#/jobs?repo=try=38213b49dc00cd108dfa9a246045ed677c34de91) which produced the coverage information for [my revision](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: Rust code coverage
Il 07/01/19 14:36, Henri Sivonen ha scritto: > On Fri, Jan 4, 2019 at 2:54 PM Marco Castelluccio > wrote: >> Hi everyone, >> we have recently enabled collecting code coverage for Rust code too, > Nice! > >> running Rust tests in coverage builds. > Does this mean running cargo test for each crate under > third_party/rust, running Firefox test suites or both? Both. We're running Rust specific tests (cargo test) like the Rusttests builds, and we're running the normal test suites. > > As for trying to make sense of what the numbers mean: > > Is the coverage ratio reported on lines attributed at all in ELF as > opposed to looking at the number of lines in the source files? We're using LLVM GCOV instrumentation, which uses debug info. > > What kind of expectations one should have on how the system measures > coverage for code that gets inlined? Inlining could cause inconsistencies in line counts, but it shouldn't cause inconsistencies in "is this line covered or not". We have thought of disabling inlining for coverage builds in the past, but there is a big runtime cost. Also, coverage instrumentation by itself increases the size of the functions, so fewer functions are inlined than in normal debug builds. - Marco. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Rust code coverage
Hi everyone, we have recently enabled collecting code coverage for Rust code too, running Rust tests in coverage builds. The support is still experimental, file bugs in the "Testing::Code Coverage" component if you see something fishy. The Rust reports are merged together with the C/C++/Java/JavaScript reports, and as usual you can find them at one of these links (we are working on a replacement for them, as they fail to scale to the size of our repository, often timing out on load): https://codecov.io/gh/mozilla/gecko-dev https://codecov.io/gh/marco-c/gecko-dev https://coveralls.io/github/marco-c/gecko-dev - Marco. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extension to integrate Searchfox features in Phabricator
Thanks for the report, I had built it really quickly without actually looking into perf. I think the issue should be fixed in the newest version of the extension (0.2.1), let me know if it isn't (I couldn't reproduce it). - Marco. P.S.: Should you find other problems, you can file issues at https://github.com/marco-c/mozsearch-phabricator-addon/issues. Il 11/10/2018 00:26, Bobby Holley ha scritto: > I noticed this extension seems to be causing significant jank while > typing comments into phabricator. I'll send a profile to Marco, but > just an FYI for anyone else who's using it. > > On Tue, Oct 2, 2018 at 6:03 AM Marco Castelluccio > mailto:mcastelluc...@mozilla.com>> wrote: > > I've built an (experimental) WebExtension to integrate some of the > Searchfox features into Phabricator. > I find it very useful to be able to search code while reviewing, but I > have to resort to opening a new > Searchfox tab and looking for the code that is being modified. This > extension makes my workflow much > more pleasant. > > You can find it at > https://addons.mozilla.org/addon/searchfox-phabricator/ (the > source code > is at > https://github.com/marco-c/mozsearch-phabricator-addon). > > Currently, the extension does: > 1) Highlight keywords when you hover them, highlighting them both > in the > pre-patch and in the post-patch view; > 2) When you press on a keyword, it offers options to search for the > definition, callers, and so on (the results are opened on > Searchfox in a > new tab). > > I'm planning to add support for sticky highlighting and blame > information (when hovering on the line number on the left side). > > - Marco. > > P.S.: The extension relies on parsing pages from Searchfox and from > Phabricator, so the maintenance might not be so easy. If there's > enough > interest, I might keep maintaining it or talk with someone to make > Searchfox data accessible in an easier way. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org <mailto: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
Extension to integrate Searchfox features in Phabricator
I've built an (experimental) WebExtension to integrate some of the Searchfox features into Phabricator. I find it very useful to be able to search code while reviewing, but I have to resort to opening a new Searchfox tab and looking for the code that is being modified. This extension makes my workflow much more pleasant. You can find it at https://addons.mozilla.org/addon/searchfox-phabricator/ (the source code is at https://github.com/marco-c/mozsearch-phabricator-addon). Currently, the extension does: 1) Highlight keywords when you hover them, highlighting them both in the pre-patch and in the post-patch view; 2) When you press on a keyword, it offers options to search for the definition, callers, and so on (the results are opened on Searchfox in a new tab). I'm planning to add support for sticky highlighting and blame information (when hovering on the line number on the left side). - Marco. P.S.: The extension relies on parsing pages from Searchfox and from Phabricator, so the maintenance might not be so easy. If there's enough interest, I might keep maintaining it or talk with someone to make Searchfox data accessible in an easier way. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Re: nsAutoConfig
Are you sure the test you wrote is testing nsAutoConfig and not nsReadConfig? nsReadConfig does not instantiate nsAutoConfig unless autoadmin.global_config_url exists and is not emtpy: https://codecov.io/gh/marco-c/gecko-dev/src/9ca76dcb7a5c61d33750e9718c02b11ba35c1032/extensions/pref/autoconfig/src/nsReadConfig.cpp#L205 https://dxr.mozilla.org/mozilla-central/rev/1c618b1a13662de7cec429f606367db3827b6dc7/extensions/pref/autoconfig/src/nsReadConfig.cpp#208 - Marco. Il 31/10/2017 10:38, Masatoshi Kimura ha scritto: > On 2017/10/31 19:22, Marco Castelluccio wrote: >> It is not covered by any automated test: >> https://codecov.io/gh/marco-c/gecko-dev/src/9ca76dcb7a5c61d33750e9718c02b11ba35c1032/extensions/pref/autoconfig/src/nsAutoConfig.cpp >> (this doesn't mean it isn't actually used ever, but it can be a clue). > Actually I wrote an automated test, although it is difficult for > coverage tools to find the usage: > https://bugzilla.mozilla.org/show_bug.cgi?id=1267567 > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsAutoConfig
It is not covered by any automated test: https://codecov.io/gh/marco-c/gecko-dev/src/9ca76dcb7a5c61d33750e9718c02b11ba35c1032/extensions/pref/autoconfig/src/nsAutoConfig.cpp (this doesn't mean it isn't actually used ever, but it can be a clue). - Marco. Il 31/10/2017 05:09, Nicholas Nethercote ha scritto: > 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 > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Firefox startup code coverage (ts_paint talos test)
Hello all,
at https://marco-c.github.io/ts_paint_startup_coverage_report/ you can
find a (C/C++-only for now) code coverage report of Firefox startup. The
report was generated using the ts_paint talos test, considering code
executed until the "MozAfterPaint" event and after a setTimeout(, 0). It
also contains the number of times a line was executed ("Line data" in
the source view).
The report could be useful to identify code that is currently being
executed at startup but shouldn't.
The build is a debug build with all optimizations disabled, to have more
precise line coverage.
- Marco.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Re: CodeCoverage Monthly Update
No, currently not, but we can build one ourselves using their API (which we might to do with codecov.io anyway, since we expect to have custom needs). - Marco. Il 04/05/17 08:22, Chris Peterson ha scritto: On 2017-05-03 8:44 PM, Kyle Lahnakoski wrote: * Daily coverage reports on coveralls.io [1] and on codecov.io[2]. Which do you like? Does coveralls.io have a top-down coverage view like codecov.io? That view seems more useful for both people that want a global view and developers that want to drill down into just their component directories. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
