Граф коммитов

14 Коммитов

Автор SHA1 Сообщение Дата
Ehsan Akhgari e5e885ae31 Bug 1521000 - Part 2: Adjust our clang-format rules to include spaces after the hash for nested preprocessor directives r=sylvestre
# ignore-this-changeset

--HG--
extra : amend_source : 7221c8d15a765df71171099468e7c7faa648f37c
extra : histedit_source : a0cce6015636202bff09e35a13f72e03257a7695
2019-01-18 10:16:18 +01:00
Sylvestre Ledru 265e672179 Bug 1511181 - Reformat everything to the Google coding style r=ehsan a=clang-format
# ignore-this-changeset

--HG--
extra : amend_source : 4d301d3b0b8711c4692392aa76088ba7fd7d1022
2018-11-30 11:46:48 +01:00
Ehsan Akhgari ca162bee20 Bug 1508472 - Part 4: Fourth batch of comment fix-ups in preparation for the tree reformat r=sylvestre
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal.  I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.

Differential Revision: https://phabricator.services.mozilla.com/D13193

--HG--
extra : moz-landing-system : lando
2018-11-28 09:16:55 +00:00
Henri Sivonen c3fcb6ab2c Bug 1466475 - Make mozilla::Span produce aligned bogus pointers per new Rust rules. r=froydnj
MozReview-Commit-ID: JFVSRu53Geh

--HG--
extra : rebase_source : a9436aef554b6e892195324744f135d2b65086d5
2018-06-04 12:59:46 +03:00
Emilio Cobos Álvarez 1e9c395548 Bug 1466168: Remove mozilla::Forward in favor of std::forward. r=froydnj
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:

  s/mozilla::Forward/std::forward/
  s/Forward</std::forward</

The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)

MozReview-Commit-ID: A88qFG5AccP
2018-06-02 09:33:26 +02:00
Masatoshi Kimura caada858fb Bug 1451722 - Constexpr-ify mozilla::Span more. r=hsivonen
MozReview-Commit-ID: B7sxH5BAdp6

--HG--
extra : rebase_source : 3e7bf5424478cdff6dfd1c25b9808a41cfb6e0d3
2018-04-05 21:55:00 +09:00
Henri Sivonen 5f81ea7f50 Bug 1448591 - Make MakeStringSpan(nullptr) return an empty span. r=froydnj.
MozReview-Commit-ID: EyuLeWjEL7w

--HG--
extra : rebase_source : a40b671692db0e7faa7772654cb4b1ae75bd30a2
2018-03-24 21:36:00 +02:00
Masatoshi Kimura 456098425e Bug 1424103 - constexpr-ify mozilla::Span. r=hsivonen
MozReview-Commit-ID: 4e98Aer9V1k

--HG--
extra : rebase_source : 44f87677a4918aea4abaf2721895e48045267c7b
2017-12-08 23:20:56 +09:00
Chris Peterson 7bbe4a40e6 Bug 1405582 - Span: avoid repeated calls to size(). r=hsivonen
MozReview-Commit-ID: BKFrbvEt57l

--HG--
extra : rebase_source : 9aeb6fd018da5b8623f14ab927bd786c29ae56ae
extra : source : c5bedfde8b9dc2929fc14cfc2dc816e5f08b4ad8
2017-09-19 13:18:38 -07:00
Chris Peterson a48326552c Bug 1405582 - Span: delete implicit constructors for char* and char16_t*. r=froydnj,hsivonen
Delete Span's implicit constructors for char* and char16_t* pointers to avoid accidental construction in cases where a pointer does not point to a zero-terminated string. Use the MakeStringSpan() function instead.

I deleted both the const and non-const char* and char16_t* constructors, in the name of cross-compiler consistency. If we only delete the const char* and char16_t* constructors, for some reason, MSVC complains that `Span<char> s(charArray)` uses a deleted constructor while clang nor gcc permit it. I don't know if this is a compiler bug in MSVC or clang and gcc.

Also, do not permit MakeSpan() for string literals (const char and char16_t arrays) because the Span length would include the zero terminator, which may surprise callers. Use MakeStringSpan() to create a Span whose length that excludes the string literal's zero terminator or use the MakeSpan() overload that accepts a pointer and length and specify the string literal's full length.

The following Span usages are prevented:

  Span<const char> span("literal"); // error
  Span<char> span(charArray); // error

  Span<const char> span;
  span = "literal"; // error
  span = charArray; // error

  MakeSpan("literal"); // error

The following Span usages are still permitted:

  assert(MakeStringSpan("literal") == 8); // OK: span length is calculated with strlen() and excludes the zero terminator
  MakeStringSpan(charArray); // OK: span length is calculated with strlen() and excludes the zero terminator
  MakeSpan(charArray); // OK: span length is the char array size including any zero terminator

MozReview-Commit-ID: Et71CpjsiyI

--HG--
extra : rebase_source : f6f8bdb28726f0f2368fdfdd039fb1d7dcf2914e
extra : source : 0547d8924ffc7713d6cf32cc06eeeaf00e0d69a3
2017-09-20 00:38:07 -07:00
Henri Sivonen 854d241f4f Bug 1359874 - Make Span::Elements() always return a non-null pointer. r=froydnj.
MozReview-Commit-ID: AGvNlHmonpi
2017-06-13 13:22:34 +03:00
David Major c4a6792abb Bug 1358169: Fix Span.h constexprs for VS2017. r=froydnj
I can't speak for whether the MOZ_SPAN_GCC_CONSTEXPR on operator> is necessary, but I'm going on the assumption that any callers of it must also be in the same bucket of constexpr-ness.
2017-04-20 14:58:38 -04:00
Henri Sivonen 4064812605 Bug 1353324 - Add const char16_t variant of MakeCStringSpan() and rename both to MakeStringSpan(). r=froydnj.
MozReview-Commit-ID: E6LEZpe5H4w

--HG--
extra : rebase_source : dd6fe66be289e94751ecdf34113d79a091c9c8f8
2017-04-04 14:04:14 +03:00
Henri Sivonen c514501f1a Bug 1295611 - Add mozilla::Span. r=froydnj,gerv.
MozReview-Commit-ID: HGNDClVctbE
2017-03-31 13:32:18 +03:00