Simply converting the argument to a string could lead to odd situations where
resolving `null` succeeds if a hostname called "null" exists on the network.
Differential Revision: https://phabricator.services.mozilla.com/D126468
This changeset is the result of adding modernize-use-default-member-init to
tools/clang-tidy/config.yaml then proceeding to run
`./mach static-analysis check netwerk/ --fix`
I then went through the resulting fix and manually updated all of the member
variables which were missed due to them having a non-trivial constructor.
Note that the tool was only run on Linux, so code that only runs on some
platforms may have been missed.
The member variables that are still initialized in the contructor definition
are:
- bitfields (not all currently supported compilers allow default-member-init
- variables that are initialized via a parameter
- variables that use code not visible in the header file
There are a few advantages to landing this change:
- fewer lines of code - now declaration is in the same place as initialization
this also makes it easier to see when looking at the header.
- it makes it harder to miss initializing a member when adding a new contructor
- variables that depend on an include guard look much nicer now
Additionally I removed some unnecessary reinitialization of NetAddr members
(it has a constructor that does that now), and changed nsWifiScannerDBus to
use the thread-safe strtok_r instead of strtok.
Differential Revision: https://phabricator.services.mozilla.com/D116980
This changeset is the result of adding modernize-use-default-member-init to
tools/clang-tidy/config.yaml then proceeding to run
`./mach static-analysis check netwerk/ --fix`
I then went through the resulting fix and manually updated all of the member
variables which were missed due to them having a non-trivial constructor.
Note that the tool was only run on Linux, so code that only runs on some
platforms may have been missed.
The member variables that are still initialized in the contructor definition
are:
- bitfields (not all currently supported compilers allow default-member-init
- variables that are initialized via a parameter
- variables that use code not visible in the header file
There are a few advantages to landing this change:
- fewer lines of code - now declaration is in the same place as initialization
this also makes it easier to see when looking at the header.
- it makes it harder to miss initializing a member when adding a new contructor
- variables that depend on an include guard look much nicer now
Additionally I removed some unnecessary reinitialization of NetAddr members
(it has a constructor that does that now), and changed nsWifiScannerDBus to
use the thread-safe strtok_r instead of strtok.
Differential Revision: https://phabricator.services.mozilla.com/D116980
This modification relies on the shared memory implemented in Bug 1698045 and on
the ability to encode and decode self-hosted content from Bug 1668361 to
optimize the JS engine initialization by making the parent process encode the
self-hosted stencil, such that all other runtime initialization would only have
to decode it, including content processes.
Differential Revision: https://phabricator.services.mozilla.com/D110578
This interface extends nsIDNSRecord and makes the DNS code more extensible
by allowing us to support more record types.
This change does require the consumer to be aware of the type they requested
and to QueryInterface to either nsIDNSAddrRecord for regular IP lookups,
or to nsIDNSByTypeRecord for other kinds of lookups.
Differential Revision: https://phabricator.services.mozilla.com/D86177
This patch adds the nsIDNSResolverInfo interface which is used to hold
information about the resolver to be used in a DNS resolution.
We use this to merge all of the *WithTRRServer resolve functions into one.
Passing a resolver info will use that object when appropriate. No resolver
info means that we default to using the system resolver, or the default TRR
resolver.
This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds
the resolveType as a parameter to asyncResolve thus removing the need
to have asyncResolveByType methods.
Differential Revision: https://phabricator.services.mozilla.com/D86176
This interface extends nsIDNSRecord and makes the DNS code more extensible
by allowing us to support more record types.
This change does require the consumer to be aware of the type they requested
and to QueryInterface to either nsIDNSAddrRecord for regular IP lookups,
or to nsIDNSByTypeRecord for other kinds of lookups.
Differential Revision: https://phabricator.services.mozilla.com/D86177
This patch adds the nsIDNSResolverInfo interface which is used to hold
information about the resolver to be used in a DNS resolution.
We use this to merge all of the *WithTRRServer resolve functions into one.
Passing a resolver info will use that object when appropriate. No resolver
info means that we default to using the system resolver, or the default TRR
resolver.
This patch also converts the RESOLVE_TYPE_* flags into a cenum and adds
the resolveType as a parameter to asyncResolve thus removing the need
to have asyncResolveByType methods.
Differential Revision: https://phabricator.services.mozilla.com/D86176
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
I also considered setting a flag if a PAC query originates from a
TRR service channel but that doesn't work because of this:
1. We try to load test.com -> PAC script
2. We try to load TRR channel -> PAC script with DISABLE_TRR flag
3. PAC thread is still blocked on resolving test.com - we exit early
regardless of flag
Differential Revision: https://phabricator.services.mozilla.com/D78526
CLOSED TREE
Backed out changeset 03c4c517ee37 (bug 1640091)
Backed out changeset a1d86c177d79 (bug 1640091)
Backed out changeset f481d4ec255a (bug 1640091)
I also considered setting a flag if a PAC query originates from a
TRR service channel but that doesn't work because of this:
1. We try to load test.com -> PAC script
2. We try to load TRR channel -> PAC script with DISABLE_TRR flag
3. PAC thread is still blocked on resolving test.com - we exit early
regardless of flag
Differential Revision: https://phabricator.services.mozilla.com/D78526
Randell Jesup
Noemi Erli
Butkovits Atila
Kershaw Chang
Valentin Gosu
Cristian Tuns
Jens Stutte
Marian-Vasile Laza
Narcis Beleuzu
Tooru Fujisawa
Csoregi Natalia
Nicolas B. Pierron
Brindusan Cristian
Sandor Molnar
Rahul Yedida
Simon Giesecke
Razvan Maries
Bogdan Tara
Jean-Yves Avenard
Mihai Alexandru Michis
Philip Chimento