Skip to content

Public dependency on once_cell #575

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

Open
CosmicHorrorDev opened this issue Mar 11, 2025 · 3 comments · May be fixed by #576
Open

Public dependency on once_cell #575

CosmicHorrorDev opened this issue Mar 11, 2025 · 3 comments · May be fixed by #576

Comments

@CosmicHorrorDev
Copy link
Contributor

CosmicHorrorDev commented Mar 11, 2025

Now that there are things like OnceLock (since 1.70.0) and LazyLock(since 1.80.0) in the standard library it'd be nice to migrate off of once_cell. The one current issue with this is that it's a breaking change for this library due to syntect::parsing::SCOPE_REPO being a part of the public API while it's a once_cell::sync::Lazy. It'd be nice to change this in the next breaking release if possible (and I'd be willing to open a PR to handle it)

@keith-hall
Copy link
Collaborator

I wonder if anyone ever actually uses syntect::parsing::SCOPE_REPO, most likely I expect it wouldn't be a big deal to change it and release a new major version as it would be trivial to upgrade 🤞

@Enselic
Copy link
Collaborator

Enselic commented Mar 17, 2025

Also see #512.

I'm not against releasing a new major version, but then I think we should try to fix the issues listed in https://github.com/trishume/syntect/milestone/1 and maybe go through new issues since then and see if there is more to do. It would be nice to not have to release 7.0 shortly after 6.0.

@CosmicHorrorDev
Copy link
Contributor Author

Well since it sounds like everyone is on board with getting rid of SCOPE_REPO in it's current iteration I'll go ahead and open a PR that can officially mark it #[deprecated] which can get out in the next non-breaking release. I'm fine with #576 hanging around till whenever things are ready for 6.0

I can also spend some of my freetime over the next couple of months working towards the 6.0 milestone. #512 does look like a good place to start

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 a pull request may close this issue.

3 participants