Several deprecated items were listed for removal in August, but it's
looking likely that 2.060 will come out in August, and I'd prefer not to
have them removed for 2.060 given how many items are already in the
changelog, and they're already deprecated, so it'll only affect people
compiling with -d either way. So, I'm changing the ddoc comments to say
September instead of August. They'll be removed in 2.061.
I may or may not re-add it later, but it's probably going to be broken
for a while, depending on how long it takes the various auto tester
boxes to be updated, since a new leap second was applied on 2012-06-30
right before midnight of 2012-07-01. The total is now 25, but some
machines will think that it's 24 for a while.
Both FILETIME and SysTime store time as the number of elapsed hnsecs
since a certain (different) epoch. Therefore, the optimal way to convert
between the two would be simply adding/subtracting the epoch difference.
This is not what std.datetime used to do - instead, FILETIME values
were converted to SYSTEMTIME (a structure with year/month/day/etc.
fields), and then created the SysTime result from that (and vice-versa),
which was very inefficient.
The "add epoch difference" method was already used in SysTime.currStdTime.
It has been refactored out and used in FILETIME conversion functions.
It looks like testing America/Santiago just isn't going to work, since
it's failing on FreeBSD. Bleh. Getting a timezone to test in South
America which actually has DST and works on all OSes is a pain (and
seemingly impossible at the moment). All of the other Chile tests were
disabled anyway.
Chile is screwing with its DST again, and I made the mistake
of leaving one of the tests using a 2012 date instead of a 2011
date (since 2011 has already happened whereas 2012 is still subject
to change).
Having the January deprecations and February deprecations in the same
month seems a bit much to me, since we managed to have both of those
months have quite a few, whereas the next few months have very few if
any. And we're close to release too, so I'd prefer to avoid causing
issues by deprecating them now.
I'll change it back to use double-checked locking once that works with
shared, but the atomicLoading stuff seemed overly complicated and
error-prone for what is supposed to be a temporary workaround for the
issues with shared.
Apparently. the compiler doesn't insert the correct memory fences for
shared yet, so double-checked locking does work right with shared yet.
This change should be undone (and the singletons changed back to using
shared) once shared has been fixed in the compiler.
This enables the test suite to build with the -property switch enabled.
std.cpuid: vendor()/processor() have not been converted to properties in accordance to core.cpuid.
std.xml: Element.text() cannot be a property due to the optional parameter.
Large switch statements have been replaced by data-driven array lookups to reduce the amount of code generated and also improve performance. Using DMD 2.056 on OSX x86 this cuts 12KB off of a Hello World program.
The motivation for this change is to try and reduce the size of small D programs as their large size is a common (and valid) complaint amongst newcomers.
The pragmas have not been as effective as we might have liked, since
they only work with templates and can't tell you where in your code you
need to make changes, and they seemed to have been more annoying to
programmers than helpful, so we're going to discontinue them. We'll
leave them in for stuff that's actually been deprecated until deprecated
has been improved enough to take a message, but we'll leave "scheduled
for deprecation" messages to the documentation and changelog.
