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

Re-factor the handling of *empty* Name-instances (PR 13612 follow-up) #13738

Merged
merged 1 commit into from
Jul 15, 2021

Conversation

Snuffleupagus
Copy link
Collaborator

When working on PR #13612, I mostly prioritized a simple solution that didn't require touching a lot of code. However, while working on PR #13735 I started to realize that the static Name.empty construction really wasn't a good idea.

In particular, having a special Name-instance where the name-property isn't actually a String is confusing (to put it mildly) and can easily lead to issues elsewhere. The only reason for not simply allowing the name-property to be an empty string, in PR #13612, was to avoid having to touch a lot of existing code. However, it turns out that this is only limited to a few methods in the PartialEvaluator and a few of the BaseLocalCache-implementations, all of which can be easily re-factored to handle empty Name-instances.

All-in-all, I think that this patch is even an overall improvement since we're now validating (what should always be) Name-data better in the PartialEvaluator.
This is what I ought to have done from the start, sorry about the code churn here!

When working on PR 13612, I mostly prioritized a simple solution that didn't require touching a lot of code. However, while working on PR 13735 I started to realize that the static `Name.empty` construction really wasn't a good idea.

In particular, having a special `Name`-instance where the `name`-property isn't actually a String is confusing (to put it mildly) and can easily lead to issues elsewhere. The only reason for not simply allowing the `name`-property to be an *empty* string, in PR 13612, was to avoid having to touch a lot of existing code. However, it turns out that this is only limited to a few methods in the `PartialEvaluator` and a few of the `BaseLocalCache`-implementations, all of which can be easily re-factored to handle *empty* `Name`-instances.

All-in-all, I think that this patch is even an *overall* improvement since we're now validating (what should always be) `Name`-data better in the `PartialEvaluator`.
This is what I ought to have done from the start, sorry about the code churn here!
@Snuffleupagus
Copy link
Collaborator Author

/botio test

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Received

Command cmd_test from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/33e37f09a31d740/output.txt

@pdfjsbot
Copy link

From: Bot.io (Windows)


Received

Command cmd_test from @Snuffleupagus received. Current queue size: 0

Live output at: http://3.101.106.178:8877/424b3404859ba99/output.txt

@pdfjsbot
Copy link

From: Bot.io (Windows)


Failed

Full output at http://3.101.106.178:8877/424b3404859ba99/output.txt

Total script time: 37.71 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Integration Tests: Passed
  • Regression tests: FAILED
  different ref/snapshot: 12
  different first/second rendering: 1

Image differences available at: http://3.101.106.178:8877/424b3404859ba99/reftest-analyzer.html#web=eq.log

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Failed

Full output at http://54.67.70.0:8877/33e37f09a31d740/output.txt

Total script time: 60.00 mins

@timvandermeij timvandermeij merged commit c1f89c7 into mozilla:master Jul 15, 2021
@timvandermeij
Copy link
Contributor

Thanks!

@Snuffleupagus Snuffleupagus deleted the empty-Name branch July 15, 2021 20:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants