Strict Gregorian calendar interpretation #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PR-URL: nodejs#51792 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Moshe Atlow <moshe@atlow.co.il> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Fixes: nodejs#51479 PR-URL: nodejs#51812 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>
PR-URL: nodejs#51799 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
PR-URL: nodejs#51663 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Adrian Estrada <edsadr@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
It is safe to create the console properties for the global console at snapshot build time. Streams must still be created lazily however because they need special synchronization for the handles. PR-URL: nodejs#51700 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
By default V8 only compiles the top-level function and skips code generation for inner functions - that would only be done when those inner functions are invoked. Since builtins are compiled as wrapped functions, most functions that look visually top-level are not actually included in the built-in code cache. For most of the builtins this is not too bad because usually only a subset of all builtin functions are needed by a particular application and including all their code in the binary would incur an unnecessary size overhead. But there is also a subset of more commonly used builtins and it would be better to include the inner functions in the built-in code cache because they are more universally used by most applications. This patch changes the compilation strategy to eager compilation (including inner functions) for the following scripts: 1. Primordials (internal/per_context/*), in all situations. 2. Bootstrap scripts (internal/bootstrap/*) and main scripts (internal/main/*), when being compiled for built-in code cache. 3. Any scripts loaded during built-in snapshot generation. We can't compile the code eagerly during snapshot generation and include them into the V8 snapshot itself just now because we need to start the inspector before context deserialization for coverage collection to work. So leave that as a TODO. With this patch the binary size increases by about 666KB (~0.6% increase) in return the worker startup can be 18-19% faster. PR-URL: nodejs#51672 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
We previously build the ESM facade (synthetic modules re-exporting builtin's exports) for builtins even when they are not directly import'ed (which rarely happens for internal builtins as that requires --expose-internals). This patch removes the eager generation to avoid the overhead and the extra promises created in facade building when it's not reqested by the user. When the facade is needed the ESM loader that can be requested it in the translator on-demand. Drive-by: set the ModuleWrap prototype to null in the built-in snapshot. PR-URL: nodejs#51669 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
It is easier to filter the core startup benchmark with this name. PR-URL: nodejs#51669 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Previously we only had an internal assertion to ensure certain code is executed before any user-provided CJS is run. This patch adds another assertion for ESM. Note that this internal state is not updated during source text module execution via vm because to run any code via vm, some user JS code must have already been executed anyway. In addition this patch moves the states into internal/modules/helpers to avoid circular dependencies. Also moves toggling the states to true *right before* user code execution instead of after in case we are half-way in the execution when internals try to check them. PR-URL: nodejs#51748 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
PR-URL: nodejs#51806 Reviewed-By: Beth Griggs <bethanyngriggs@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Ruy Adorno <ruyadorno@google.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: nodejs#51803 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Adrian Estrada <edsadr@gmail.com> Reviewed-By: Shelley Vohr <shelley.vohr@gmail.com>
Refs: nodejs/TSC#1501 Signed-off-by: Michael Dawson <midawson@redhat.com> PR-URL: nodejs#51825 Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Refs: nodejs#31727 (comment) PR-URL: nodejs#51735 Reviewed-By: Michael Dawson <midawson@redhat.com>
It has failed 22 PRs from the latest 100 CI runs. PR-URL: nodejs#51834 Refs: nodejs#51822 Refs: nodejs/reliability#790 Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Using this to iterate over an array can be faster than calling Array::Get repeatedly. Local experiment shows that this is faster once the array size is bigger than 2. PR-URL: nodejs#51758 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
PR-URL: nodejs#51758 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Previously we wrapped the embedder entry point callback into a binding and then invoke the binding from JS land which was a bit convoluted. Now we just call it directly from C++. The main scripts that needed to tail call the embedder callback now return the arguments in an array so that the C++ land can extract the arguments and pass them to the callback. We also set `PauseOnNextJavascriptStatement()` for --inspect-brk and mark the bootstrap complete milestone directly in C++ for these execution modes. PR-URL: nodejs#51557 Reviewed-By: Daniel Lemire <daniel@lemire.me> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
This is a follow-up to nodejs#51605. PR-URL: nodejs#51818 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This change can be removed after the upstream fix lands in Node: c-ares/c-ares#709 PR-URL: nodejs#51687 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
PR-URL: nodejs#50737 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
PR-URL: nodejs#51439 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: nodejs#51571 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Vladimir Morozov <vmorozov@microsoft.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
`NodeRuntime.waitingForDebugger` is a new Inspector Protocol event that
will fire when the process being inspected is waiting for the debugger
(for example, when `inspector.waitForDebugger()` is called). This allows
inspecting processes to know when the inspected process is waiting for a
`Runtime.runIfWaitingForDebugger` message to resume execution. It allows
tooling to resume execution of the inspected process as soon as it deems
necessary, without having to guess if the inspected process is waiting
or not, making the workflow more deterministic. With a more
deterministic workflow, it is possible to update Node.js core tests to
avoid race conditions that can cause flakiness. Therefore, tests were
also changed as following:
* Remove no-op Runtime.runIfWaitingForDebugger from tests that don't
need it
* Use NodeRuntime.waitingForDebugger in all tests that need
Runtime.runIfWaitingForDebugger, to ensure order of operations is
predictable and correct
* Simplify test-inspector-multisession-ws
There might be value in adding `NodeWorker.waitingForDebugger` in a
future patch, but as of right now, no Node.js core inspector tests using
worker threads are not failing due to race conditions.
Fixes: nodejs#34730
PR-URL: nodejs#51560
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Move the child process code into a fixture and split the test so that it can be run in parallel and it's easier to identify where the failure is coming from. Also use the spawnSyncAndExitWithoutError() utility so that the test shows complete information on failure. Instead of marking all the wasi tests as flaky, only mark the wasi-poll one which is flaking in the CI now. PR-URL: nodejs#51836 Refs: nodejs#51822 Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>
Because the previous security release modified the bundled version of libuv, we cannot automatically update libuv without potentially undoing those changes. PR-URL: nodejs#51775 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
The child processes are supposed to get 4 messages (2 ends, 2 writes). Previously the mustCall() wrapping the message listener attempts to match exactly 1 invocation which is bound to fail but could be swallowed if the child happens to be killed before the exit event is fired for the mustCall() check to work. In the CI, on some machines the kill() could happen after the child process finishes with the mustCall() check, resulting in EPERM errors in kill(). This patch fixes the mustCall() checks (updating the expected invocation count to 4) and swallow the errors when kill() fails, which should be fine because they are only there for cleanup. PR-URL: nodejs#51841 Refs: nodejs#51813 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The recursive fs watch tests that mutate the watched folder immediately after fs.watch() returns are all flaking in the CI while the others that mutate the folder with a bit of delay aren't flaking. So this patch adds a bit of delay for the rest of the tests to deflake them. PR-URL: nodejs#51842 Refs: nodejs/reliability#790 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: nodejs#51632 Fixes: nodejs#50184 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
The latest clang warns about this. PR-URL: nodejs#51845 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: nodejs#51795 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
In many cases we can query the environment variable directly instead of encoding it into UTF8 first and then decoding it again from UTF8 via an intermediate V8 string. Drive-by: pass per_process::system_environment explicitly when the real environment variables are supposed to be used instead of relying on fallback with defaults. PR-URL: nodejs#51829 Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: nodejs#51331 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Fixed: nodejs#50571 PR-URL: nodejs#51416 Fixes: nodejs#50571 Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Fixes: nodejs#50571 PR-URL: nodejs#51419 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
PR-URL: nodejs#51877 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Michael Dawson <midawson@redhat.com>
PR-URL: nodejs#51904 Reviewed-By: Moshe Atlow <moshe@atlow.co.il> Reviewed-By: Jacob Smith <jacob@frende.me> Reviewed-By: theanarkh <theratliter@gmail.com> Reviewed-By: Qingyu Deng <i@ayase-lab.com>
PR-URL: nodejs#51726 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Moshe Atlow <moshe@atlow.co.il> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
PR-URL: nodejs#51800 Fixes: nodejs#51789 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
PR-URL: nodejs#51713 Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Minwoo Jung <nodecorelab@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Previously, a value seen in 'actual' would be serialized as a circular reference if it had also appeared in 'expected'. PR-URL: nodejs#51851 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Moshe Atlow <moshe@atlow.co.il> Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
PR-URL: nodejs#51913 Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Richard Lau <rlau@redhat.com>
PR-URL: nodejs#51900 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Functions registered with `addSerializeCallback()` can access and call `process.cwd()`. b7d836e accounted for the fact that it is necessary to reset the cwd cache after the snapshot builder script has run, but did not account for possible accesses from serialization callbacks. To properly account for these, add a deserialization callback as well. As a related drive-by fix, also mention the execution order of callbacks in the documentation. Refs: nodejs#49684 PR-URL: nodejs#51901 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Previously the test assumes that when the queued finalizer is run, it must be run at a point where env->can_call_into_js() is false (typically, during Environment shutdown), which is not certain. If GC kicks in early and the second pass finalizer is queued before the event loop runs the check callbacks, the finalizer would then be called in check callbacks (via native immediates), where the finalizer can still call into JS. Essentially, addons can't make assumptions about where the queued finalizer would be called. This patch updates the assertions in the test to account for that. PR-URL: nodejs#51898 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
PR-URL: nodejs#51909 Fixes: nodejs#51907 Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Fix a bug caused by nodejs#50737 that, make install fails for --shared mode. PR-URL: nodejs#51910 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Try to match a test by name prefixed with all its ancestors to ensure uniqueness of the name Fixes: nodejs#46728 PR-URL: nodejs#51577 Reviewed-By: Moshe Atlow <moshe@atlow.co.il> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#51914 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
New option `--report-exclude-network`, also available as `report.excludeNetwork`, enables the user to exclude networking interfaces in their diagnostic report. On some systems, this can cause the report to take minutes to generate so this option can be used to optimize that. Fixes: nodejs#46060 PR-URL: nodejs#51645 Co-authored-by: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Previously it would not compile if the build is configured with --disable-single-executable-application because we use directives to exclude the definition of SEA-related code completely. This patch changes them so that the SEA code are still compiled and internals can still check whether the executable is an SEA. The executable would not try to load the SEA blob at all if SEA is disabled. If future modifications to the C++ code attempt to load the SEA blob when SEA is disabled, UNREACHABLE() would be raised. If user attempt to generate the SEA blob with --experimental-sea-config with an executable that disables SEA, they would get an error. PR-URL: nodejs#51808 Fixes: nodejs#51730 Reviewed-By: Tobias Nießen <tniessen@tnie.de>
In the SEA tests, if any of these steps fail: 1. Copy the executable 2. Inject the SEA blob 3. Signing the SEA We skip the test because the error likely comes from the system or postject and is not something the Node.js core can fix. We only leave an exception for a basic test that test injecting empty files as SEA to ensure the workflow is working (but we still skip if copying fails or signing fails on Windows). PR-URL: nodejs#51887 Refs: nodejs#49630 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#51917 Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Moshe Atlow <moshe@atlow.co.il> Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#51920 Reviewed-By: Moshe Atlow <moshe@atlow.co.il> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Searching the automatically-generated test failure reports in the issues at https://github.com/nodejs/reliability/issues, I don't see `test-worker-message-port-message-before-close` failing any time recently. PR-URL: nodejs#51736 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: nodejs#51884 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Refs: nodejs#50428 PR-URL: nodejs#51925 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
This is similar to the `queryObjects()` console API provided by the Chromium DevTools console. It can be used to search for objects that have the matching constructor on its prototype chain in the entire heap, which can be useful for memory leak regression tests. To avoid surprising results, users should avoid using this API on constructors whose implementation they don't control, or on constructors that can be invoked by other parties in the application. To avoid accidental leaks, this API does not return raw references to the objects found. By default, it returns the count of the objects found. If `options.format` is `'summary'`, it returns an array containing brief string representations for each object. The visibility provided in this API is similar to what the heap snapshot provides, while users can save the cost of serialization and parsing and directly filer the target objects during the search. We have been using this API internally for the test suite, which has been more stable than any other leak regression testing strategies in the CI. With a public implementation we can now use the public API instead. PR-URL: nodejs#51927 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
PR-URL: nodejs#51918 Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Dates >= October 5th and <= October 14th, 1582 will now automatically get shifted to October 15th.