no longer leak StringStack from our API

[devoncarew]

• remove places where we were leaking StringStack from our API

This might technically be a breaking change for our users, but I assume that in practice nobody was relying on the visibility here. This leak was reported on my previous PR from the health check:

I was not able to find where we were leaking DateBuilder from.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[github-actions]

PR Health

Breaking changes ⚠️

Package	Change	Current Version	New Version	Needed Version	Looking good?
intl	Breaking	0.20.1	0.20.1	0.21.0 Got "0.20.1" expected >= "0.21.0" (breaking changes)	⚠️

This check can be disabled by tagging the PR with skip-breaking-check.

Changelog Entry ❗

Package	Changed Files
package:intl	pkgs/intl/lib/src/intl/date_builder.dart pkgs/intl/lib/src/intl/number_parser_base.dart

Changes to files need to be accounted for in their respective changelogs.

This check can be disabled by tagging the PR with skip-changelog-check.

Coverage ✔️

File	Coverage
pkgs/intl/lib/src/intl/date_builder.dart	💚 92 %
pkgs/intl/lib/src/intl/number_parser_base.dart	💚 92 %

This check for test coverage is informational (issues shown here will not fail the PR).

API leaks ⚠️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbols
intl	StringStack DateBuilder

This check can be disabled by tagging the PR with skip-leaking-check.

License Headers ✔️

// Copyright (c) 2024, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

[devoncarew]

Hmm, we may still be leaking StringStack.

[devoncarew]

Running it locally, I see:

The following declarations do not have an entry point (did you miss to export them?):
  StringStack
    Usage(s):
    - intl/date_format_field.dart::_DateFormatField::parse::input
    - intl/date_format_field.dart::_DateFormatField::parseLoose::input
    - intl/date_format_field.dart::_DateFormatField::parseLiteral::input
    - intl/date_format_field.dart::_DateFormatField::parseLiteralLoose::input
    - intl/date_format_field.dart::_DateFormatField::throwFormatException::stack
    - intl/number_parser_base.dart::NumberParserBase::parseNumber::input
  DateBuilder
    Usage(s):
    - intl/date_format_field.dart::_DateFormatField::parse::dateFields
    - intl/date_format_field.dart::_DateFormatField::parseLoose::dateFields

We may want to print local run instructions as part of the health check stdout, and or more verbose info about where things leaked from.

[devoncarew]

The API tool seems to think things are leaking from _DateFormatField, which as a private class isn't visible outside the library.

[devoncarew]

Ah, from date_format.dart:

  /// Parse the template pattern and return a list of field objects.
  @visibleForTesting
  @Deprecated('clients should not depend on this internal method')
  // ignore: library_private_types_in_public_api
  List<_DateFormatField> parsePattern(String pattern) {
     ...