dom/quota/test/gtest/TestFlatten.cpp:18:3: error: loop will run at most once (loop increment never executed) [-Werror,-Wunreachable-code-loop-increment]
for (const auto& item : Flatten<int>(nsTArray<int>{})) {
^~~
dom/quota/test/gtest/TestFlatten.cpp:26:3: error: loop will run at most once (loop increment never executed) [-Werror,-Wunreachable-code-loop-increment]
for (const auto& item : Flatten<int>(nsTArray<CopyableTArray<int>>{})) {
^~~
dom/quota/test/gtest/TestFlatten.cpp:34:3: error: loop will run at most once (loop increment never executed) [-Werror,-Wunreachable-code-loop-increment]
for (const auto& item :
^~~
clang figures out that the loop is not going to execute, which is the
whole point of the test.
Differential Revision: https://phabricator.services.mozilla.com/D126874
This patch introduces a new notion of unaccessed origins. An origin is
considered as unaccessed if its age is older than a threshold (controlled by a
new preference, currently set to 13 months). Unaccessed origins are collected
during quota info loading.
When quota info loading is finished we check if it took a long time (controlled
by a new preference, currently set to 21s) and eventually archive unaccessed
origins which should speed up temporary storage initialization in a new
session.
Archiving consits of creating a new directory (archive) under storage/archives/0
directory (the name is based on the current date) and moving unaccessed origin
directories to the archive.
Once the patch lands, we will be monitoring QM_QUOTA_INFO_LOAD_TIME_V0
telemetry (quota info load time) and eventually lower down the preference for
long quota info load time.
If there are no issues, the archiving will be replaced with a hard removal of
unaccessed origins and also of the archives which were created in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D123049
This patch introduces a new notion of unaccessed origins. An origin is
considered as unaccessed if its age is older than a threshold (controlled by a
new preference, currently set to 13 months). Unaccessed origins are collected
during quota info loading.
When quota info loading is finished we check if it took a long time (controlled
by a new preference, currently set to 21s) and eventually archive unaccessed
origins which should speed up temporary storage initialization in a new
session.
Archiving consits of creating a new directory (archive) under storage/archives/0
directory (the name is based on the current date) and moving unaccessed origin
directories to the archive.
Once the patch lands, we will be monitoring QM_QUOTA_INFO_LOAD_TIME_V0
telemetry (quota info load time) and eventually lower down the preference for
long quota info load time.
If there are no issues, the archiving will be replaced with a hard removal of
unaccessed origins and also of the archives which were created in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D123049
This patch introduces a new type alias OkOrErr for Result<Ok, QMResult> and also converts some existing occurencies of Result<Ok, QMResult> to OkOrErr.
Differential Revision: https://phabricator.services.mozilla.com/D122206
This patch introduce an additional check inside the Helper::GetInactiveOriginInfos static method
used internally by CollectOriginsForEviction to ensure that QuotaManager will not select an
extension origin as an inactive origin to evict non persisted data from.
The rationale is that unlike websites (which may more likely using the locally stored data
as a local cache, but still able to retrieve the same data again from the server side),
extensions do not have a remote counterpart and so evicting their data would result
into potential data loss for the users.
Besides that, the browser extensions (unlike websites) are explicitly installed and uninstalled by
the user and all the data associated to the extension will be completely removed when the
extension is uninstalled.
Differential Revision: https://phabricator.services.mozilla.com/D120470
This patch adjusts other similar names as well:
MakeRelativeSourceFileName -> MakeSourceFileRelativePath
relativeSourceFile -> sourceFileRelativePath
thisFileRelativeSourceFileName -> thisSourceFileRelativePath
Differential Revision: https://phabricator.services.mozilla.com/D113076
This patch adjusts other similar names as well:
MakeRelativeSourceFileName -> MakeSourceFileRelativePath
relativeSourceFile -> sourceFileRelativePath
thisFileRelativeSourceFileName -> thisSourceFileRelativePath
Differential Revision: https://phabricator.services.mozilla.com/D113076
This patch:
- adds QM_WARNONLY_TRY/QM_NOTEONLY_TRY macros
- adds QM_WARNONLY_TRY_UNWRAP/QM_NOTEONLY_TRY_UNWRAP macros
- adds QM_OR_ELSE_WARN/QM_OR_ELSE_NOTE sub macros
- replaces non-propagating uses of NS_WARNING with redundant messages by
QM_WARNONLY_TRY
- replaces uses of QM_TRY with orElse by QM_TRY(QM_OR_ELSE_WARN(...))
- replaces uses of QM_TRY inside an extra lambda with QM_WARNONLY_TRY
- replaces uses of QM_TRY with QM_VOID with QM_WARNONLY_TRY.
- replaces uses of QM_TRY with unwanted warnings with QM_NOTEONLY_TRY
- replaces uses of QM_TRY with additional Maybe wrapping for doing a
fallback with QM_TRY(QM_OR_ELSE_WARN(...))
Differential Revision: https://phabricator.services.mozilla.com/D108424
This patch:
- adds QM_WARNONLY_TRY/QM_NOTEONLY_TRY macros
- adds QM_WARNONLY_TRY_UNWRAP/QM_NOTEONLY_TRY_UNWRAP macros
- adds QM_OR_ELSE_WARN/QM_OR_ELSE_NOTE sub macros
- replaces non-propagating uses of NS_WARNING with redundant messages by
QM_WARNONLY_TRY
- replaces uses of QM_TRY with orElse by QM_TRY(QM_OR_ELSE_WARN(...))
- replaces uses of QM_TRY inside an extra lambda with QM_WARNONLY_TRY
- replaces uses of QM_TRY with QM_VOID with QM_WARNONLY_TRY.
- replaces uses of QM_TRY with unwanted warnings with QM_NOTEONLY_TRY
- replaces uses of QM_TRY with additional Maybe wrapping for doing a
fallback with QM_TRY(QM_OR_ELSE_WARN(...))
Differential Revision: https://phabricator.services.mozilla.com/D108424
The module argument in LogError is redundant: the module information can
already be determined from the source file path. Indeed, reporting the module
separately in the telemetry events seems unnecessary. Instead, the relative
path is now reported. This is what the analysis of the telemetry data did
reconstruct anyway.
As a consequence, it's no longer necessary to define module-specific
HandleError functions, and therefore it's also unnecessary to define
module-specific TRY macros. These are retained as simple aliases for now,
but can be removed in a later patch entirely.
This also avoids misuses of a TRY macros in the wrong module, which were
happening a few times before, resulting in confusing output or telemetry
events.
Since Bug 1686191 will add some more TRY macro variants that warn, so
simplifying the module-specific aspects will simplify that task. Furthermore,
this is in preparation of moving the TRY macro extensions to MFBT.
Differential Revision: https://phabricator.services.mozilla.com/D102767
Jan Varga
Mike Hommey
criss
Csoregi Natalia
Luca Greco
imoraru
Tom Tung
Tom Tung
Butkovits Atila
Simon Giesecke