-
-
Notifications
You must be signed in to change notification settings - Fork 400
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#3696 - tc39-test262 Crate #3708
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3708 +/- ##
==========================================
+ Coverage 47.24% 47.37% +0.12%
==========================================
Files 476 461 -15
Lines 46892 44846 -2046
==========================================
- Hits 22154 21245 -909
+ Misses 24738 23601 -1137 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merge comments
@@ -220,54 +220,6 @@ impl RunTest<OptimizerOptions, TestResult> for Test { | |||
} | |||
} | |||
|
|||
/// Creates the test result from the outcome and message. | |||
fn create_result<S: Into<Box<str>>>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved to helper function (Out of Trait)
tools/tc39-test262/src/edition.rs
Outdated
@@ -87,9 +93,13 @@ static FEATURE_EDITION: phf::Map<&'static str, SpecEdition> = phf::phf_map! { | |||
// https://github.com/tc39/proposal-set-methods | |||
"set-methods" => SpecEdition::ESNext, | |||
|
|||
// Regular Expression Pattern Modifiers | |||
// https://github.com/tc39/proposal-regexp-modifiers | |||
"regexp-modifiers" => SpecEdition::ESNext, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicate in line 76
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for all the work!
It's been several days going back and forth on this PR about whether to put the feature to editions map into the new crate or the tester.
On the one hand, features are part of the test262 suite and we may include them to also get the edition of a test. On the other hand, if we include them, we would need to keep the crate pretty much updated with every new commit to the test262 repo, which would be a pretty big maintenance work for us.
I'm tending towards leaving the editions on the tester, since I don't see many use cases for it aside from engine tests. What do you think?
I wonder if would be ok for tests that contains unknown features set edition to ESNext as a fallback option. I guess in that case they could be marked as ignored as well. Thinking long term:
|
That would also be a good option for the short-term. On the long term, I'm trying to push for adding this metadata to |
tools/tc39-test262/src/edition.rs
Outdated
@@ -39,12 +39,6 @@ static FEATURE_EDITION: phf::Map<&'static str, SpecEdition> = phf::phf_map! { | |||
// https://github.com/tc39/proposal-json-modules | |||
"json-modules" => SpecEdition::ESNext, | |||
|
|||
// https://github.com/tc39/proposal-source-phase-imports |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicated
Temporally fallback to ESNext while pending on features map on tc39/test262#4161. @jedel1043 Could you please take a look on this: I guess with that change we could merge this PR and implement features map parser later. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass of reviews. It's starting to look really nice!
tests/tester/src/exec/mod.rs
Outdated
pub(crate) trait RunTest<TO, TR> { | ||
/// Runs the test. | ||
fn run(&self, harness: &Harness, verbose: u8, optimizer_options: TO, console: bool) -> TR; | ||
|
||
/// Runs the test once, in strict or non-strict mode | ||
fn run_once( | ||
&self, | ||
harness: &Harness, | ||
strict: bool, | ||
verbose: u8, | ||
optimizer_options: OptimizerOptions, | ||
console: bool, | ||
) -> TestResult; | ||
} | ||
|
||
pub(crate) trait RunTestSuite<TO, TR> { | ||
/// Runs the test suite. | ||
fn run( | ||
&self, | ||
harness: &Harness, | ||
verbose: u8, | ||
parallel: bool, | ||
max_edition: SpecEdition, | ||
optimizer_options: OptimizerOptions, | ||
console: bool, | ||
) -> SuiteResult; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need these to be generic traits? They could also be simple traits without generics, since they're only used internally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, we can remove generics.
tools/tc39-test262/Cargo.toml
Outdated
@@ -0,0 +1,24 @@ | |||
[package] | |||
name = "tc39-test262" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is test262
available in crates.io? That could potentially be a better name for the crate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like test262
it's available.
tools/tc39-test262/src/edition.rs
Outdated
@@ -292,7 +290,7 @@ static FEATURE_EDITION: phf::Map<&'static str, SpecEdition> = phf::phf_map! { | |||
clap::ValueEnum, | |||
)] | |||
#[repr(u8)] | |||
pub(crate) enum SpecEdition { | |||
pub enum SpecEdition { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To prepare for the test262 changes, this should probably become an open enum instead.
pub struct SpecEdition(u8);
impl SpecEdition {
const ES5: SpecEdition = SpecEdition(5);
const ES8: SpecEdition = SpecEdition(8);
}
tools/tc39-test262/src/lib.rs
Outdated
pub fn clone_test262(commit: Option<&str>, verbose: u8) -> color_eyre::Result<()> { | ||
const TEST262_REPOSITORY: &str = "https://github.com/tc39/test262"; | ||
git::clone( | ||
TEST262_DIRECTORY, | ||
TEST262_REPOSITORY, | ||
&"origin/main", | ||
commit, | ||
verbose, | ||
) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we should expose a clone_repo
function. IMO, we should provide a test262
function that takes a struct of options and returns the whole suite, optionally cloning the repo if a path to a valid repo is not provided.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okey, that seams reasonable to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After longer consideration and refactor I not sure if reading and optionally cloning logic should be in the same function (double responsibility).
- it would add more complexity to read(...) fn signature as we would have to provide extra information (struct) on each read level (harness, suite, test).
- if we provide it only on the suite level api in that form can be confusing and inconsistent.
Usage in main:
in this example if path to suite would be a direct path to test (.js) test262 would skip clone and return error, causing inconsistent cli behavior.
@jedel1043 please let me know what do you think about it. Maybe I'm missing something and there is a better solution to make it done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need the public read
to be the same as the read
used internally. I'd expect something like having a test262::read
that does all the fetch git logic, then a private test262::read_from_dict
that is called by test262::read
and does the reading tests logic. Also, I'd avoid exposing pub read
functions for the other components.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jedel1043 Thanks for clarification.
Please take a look at this changes and let me know if there are closer to the expected result.
027fbb4?diff=split&w=0
Still some work is needed, but I want to make sure that this is the desired direction.
tools/tc39-test262/src/read.rs
Outdated
|
||
/// Reads the Test262 defined bindings. | ||
pub(super) fn read_harness(test262_path: &Path) -> Result<Harness> { | ||
pub fn read_harness(test262_path: &Path) -> Result<Harness> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, I think all of these should just be private, and the user should be able to explore the repo using methods in Test
, TestSuite
, and friends.
tools/tc39-test262/src/test_files.rs
Outdated
|
||
impl Test { | ||
/// Creates a new test. | ||
pub fn new<N, C>(name: N, path: C, metadata: MetaData) -> color_eyre::Result<Self> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not use eyre
for error handling. We should have an Error
enum that people can match on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for review @jedel1043
tools/tc39-test262/Cargo.toml
Outdated
@@ -0,0 +1,24 @@ | |||
[package] | |||
name = "tc39-test262" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like test262
it's available.
tools/tc39-test262/src/lib.rs
Outdated
pub fn clone_test262(commit: Option<&str>, verbose: u8) -> color_eyre::Result<()> { | ||
const TEST262_REPOSITORY: &str = "https://github.com/tc39/test262"; | ||
git::clone( | ||
TEST262_DIRECTORY, | ||
TEST262_REPOSITORY, | ||
&"origin/main", | ||
commit, | ||
verbose, | ||
) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okey, that seams reasonable to me.
tests/tester/src/exec/mod.rs
Outdated
pub(crate) trait RunTest<TO, TR> { | ||
/// Runs the test. | ||
fn run(&self, harness: &Harness, verbose: u8, optimizer_options: TO, console: bool) -> TR; | ||
|
||
/// Runs the test once, in strict or non-strict mode | ||
fn run_once( | ||
&self, | ||
harness: &Harness, | ||
strict: bool, | ||
verbose: u8, | ||
optimizer_options: OptimizerOptions, | ||
console: bool, | ||
) -> TestResult; | ||
} | ||
|
||
pub(crate) trait RunTestSuite<TO, TR> { | ||
/// Runs the test suite. | ||
fn run( | ||
&self, | ||
harness: &Harness, | ||
verbose: u8, | ||
parallel: bool, | ||
max_edition: SpecEdition, | ||
optimizer_options: OptimizerOptions, | ||
console: bool, | ||
) -> SuiteResult; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, we can remove generics.
This Pull Request closes #3696.
It changes the following:
boa_tester
parser logic totools/tc39-test262
crate