Remove NS_*LITERAL_*STRING macros
Categories
(Core :: XPCOM, task)
Tracking
()
People
(Reporter: sg, Assigned: sg)
References
Details
Attachments
(7 files)
Bug 1648010 - Remove NS_NAMED_LITERAL_CSTRING and NS_NAMED_LITERAL_STRING macros. r=#xpcom-reviewers
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
The NS_*LITERAL_*STRING
macros are no longer really necessary, and can be replaced by regular constructor calls to the corresponding nsLiteralString/nsLiteralCString
classes.
In particular, the NS_NAMED_LITERAL_STRING
and NS_NAMED_LITERAL_CSTRING
macros obscure the declaration of constants.
Assignee | ||
Comment 1•4 years ago
|
||
Assignee | ||
Comment 2•4 years ago
|
||
Depends on D80631
Assignee | ||
Comment 3•4 years ago
|
||
Depends on D80860
Assignee | ||
Comment 4•4 years ago
|
||
Depends on D80861
Assignee | ||
Comment 5•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
Instead of calling the constructor directly, user-defined literals can be used for a significantly more concise syntax.
Assignee | ||
Comment 7•4 years ago
|
||
Depends on D80861
Assignee | ||
Updated•4 years ago
|
Pushed by sgiesecke@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d1416483de0d Add user-defined string literals. r=froydnj
Comment 9•4 years ago
|
||
Backed out changeset d1416483de0d for causing bustages in nsTLiteralString.h
Backout link: https://hg.mozilla.org/integration/autoland/rev/ebb333a4a297259adbdc72cb40ebd488aee28818
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=307865952&repo=autoland&lineNumber=5664
Comment 10•4 years ago
|
||
Pushed by sgiesecke@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9063f494163b Add user-defined string literals. r=froydnj
Comment 11•4 years ago
|
||
bugherder |
Comment 13•4 years ago
|
||
Pushed by sgiesecke@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3f8100fb7431 Replace uses of NS_LITERAL_STRING/NS_LITERAL_CSTRING macros by _ns literals. r=geckoview-reviewers,jgilbert,agi,hsivonen,froydnj https://hg.mozilla.org/integration/autoland/rev/3d7ffaefcd5a Fix uses of NS_LITERAL_STRING with C string literals. r=geckoview-reviewers,agi,froydnj https://hg.mozilla.org/integration/autoland/rev/e52e5ee6f9d6 Remove NS_NAMED_LITERAL_CSTRING and NS_NAMED_LITERAL_STRING macros. r=froydnj
Comment 14•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Comment 15•4 years ago
|
||
Pushed by sgiesecke@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5f8a5717324d Remove NS_LITERAL_STRING and NS_LITERAL_CSTRING macros. r=froydnj
Comment 16•4 years ago
|
||
bugherder |
Comment 17•4 years ago
|
||
Pushed by sgiesecke@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d402a579fb2d Update coding style with respect to string literals. r=froydnj
Assignee | ||
Updated•4 years ago
|
Comment 18•4 years ago
|
||
bugherder |
Assignee | ||
Comment 19•4 years ago
|
||
Actually, the main patches already landed in Firefox 80, just the documentation update took much longer. It should probably better have been moved to a separate bug. Sorry for that!
Comment 20•4 years ago
|
||
This burns us pretty often on ESR78 uplifts. While I'm not suggesting we should try to land a tree-wide rewrite there, could we consider uplifting at least enough to support the _ns strings so builds don't break?
Assignee | ||
Comment 21•4 years ago
|
||
Comment on attachment 9159347 [details]
Bug 1648010 - Add user-defined string literals. r=#xpcom-reviewers
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: Many patches that are considered for uplifting depend on the user-defined literals that are added by this patch.
- User impact if declined: Delay in uplifting patches to esr
- Fix Landed on Version:
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This only adds new functions which do not affect existing code.
- String or UUID changes made by this patch:
Assignee | ||
Comment 22•4 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #20)
This burns us pretty often on ESR78 uplifts.
:(
While I'm not suggesting we should try to land a tree-wide rewrite there, could we consider uplifting at least enough to support the _ns strings so builds don't break?
Sure, that makes sense, and I checked it grafts cleanly to esr78, so I made an uplift request. Sorry I didn't think of that myself!
Comment 23•4 years ago
|
||
Comment on attachment 9159347 [details]
Bug 1648010 - Add user-defined string literals. r=#xpcom-reviewers
Thanks, this will make our lives much easier over the next year or so :). Approved for 78.4esr.
Comment 24•4 years ago
|
||
bugherder uplift |
Comment 25•4 years ago
|
||
Comment on attachment 9159347 [details]
Bug 1648010 - Add user-defined string literals. r=#xpcom-reviewers
Removing the approval flag and ESR78 status since this isn't really "fixed" there.
Updated•4 years ago
|
Assignee | ||
Comment 26•4 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #25)
Comment on attachment 9159347 [details]
Bug 1648010 - Add user-defined string literals. r=#xpcom-reviewersRemoving the approval flag and ESR78 status since this isn't really "fixed" there.
Yes, and we probably specifically do NOT want to remove the NS_LITERAL_(C)STRING
macros (D80862) in esr78 as that would again be an obstacle to uplifting patches, which is what the title of this bug is telling.
Comment 27•4 years ago
|
||
Should we consider adding this to the vcs "ignored csets for annotate/blame" lists? These patches touched a lot of code without materially changing semantics in consumers, AIUI...
Assignee | ||
Comment 28•4 years ago
|
||
Yes, makes sense to me (without knowing the general policy on this). I just don't know where/how to add that. Can you provide a patch, or point me to directions how to do that?
Comment 29•4 years ago
|
||
(In reply to Simon Giesecke [:sg] [he/him] from comment #28)
Yes, makes sense to me (without knowing the general policy on this). I just don't know where/how to add that. Can you provide a patch, or point me to directions how to do that?
I do not know how either; hg log
on the git and hg ignored revs files in the root of the tree point at bug 1633969, which is blocking bug 1637889, which has a comment suggesting Sylvestre knows. Sylvestre?
Comment 30•4 years ago
|
||
.hg-annotate-ignore-revs and .git-blame-ignore-revs I suppose
Comment 31•4 years ago
|
||
Yeah and it should also ignore patches with
# ignore-this-changeset
in the commit message
Comment 32•4 years ago
|
||
Could you add the hashes of these commits to .hg-annotate-ignore-revs
and .git-blame-ignore-revs
?
Assignee | ||
Comment 33•4 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #32)
Could you add the hashes of these commits to
.hg-annotate-ignore-revs
and.git-blame-ignore-revs
?
Sure, I hope I got that right. Sorry I lost track of the earlier request to do this.
Assignee | ||
Comment 34•4 years ago
|
||
Comment 35•4 years ago
|
||
Pushed by sgiesecke@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/79dea42aa15d Add revisions for the replacement of literal string macros by string literals to the ignore sets. r=marco,glandium DONTBUILD
Comment 36•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Description
•