Re: Tool for converting C++ standard library naming style to Gecko naming style?

On 16 February 2017 at 13:41, Henri Sivonen wrote: > Is there some kind of tool, similar to ./mach clang-format for > whitespace, that changes identifies from C++ standard library style to > Gecko style? Yes, clang-tidy has the readability-identifier-naming check: http://clang.llvm.org/extra/clan

Re: Coding style for C++ enums

On 8 April 2016 at 18:10, Kartikaya Gupta wrote: > Others? enum class OptionD { SentenceCaseValues, ThisWontBeConfusedWithOtherThings // ... because you need to use OptionD::ThisWontBeConfusedWithOtherThings }; ___ dev-platform mailing list dev-pl

Re: Intent to Implement and Ship: Permissions API

On 24 August 2015 at 09:47, Ehsan Akhgari wrote: > Just to double check, do we support "geolocation", "notifications" and > "push"? Yep! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement and Ship: Permissions API

On 22 August 2015 at 06:24, Jonas Sicking wrote: > Does it also work in workers? Not yet, that was left for bug 1193373. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: Permissions API

Hi, navigator.permissions.query has been Nightly-only for a few weeks. We are going to let it ride the trains. Other parts of the spec (such as Permissions.request) will be implemented when the spec is complete. Summary: The Permissions API allows a web application to be aware of the status of a

Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

On 14 July 2015 at 08:23, Benjamin Smedberg wrote: > The argument I am most sympathetic to is that this convention is a barrier > to new contributors. Making new contributors productive, both employees and > volunteers, is a very good reason to choose one style over another. The C++ world is a hu

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On 7 July 2015 at 15:02, Mike Hommey wrote: > On Tue, Jul 07, 2015 at 11:52:12PM +0300, smaug wrote: >> until the tools (and poiru) are run and make the code follow Mozilla coding >> style. > > Assuming you're talking about clang-format, that doesn't take care > about anything else than whitespac

Re: Revisiting modelines in source files

On 18 June 2015 at 07:28, wrote: > 1) Comments that exceed the 80-char limit get wrapped blindly, rather than > being rewrapped properly. This results in comment blocks that look like this: I sidestepped this issue by making Clang-Format ignore all comments. See bug 961541. Cheers, Biru __

Re: Revisiting modelines in source files

Hi, Over the past year, I have converted a few directories (xpcom/, docshell/, embedding/) to Gecko style using a patched Clang-Format and a few other tools. On 17 June 2015 at 18:57, Gregory Szorc wrote: > First thing is first: what are the blockers to mass rewriting > mozilla-central with clan

Re: Announcing MozillaBuild 2.0.0 Release

On 14 June 2015 at 18:00, Xidorn Quan wrote: > But it seems we still cannot build on MSVC2015, but I don't want to > reinstall MSVC 2013 to switch from the Express Edition to the Community > Edition. It seems I have to stick to MozillaBuild 1.11 for a while :/ VS Express 2013 for Windows Desktop

PSA: Allocating FallibleTArray methods will soon require `mozilla::fallible` argument

Greetings, Over in bug 968520, FallibleTArray is being merged into nsTArray. After the bug is complete, we will be left with just nsTArray (and nsAutoTArray). Fallible allocation will be opt-in using the `mozilla::fallible` parameter just like with ns*String. As a first step in this transition, i

Re: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|

On 27 March 2015 at 01:19, Bobby Holley wrote: > Can we switch from 4-space to 2-space indentation at some point too? > Together, those would remove the most glaring formatting differences. The > others (bracing single-line consequents, aNamingWarts, etc) might be harder. I've done all of that an

PSA: IDL file changes may now be rejected by server-side hook

Greetings, If your commit modifies an IDL interface (think `[...] interface Foo {};`), you will now have to either 1) Bump the corresponding interface UUID. Use e.g. `./mach update-uuids nsISomething` to bump the UUID of nsISomething and all its descendant interfaces. or 2) Include 'IGN

Re: PSA: content/{base,html,media,svg,xul} will move to dom/

This has landed on inbound and will probably be merged to central on Monday. To update existing patch files to use the new paths, see: https://gist.github.com/poiru/b266b75473a8d9f71d33 Biru ___ dev-platform mailing list dev-platform@lists.mozilla.org h

Re: Switching to Visual Studio 2013

I went ahead and fixed the instructions. Most of it should now be up-to-date. On 20 October 2014 18:44, Gijs Kruitbosch wrote: > Hi, > > Can you or someone else in the know update > https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prerequisites > and friends, or

PSA: content/{base,html,media,svg,xul} will move to dom/

I'm planning to move and flatten content/{base,html,media,svg,xul}/ into dom/ in a few days barring any unforeseen test reordering issues. For example: content/base/public/nsINode.h=> dom/base/nsINode.h content/html/content/src/HTMLElement.cpp => dom/html/HTMLElement.cpp content/

Gecko style: Braces with enums and uninons

While working on bug 995730, I bumped into a few things that the Gecko style guide leaves unspecified. I have described one such case below. I'll create separate threads for the other things in order to maximize the number of bikeshedding threads (and for readability). For classes and structs, bra

Gecko style: Line-continuation backslash in macros

(Note: Use a monospace font to view this message or use .) The placement of the line-continuation backslash in macros is wildly inconsistent. Some put the backslash directly after the line: #define NS_IMPL_CYCLE_COLLECTION_CAN_SKIP_IN_CC_BEG

Gecko style: Formatting function return type and specifiers

For top-level function definitions, the recommended style is: template static inline T Foo() { // ... } However, for function declarations and inline member functions, there does not seem to be a definitive style. Some use: int Foo(); class Bar { virt

Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic

On 28 April 2014 14:18, Benoit Jacob wrote: > Question: is there a plan to switch to an implementation based on variadic > templates when we will stop supporting compilers that don't support them? Do > you know when that would be (of the compilers that we currently support, > which ones don't supp

Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic

On 28 April 2014 07:29, Boris Zbarsky wrote: > On 4/28/14, 12:18 AM, Birunthan Mohanathas wrote: >> >> Right now, the new macros support up to 50 variadic arguments. > > > If someone uses more than that, will that fail to compile or silently ignore > the extra arg

PSA: NS_IMPL_ISUPPORTS and friends are now variadic

Bugs 900903 and 900908 introduced variadic variants of NS_IMPL_ISUPPORTS, NS_IMPL_QUERY_INTERFACE, NS_IMPL_CYCLE_COLLECTION, etc. and removed the old numbered macros. So, instead of e.g. NS_IMPL_ISUPPORTS2(nsFoo, nsIBar, nsIBaz), simply use NS_IMPL_ISUPPORTS(nsFoo, nsIBar, nsIBaz) instead. Right no