Skip to content

feat(semantics): collect symbols used for function / class names#9872

Closed
sapphi-red wants to merge 1 commit intomainfrom
03-18-feat_semantics_collect_symbols_used_for_function___class_names
Closed

feat(semantics): collect symbols used for function / class names#9872
sapphi-red wants to merge 1 commit intomainfrom
03-18-feat_semantics_collect_symbols_used_for_function___class_names

Conversation

@sapphi-red
Copy link
Member

@sapphi-red sapphi-red commented Mar 18, 2025

Collect symbols that are used for function / class names so that we can use this information in the mangler.

@github-actions github-actions bot added A-semantic Area - Semantic C-enhancement Category - New feature or request labels Mar 18, 2025
Copy link
Member Author

sapphi-red commented Mar 18, 2025


How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

  • 0-merge - adds this PR to the back of the merge queue
  • hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

@sapphi-red sapphi-red marked this pull request as ready for review March 18, 2025 13:03
@codspeed-hq
Copy link

codspeed-hq bot commented Mar 18, 2025

CodSpeed Performance Report

Merging #9872 will not alter performance

Comparing 03-18-feat_semantics_collect_symbols_used_for_function___class_names (af0a969) with main (ecdfe2e)

Summary

✅ 33 untouched benchmarks

@overlookmotel
Copy link
Member

My concern about this change is that this is more semantic data that we need to keep in sync with AST changes in transformer. That's quite a struggle already!

Is this necessary to achieve the keepNames option? Could we maybe achieve the same thing with SymbolFlags?

@sapphi-red
Copy link
Member Author

sapphi-red commented Mar 18, 2025

Is this necessary to achieve the keepNames option? Could we maybe achieve the same thing with SymbolFlags?

It isn't necessary; the other option I can think of is to check the parent node in the mangler by calling nodes().parent_node(node) for each symbol declaration and references.
Current SymbolFlags does not contain the needed information so it cannot be used.

@camc314
Copy link
Contributor

camc314 commented Mar 18, 2025

i think

diff --git a/crates/oxc_mangler/src/lib.rs b/crates/oxc_mangler/src/lib.rs
index d43bea1b8..adb8a087e 100644
--- a/crates/oxc_mangler/src/lib.rs
+++ b/crates/oxc_mangler/src/lib.rs
@@ -388,6 +388,14 @@ impl Mangler {
             if is_special_name(scoping.symbol_name(symbol_id)) {
                 continue;
             }
+
+            let symbol_flags: oxc_semantic::SymbolFlags = scoping.symbol_flags(symbol_id);
+
+            if self.options.keep_names.function && symbol_flags.is_function()
+                || self.options.keep_names.class && symbol_flags.is_class()
+            {
+                continue;
+            }
             let index = slot;
             frequencies[index].slot = slot;
             frequencies[index].frequency += scoping.get_resolved_reference_ids(symbol_id).len();

should work

iirc, i tried this a very long time ago and that diff seemed to have the desired effect

@Boshen Boshen marked this pull request as draft March 18, 2025 13:21
@Boshen Boshen self-assigned this Mar 18, 2025
@sapphi-red
Copy link
Member Author

@sapphi-red
Copy link
Member Author

the other option I can think of is to check the parent node in the mangler by calling nodes().parent_node(node) for each symbol declaration and references.

On second thought, this sounds better. Also found this code which does a similar thing.

match parent_node.kind() {
AstKind::VariableDeclarator(declarator) => {
matches!(declarator.id.kind, BindingPatternKind::BindingIdentifier(_))
&& matches!(declarator.init.as_ref().unwrap(), Expression::FunctionExpression(function_expression)
if get_function_identifier(function_expression) == get_function_identifier(function)
)
}
AstKind::ObjectProperty(property) => {
matches!(&property.value, Expression::FunctionExpression(function_expression)
if get_function_identifier(function_expression) == get_function_identifier(function)
)
}
AstKind::PropertyDefinition(definition) => {
matches!(&definition.value.as_ref().unwrap(), Expression::FunctionExpression(function_expression)
if get_function_identifier(function_expression) == get_function_identifier(function)
)
}
AstKind::AssignmentExpression(expression) => {
matches!(expression.left, AssignmentTarget::AssignmentTargetIdentifier(_))
&& matches!(&expression.right, Expression::FunctionExpression(function_expression)
if get_function_identifier(function_expression) == get_function_identifier(function)
)
}
AstKind::AssignmentTargetWithDefault(target) => {
matches!(target.binding, AssignmentTarget::AssignmentTargetIdentifier(_))
&& matches!(&target.init, Expression::FunctionExpression(function_expression)
if get_function_identifier(function_expression) == get_function_identifier(function)
)
}
AstKind::AssignmentPattern(pattern) => {
matches!(pattern.left.kind, BindingPatternKind::BindingIdentifier(_))
&& matches!(&pattern.right, Expression::FunctionExpression(function_expression)
if get_function_identifier(function_expression) == get_function_identifier(function)
)
}
AstKind::ObjectAssignmentTarget(target) => {
for property in &target.properties {
let AssignmentTargetProperty::AssignmentTargetPropertyIdentifier(identifier) =
property
else {
continue;
};
let Expression::FunctionExpression(function_expression) =
&identifier.init.as_ref().unwrap()
else {
continue;
};
if get_function_identifier(function_expression) == get_function_identifier(function)
{
return true;
}
}
false
}
_ => false,

@Boshen Boshen closed this Mar 23, 2025
graphite-app bot pushed a commit that referenced this pull request Mar 23, 2025
…9897)

Same as #9872 but implemented in the mangler instead.

close #9872
@overlookmotel overlookmotel deleted the 03-18-feat_semantics_collect_symbols_used_for_function___class_names branch March 24, 2025 11:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-semantic Area - Semantic C-enhancement Category - New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants