Fix observatory tests broken by running dartfmt due to line and column changes.
Temporarily reverted formatting for evaluate_activation_test.dart as dartfmt doesn't yet handle multitests.
BUG=
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2759973004 .
I've omitted files where the formatter output is significantly uglier
than the original code and I'll send those files in a separate CL
with options for how to make the code look reasonable while still
taking advantage of the formatter.
BUG=
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2751423005 .
Allow members of patch classes to be annotated with @patch. The VM
ignores the annotation. I simply replaces the original method
if the name matches, or reports an error if field names match.
Adding a bit is_patched to members to do more checking remains a
TODO. There are currently no unused bits available, and I don’t want
to increase the size of Function objects for this.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org/2230383003 .
Annotate patch classes and top-level patch functions with @patch
instead of the pseudo-keyword patch. This allows the analyzer
to read patch files, and matches the syntax that dart2js uses.
The deprecated syntax is still supported, but a warning is printed when detected.
BUG=
Review URL: https://codereview.chromium.org/2220883004 .
Symptom of the problem:
Set your Linux workstation (or Mac or MIPS board) to the Europe/London timezone
and the corelib/date_time test will fail, claiming that 1/1/1970 was a Wednesday
(it was actually a Thursday, trust me, I was already born).
Problem:
The implementation of DateTime in the VM relies on Unix time_t, the number of
seconds since the Epoch (1/1/1970 UTC). When asked for the weekday of a given
time, our implementation limits itself to a 32-bit positive range of time_t.
If the time falls outside of this range, the implementation picks an equivalent
time in the valid range with the same weekday, also in leap year or not, etc...
The issue is that DateTime is using the underlying OS in an inconsistent manner.
Let's take the example above: 1/1/1970 in the Europe/London timezone.
First, the number of seconds since the Epoch in UTC is calculated, here 0.
Then, the timezone offset at the given time is calculated using the underlying
OS. In this case, an historical deviation is taken into account. Indeed, London
stayed on British Summer Time between 27 October 1968 and 31 October 1971. See
https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation for
details.
Our resulting time is therefore negative (one hour difference with UTC).
When asked about the weekday of this time, the implementation notices that the
time is not in the positive range and picks an "equivalent" time in the future.
It then asks the underlying OS about the timezone offset for this time, which
is 0 (usually no daylight saving time in January in London). Unfortunately,
this time is not really equivalent, because it ignores the original historical
deviation. The result is wrongly equivalent to 12/31/1969 23:00 in London, i.e.
a Wednesday, and not a Thursday as expected.
Solution:
We should use the underlying OS in a consistent way, by simply allowing the
value of time_t passed to the underlying OS to be negative, which is legal.
R=floitsch@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org/1845483002 .
Jacob Richman