On 30/01/14 14:44, Anthony Jones wrote:
> On 30/01/14 10:46, Kyle Huey wrote:
>> Whatever tool we end up using needs to work on Windows.
>
> clang-format works fine on Windows.
>
> If we want to go down the preprocessed route, you can generate
> preprocessed output from the msvc compiler using:
>
On 30/01/14 10:46, Kyle Huey wrote:
> Whatever tool we end up using needs to work on Windows.
clang-format works fine on Windows.
If we want to go down the preprocessed route, you can generate
preprocessed output from the msvc compiler using:
C:\> cl /E MyFile.cpp
Pretty much does the same thin
On 29/01/2014 13:46, Kyle Huey wrote:
> On Wed, Jan 29, 2014 at 9:32 AM, Gregory Szorc wrote:
>> On 1/28/14, 7:15 PM, Anthony Jones wrote:
>>> On 28/01/14 13:08, Nicholas Nethercote wrote:
> In the meantime, we should wrap up the pending discussions about other
> changes to the style guide
On 2014-01-29 4:21 PM, Anthony Jones wrote:
I don't think we should attempt style rewriting.
One thing I wanted to explain is why I have focussed on
clang-format-diff more than clang-format. My approach is to stop
introducing ugliness so that we ratchet towards consistency. I suggest
we do the
On Wed, Jan 29, 2014 at 9:32 AM, Gregory Szorc wrote:
> On 1/28/14, 7:15 PM, Anthony Jones wrote:
>>
>> On 28/01/14 13:08, Nicholas Nethercote wrote:
In the meantime, we should wrap up the pending discussions about other
changes to the style guide, such as 80/100/infinite columns,
>
On Wed, Jan 29, 2014 at 1:21 PM, Anthony Jones wrote:
> I don't think we should attempt style rewriting.
>
> One thing I wanted to explain is why I have focussed on
> clang-format-diff more than clang-format. My approach is to stop
> introducing ugliness so that we ratchet towards consistency. I
On 30/01/14 06:32, Gregory Szorc wrote:
> Building a style verifier for C++ is hard. You inevitably have to build
> it on top of an existing parser (like Clang) or cobble something hacky
> together [1], at which point you are chasing the language evolution and
> all kinds of one-offs.
I wrote one
Anthony Jones writes:
> There is also some vagueness and inconsistency around:
>
> bool
> MyClass::MyFunction()
>
> vs
>
> bool MyClass::MyFunction()
>
> Most of the code seems to do this only for top-level functions i.e. when
> not already indented. I'd like some clarification on the rule here. I
On Wednesday, January 29, 2014 10:35:24 AM UTC-8, Nikhil Marathe wrote:
> As off January 28, our DOM Promises implementation implements the es6
>
> promises spec. [1]
>
> It is feature complete, and passes the Promises/A+ tests. [2]
>
> I intend to enable it by default this week so that it ships
As off January 28, our DOM Promises implementation implements the es6
promises spec. [1]
It is feature complete, and passes the Promises/A+ tests. [2]
I intend to enable it by default this week so that it ships in Firefox 30.
Caveats:
We don't support subclassing, which is a ES6 feature, but neith
On 1/28/14, 7:15 PM, Anthony Jones wrote:
On 28/01/14 13:08, Nicholas Nethercote wrote:
In the meantime, we should wrap up the pending discussions about other
changes to the style guide, such as 80/100/infinite columns,
member/parameter/local naming convention, and other threads that Gavin was
g
On 1/27/2014 7:08 PM, Nicholas Nethercote wrote:
It's been a couple of weeks now. Can we move forward?
Anthony Jones has done some work on using clang-format to restyle
lines that have changed in a file, but I don't think anyone has done
any evaluation of clang-format for whole-file changes.
I
Bobby Holley wrote:
On Tue, Jan 28, 2014 at 7:15 PM, Anthony Jones wrote:
There is also some vagueness and inconsistency around:
bool
MyClass::MyFunction()
vs
bool MyClass::MyFunction()
I'm pretty sure the former is correct per Gecko style. Benjamin can confirm.
My understanding is th
13 matches
Mail list logo
