And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
--HG--
extra : moz-landing-system : lando
We clamp earlier (parse time rather than computed value time), but that's the
only behavior change, which I think doesn't really matter.
Differential Revision: https://phabricator.services.mozilla.com/D35198
--HG--
extra : moz-landing-system : lando
This needs https://github.com/eqrion/cbindgen/pull/362, but I expect it to be
uncontroversial. I'll add a patch to this bug when it's merged to update it.
cbindgen historically didn't include these, but it turns out to be pretty useful
to generate constants for the style crate (since the binding crate is
`servo/ports/geckolib`).
An alternative is to get a completely different cbindgen-generated header for
these, but that seems a bit wasteful. This generates the constants with the
Style prefix (so we'll get `StyleMAX_GRID_LINE` for example), which is very
ugly. But we probably want to eventually stop using the Style prefix and use a
namespace instead, plus it's trivial to do `auto kMaxLine = StyleMAX_GRID_LINE`,
for example, so it's probably not a huge deal.
Another alternative would be to use associated consts, which _are_ generated by
cbindgen. Something like:
```
struct GridConstants([u8; 0]);
impl GridConstants {
const MAX_GRID_LINE: i32 = 10000;
}
```
Which would yield something like:
```
static const int32 StyleGridConstants_MAX_GRID_LINE = 10000;
```
I'm not sure if you find it preferrable, but I'm also happy to change it in a
follow-up to use this.
We need to fix a few manual C++ function signature definitions to match the C++
declaration.
Differential Revision: https://phabricator.services.mozilla.com/D35197
--HG--
extra : moz-landing-system : lando
Option<> is not FFI-safe, so if we want to use the same representation
everywhere we need to get rid of it. This also makes it take the same amount of
memory as the C++ representation, and it's not very complex, I'd think.
Differential Revision: https://phabricator.services.mozilla.com/D35195
--HG--
extra : moz-landing-system : lando
We clamp earlier (parse time rather than computed value time), but that's the
only behavior change, which I think doesn't really matter.
Differential Revision: https://phabricator.services.mozilla.com/D35198
--HG--
extra : moz-landing-system : lando
This needs https://github.com/eqrion/cbindgen/pull/362, but I expect it to be
uncontroversial. I'll add a patch to this bug when it's merged to update it.
cbindgen historically didn't include these, but it turns out to be pretty useful
to generate constants for the style crate (since the binding crate is
`servo/ports/geckolib`).
An alternative is to get a completely different cbindgen-generated header for
these, but that seems a bit wasteful. This generates the constants with the
Style prefix (so we'll get `StyleMAX_GRID_LINE` for example), which is very
ugly. But we probably want to eventually stop using the Style prefix and use a
namespace instead, plus it's trivial to do `auto kMaxLine = StyleMAX_GRID_LINE`,
for example, so it's probably not a huge deal.
Another alternative would be to use associated consts, which _are_ generated by
cbindgen. Something like:
```
struct GridConstants([u8; 0]);
impl GridConstants {
const MAX_GRID_LINE: i32 = 10000;
}
```
Which would yield something like:
```
static const int32 StyleGridConstants_MAX_GRID_LINE = 10000;
```
I'm not sure if you find it preferrable, but I'm also happy to change it in a
follow-up to use this.
We need to fix a few manual C++ function signature definitions to match the C++
declaration.
Differential Revision: https://phabricator.services.mozilla.com/D35197
--HG--
extra : moz-landing-system : lando
Option<> is not FFI-safe, so if we want to use the same representation
everywhere we need to get rid of it. This also makes it take the same amount of
memory as the C++ representation, and it's not very complex, I'd think.
Differential Revision: https://phabricator.services.mozilla.com/D35195
--HG--
extra : moz-landing-system : lando
This doesn't change the way C++ code uses static prefs. But it does slightly
change how Rust code uses static prefs, specifically the name generated by
bindgen is slightly different.
The commit also improves some comments.
Differential Revision: https://phabricator.services.mozilla.com/D35764
--HG--
extra : rebase_source : 13cf215aeb713e188103ef0cd04d094aa150853e
Jonathan Kew
alwu
shindli
atouchet
Emilio Cobos Álvarez
Kagami Sascha Rosylight
Calixte Denizet
Hugh Gallagher
Cosmin Sabou
Charlie Marlow
Andreea Pavel
Cameron McCormack
Mihai Alexandru Michis
Connor Brewster
Nicholas Nethercote
Dorel Luca