mirror of
https://github.com/nodejs/node.git
synced 2026-11-09 15:11:11 -05:00
Anna Henningsen
bd20110286
- Instead of storing a pointer whose type refers to the specific subclass of `BaseObject`, just store a `BaseObject*` directly. This means in particular that one can cast to classes along the way of the inheritance chain without issues, and that `BaseObject*` no longer needs to be the first superclass in the case of multiple inheritance. In particular, this renders hack-y solutions to this problem (likeddc19be6de) obsolete and addresses a `TODO` comment of mine. - Move wrapping/unwrapping methods to the `BaseObject` class. We use these almost exclusively for `BaseObject`s, and I hope that this gives a better idea of how (and for what) these are used in our code. - Perform initialization/deinitialization of the internal field in the `BaseObject*` constructor/destructor. This makes the code a bit more obviously correct, avoids explicit calls for this in subclass constructors, and in particular allows us to avoid crash situations when we previously called `ClearWrap()` during GC. This also means that we enforce that the object passed to the `BaseObject` constructor needs to have an internal field. This is the only reason for the test change. - Change the signature of `MakeWeak()` to not require a pointer argument. Previously, this would always have been the same as `this`, and no other value made sense. Also, the parameter was something that I personally found somewhat confusing when becoming familiar with Node’s code. - Add a `TODO` comment that motivates switching to real inheritance for the JS types we expose from the native side. This patch brings us a lot closer to being able to do that. - Some less significant drive-by cleanup. Since we *effectively* already store the `BaseObject*` pointer anyway sinceddc19be6de, I do not think that this is going to have any impact on diagnostic tooling. Fixes: https://github.com/nodejs/node/issues/18897 PR-URL: https://github.com/nodejs/node/pull/20455 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Node.js Core Tests
This directory contains code and data used to test the Node.js implementation.
For a detailed guide on how to write tests in this directory, see the guide on writing tests.
On how to run tests in this directory, see the contributing guide.
Test Directories
| Directory | Runs on CI | Purpose |
|---|---|---|
| abort | Yes | Tests for when the --abort-on-uncaught-exception flag is used. |
| addons | Yes | Tests for addon functionality along with some tests that require an addon to function properly. |
| cctest | Yes | C++ test that is run as part of the build process. |
| common | Common modules shared among many tests. Documentation | |
| es-module | Yes | Test ESM module loading. |
| fixtures | Test fixtures used in various tests throughout the test suite. | |
| gc | No | Tests for garbage collection related functionality. |
| internet | No | Tests that make real outbound connections (mainly networking related modules). Tests for networking related modules may also be present in other directories, but those tests do not make outbound connections. |
| known_issues | Yes | Tests reproducing known issues within the system. All tests inside of this directory are expected to fail consistently. If a test doesn't fail on certain platforms, those should be skipped via known_issues.status. |
| message | Yes | Tests for messages that are output for various conditions (console.log, error messages etc.) |
| parallel | Yes | Various tests that are able to be run in parallel. |
| pseudo-tty | Yes | Tests that require stdin/stdout/stderr to be a TTY. |
| pummel | No | Various tests for various modules / system functionality operating under load. |
| sequential | Yes | Various tests that are run sequentially. |
| testpy | Test configuration utility used by various test suites. | |
| tick-processor | No | Tests for the V8 tick processor integration. The tests are for the logic in lib/internal/v8_prof_processor.js and lib/internal/v8_prof_polyfill.js. The tests confirm that the profile processor packages the correct set of scripts from V8 and introduces the correct platform specific logic. |
| timers | No | Tests for timing utilities (setTimeout and setInterval). |
When a new test directory is added, make sure to update the CI_JS_SUITES
variable in the Makefile and the js_test_suites variable in
vcbuild.bat.