- add EncodingScheme.register overload that references the registered class
- just adding the FQN name of a class does not reference that class, so
it must not end up in the binary and subsequently EncodingScheme.create failed
- This used to work by chance b/c all the EncodingScheme implementations
were in a module w/ static ctor. Any user of std.encoding did drag in
that ModuleInfo, which in turn referenced all classes of std.encoding.
Since moving the static ctor to std.internal.phobosinit to break a
cycle, the classes were no longer referenced by a ModuleInfo w/ shared
ctor, so they wouldn't end up in the binary unless explicitly
referenced elsewhere.
- deprecate the old EncodingScheme.register(string fqn) b/c relying on
Object.factory is slow, error prone (linkage), and really unnecessary
- import encodinginit in std.encoding so that the
std_encoding_shared_static_this callback actually gets run
- partially Revert "Merge pull request #4493 from schveiguy/fixcycles2"
- recreate processinit (and import it from std.process)
to call std.process shared ctor w/o creating a cycle
- keep it separate from phobosinit to not drag std.encoding
into any binary using std.process
Carried bits in last word must be output at the end.
Add unittest for 3rd/4th word no-carry boundary.
Implement 'o' format specifier in BigInt.toString().
* fixating the current DummyRange behaviour in a unittest.
* structured the tests a little
* DummyRange with custom types
style
style again
even more style
spaces
Resolves#15335: getSymbolsByUDA fails if type has private members.
Generous (ab)use of mixins allows getSymbolsByUDA to reference symbols
without trying to access them, allowing it to inspect private members
without failing.
Testing this required private symbols defined outside of std.traits.
This adds std.internal.test.uda, which defines a struct containing
private members that is used in a unittest added to std.traits.
Using LDC master on Win64, I get a relative diff of 1.068e-15 for the
second tuple (input = 1/8), exceeding the allowed upper bound by not even
7%. I chose to be generous and doubled the limit. ;)
More details for the 2nd tuple:
actual: 0x1.0a333fd8b6880p+2
expected: 0x1.0a333fd8b687bp+2
rel diff: 1.067682e-15
The other 4 tuples are perfect matches.
