Skip to content
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

A general way to test scope resolving logic #1227

Closed
hyf0 opened this issue Nov 12, 2023 · 2 comments
Closed

A general way to test scope resolving logic #1227

hyf0 opened this issue Nov 12, 2023 · 2 comments

Comments

@hyf0
Copy link
Contributor

hyf0 commented Nov 12, 2023

pub struct SemanticTester {
allocator: Allocator,
source_type: SourceType,
source_text: &'static str,
}

The current SemanticTester is great to do many kinds of assertions. Such as

SemanticTester::js("export class Foo {}")
.has_root_symbol("Foo")
.contains_flags(SymbolFlags::Class | SymbolFlags::Export)
.has_number_of_references(0)
.is_exported()
.test();
.

But I kind of think the SemanticTester might not be that intuitive for testing general scope resolving logic, which means weather the symbol has correct scope and don't care about the flags or others.

Let's see we have test case

log()

let a = 1
log(a)
let b = 1
log(b)
{
  let a = 2
  log(a)
  log(b)
}

we could transform it to

log#0()

let a#1 = 1
log(a#1)
let b#1 = 1;
log(b#1);
{
  let a#2 = 2;
  log(a#2)
  log(b#1)
}

the x in #x is the ScopeId we get from the Sematics.

In this way, we could easily visualize the whether the scope is correct. And with snapshot testing, this could be a general way for testing without any other kinds of assertions.


I get this idea from contributing to swc. https://github.com/swc-project/swc/blob/main/crates/swc_ecma_transforms_base/tests/resolver/hoisting/output.js

@Boshen
Copy link
Member

Boshen commented Nov 12, 2023

Intresting. I think it's hard to cover all cases by manually writing test cases, the general approach should be running Test262 over mangled files ... let me think about this.

@Boshen
Copy link
Member

Boshen commented Feb 5, 2024

We should rely and take advantage of test262 instead of manual tests.

@Boshen Boshen closed this as not planned Won't fix, can't repro, duplicate, stale Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants