Skip to content

New FontData Constructor to create a deep copy #2128

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

Merged
merged 1 commit into from
Jun 16, 2025

Conversation

ShahzaibIbrahim
Copy link
Contributor

This change will give us a chance to use proper channel to create a deep copy of FontData object instead of using FontData(fd.toString)

Copy link
Contributor

github-actions bot commented May 8, 2025

Test Results

   545 files     545 suites   29m 32s ⏱️
 4 400 tests  4 382 ✅  18 💤 0 ❌
16 727 runs  16 587 ✅ 140 💤 0 ❌

Results for commit 3b174ca.

♻️ This comment has been updated with latest results.

@ShahzaibIbrahim ShahzaibIbrahim marked this pull request as ready for review May 8, 2025 11:56
@ShahzaibIbrahim ShahzaibIbrahim force-pushed the master-296 branch 2 times, most recently from c7a5291 to 46cfcee Compare May 13, 2025 10:16
Copy link
Contributor

@HeikoKlare HeikoKlare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a proper copy constructor for FontData sounds reasonable to me.
However, the implementations are no proper copy constructors. They seem to be copies of the String-based constructors which is only able to copy the data present in the string, while a proper copy constructor can simply deep-copy all the data from the existing FontData object.

@ShahzaibIbrahim ShahzaibIbrahim marked this pull request as draft June 3, 2025 11:56
@ShahzaibIbrahim ShahzaibIbrahim marked this pull request as ready for review June 3, 2025 12:10
Copy link
Contributor

@HeikoKlare HeikoKlare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, this now looks fine to me. I only have some minor comments regarding code style.

@ShahzaibIbrahim ShahzaibIbrahim force-pushed the master-296 branch 2 times, most recently from 2d5c93f to aee6314 Compare June 5, 2025 09:28
Copy link
Contributor

@HeikoKlare HeikoKlare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good now. Before merging we will just need to ensure that the @since tags are updated to 3.131 (you could already do that now) and that the necessary version bump to 3.131 is applied (if not yet done by then).

@fedejeanne
Copy link
Contributor

@ShahzaibIbrahim can you please bump the appropriate versions and link/document the failing tests?

[win32] Introducing new FontData Constructor to create a deep copy

This change will give us a chance to use proper channel to create a deep
copy of FontData object instead of using FontData(fd.toString)
@HeikoKlare HeikoKlare merged commit 9faeb19 into eclipse-platform:master Jun 16, 2025
17 checks passed
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

Successfully merging this pull request may close these issues.

Improve FontData Copying: Replace String Constructor with Safer Approach
3 participants