Re: Intent to Unship: stream decoder for BinHex format

2017-10-17 Thread Boris Zbarsky 

On 10/17/17 8:12 PM, Myk Melez wrote:
Shouldn't the code rather move to comm-central if it's specific to 
mailnews?


That would be fine too, yes.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Unship: stream decoder for BinHex format

2017-10-17 Thread Myk Melez 

Boris Zbarsky 
2017 October 17 at 07:45
Please double-check that this use case does not get broken, or 
condition the code to be mailnews-only or something.

Shouldn't the code rather move to comm-central if it's specific to mailnews?

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

2017-10-17 Thread Andrew Halberstadt 
On Tue, Oct 17, 2017 at 4:00 PM  wrote:

> Those things can be encoded as regexps, but they span across programming
> languages (XUL, XHTML, HTML, XBL, DTD, JS, C++).
>

To create a new regex-based linter, simply add a file like this:
https://dxr.mozilla.org/mozilla-central/source/tools/lint/test-disable.yml

It'll get picked up automatically and be enabled on any files that match
the include/exclude directives. Just run:
./mach lint 

And anything that matches the regex will spit out an error. The above
link is currently the only regex based linter in-tree, so it could
definitely use some improvements (e.g we could allow a list of regexes
in a single linter). It also only works if the offending string is all on
the
same line, which isn't ideal.

Is there any mozilla-clippy project being planned? :)
>

Yes, see bug 1361342. We were blocking on rust stable support in clippy.
Last I heard that still hadn't landed (though this was several months
ago). If anyone knows the status there please chime in on the bug.


> zb.
> ___
> 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: Intent to Enable: Automated Static Analysis feedback in MozReview

2017-10-17 Thread Gregory Szorc 
On Tue, Oct 17, 2017 at 9:58 PM,  wrote:

> This is awesome! As an engineer who has to work with C++ until we advance
> Rust bindings, I always feel terrible when my reviewers spend their
> precious time identifying simple C++ errors in my code.
>
>
> Seeing the advancements in static analysis for C++, rustfmt and eslint for
> JS, I'm wondering if there's a place to collect a less strict "best
> practices" analysis - more similar to rust's clippy than fmt.
>
> In Intl/L10n land, we have a bunch of recommendations that are very hard
> to enforce since they spread between JS, C++ and soon Rust regarding
> language selection, manipulation, testing of intl output etc.
> I'm wondering if there's a place to get those kind of "automated feedback"
> patterns.
> A few examples of what I have on my mind:
>
>  - We'd like people to not use "general.useragent.locale" to manipulate
> app locale anymore, but rather use Services.locale.getRequestedLocales/
> setRequestedLocales.
>  - We'd like to make sure people don't write unit tests that test
> particular output out of Intl APIs (that makes our tests locked to only
> work in one language and break every time we update our datasets - that's a
> big no-no in the intl world)
>  - We'd like to discourage people from altering app locales, and rather
> test against updated required locales.
>  - Soon we'll want to recommend using DOMLoclaization.jsm/Localization.jsm
> API over StringBundle/DTD.
>
> Those things can be encoded as regexps, but they span across programming
> languages (XUL, XHTML, HTML, XBL, DTD, JS, C++).
>
> Is there any mozilla-clippy project being planned? :)
>

We have mozlint (
https://firefox-source-docs.mozilla.org/tools/lint/index.html), which is a
mini framework of sorts for integrating various linters into a common
frontend (`mach lint`). Many of these lints run in CI. It is relatively
easy to add new linters (as the docs detail).

Feel free to supplement existing linters with custom checks or write your
own new linter if appropriate. ahal is the mozlint guru if you have
questions.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: (hyperlink auditing)

2017-10-17 Thread James Graham 

On 02/10/17 18:06, Anne van Kesteren wrote:

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=951104

Rationale: There's already a myriad of ways to obtain this data
through script. We might as well ship the protocol that both Chrome
and Safari ship in the hope that along with sendBeacon() it decreases
the usage of the slower alternatives; ultimately giving users a better
experience.

Previously: This was already discussed in
https://groups.google.com/d/msg/mozilla.dev.platform/DxvZVnc8rfo/RxSnyIFqxoQJ
and I think concluded given Jonas Sicking's statement in the
aforementioned bug, but since it's been a few years without action we
thought it would be worth it to send another ping.




Are there cross-browser (i.e. wpt) tests for this feature?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

2017-10-17 Thread zbraniecki 
This is awesome! As an engineer who has to work with C++ until we advance Rust 
bindings, I always feel terrible when my reviewers spend their precious time 
identifying simple C++ errors in my code.


Seeing the advancements in static analysis for C++, rustfmt and eslint for JS, 
I'm wondering if there's a place to collect a less strict "best practices" 
analysis - more similar to rust's clippy than fmt.

In Intl/L10n land, we have a bunch of recommendations that are very hard to 
enforce since they spread between JS, C++ and soon Rust regarding language 
selection, manipulation, testing of intl output etc.
I'm wondering if there's a place to get those kind of "automated feedback" 
patterns.
A few examples of what I have on my mind:

 - We'd like people to not use "general.useragent.locale" to manipulate app 
locale anymore, but rather use 
Services.locale.getRequestedLocales/setRequestedLocales.
 - We'd like to make sure people don't write unit tests that test particular 
output out of Intl APIs (that makes our tests locked to only work in one 
language and break every time we update our datasets - that's a big no-no in 
the intl world)
 - We'd like to discourage people from altering app locales, and rather test 
against updated required locales.
 - Soon we'll want to recommend using DOMLoclaization.jsm/Localization.jsm API 
over StringBundle/DTD.

Those things can be encoded as regexps, but they span across programming 
languages (XUL, XHTML, HTML, XBL, DTD, JS, C++).

Is there any mozilla-clippy project being planned? :)

zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Unship: stream decoder for BinHex format

2017-10-17 Thread Boris Zbarsky 

On 10/17/17 5:47 AM, Shih-Chiang Chien wrote:

I intent to remove all the code that handling BinHex decoding, i.e.
nsBinHex.cpp, from mozilla-central if no other project is using it.


The code was originally added for mailnews.  See 
https://bugzilla.mozilla.org/show_bug.cgi?id=81352


Please double-check that this use case does not get broken, or condition 
the code to be mailnews-only or something.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Unship: stream decoder for BinHex format

2017-10-17 Thread Shih-Chiang Chien 
Currently on non-Mac platform, firefox will decompression the content while
loading resource with MIME type "application/mac-binhex40". This introduces
the confusion like bug 1390708 when Firefox trying to decode BinHex file.
On Mac platform we already disabled stream decoding of BinHex file.

I tested with Google Chrome 61, Internet Explorer 11, and Safari 11. All
these browsers treat BinHex file as binary file and trigger file download
directly.

I intent to remove all the code that handling BinHex decoding, i.e.
nsBinHex.cpp, from mozilla-central if no other project is using it. This
will happen on Firefox 58 if no objection on mailing list and in bug
1390708.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

2017-10-17 Thread Jan Keromnes 
Thanks glandium!

Yes, reporting defects that are expanded from macros generates a lot of
noise, and it's not always an issue we can fix (e.g. when the macro comes
from third-party code). So we've decided to stop reporting these, and the
fix was merged in time for tomorrow's push to production.

TL;DR After tomorrow, clangbot will stop reporting defects expanded from
macros.

On Tue, Oct 17, 2017 at 10:40 AM, Mike Hommey  wrote:

> On Tue, Oct 17, 2017 at 10:38:09AM +0200, Jean-Yves Avenard wrote:
> > Hi
> >
> > Do you have ways to prevent running this code on some external
> > frameworks?
> >
> > Whenever we modify a gtest this causes hundreds of errors about not
> > using a default constructor … (which shouldn’t be an error anyway)
>
> https://github.com/mozilla-releng/services/issues/658
>
> Mike
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

2017-10-17 Thread Mike Hommey 
On Tue, Oct 17, 2017 at 10:38:09AM +0200, Jean-Yves Avenard wrote:
> Hi
> 
> Do you have ways to prevent running this code on some external
> frameworks?
> 
> Whenever we modify a gtest this causes hundreds of errors about not
> using a default constructor … (which shouldn’t be an error anyway)

https://github.com/mozilla-releng/services/issues/658

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

2017-10-17 Thread Jean-Yves Avenard 
Hi

Do you have ways to prevent running this code on some external frameworks?

Whenever we modify a gtest this causes hundreds of errors about not using a 
default constructor … (which shouldn’t be an error anyway)

> On 9 Oct 2017, at 4:33 pm, Jan Keromnes  wrote:
> 
> 
> C/C++ was our top priority because code defects are very costly, but we'd
> love to make our static analysis bot support additional languages, so we're
> looking into integrating with mozlint [0] (the  `./mach lint` wrapper
> around eslint, flake8 and wptlint), and I think we should also use clippy
> to lint Rust code.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform