@Since is not giving a warning when used from a package with a lower sdk constraint

[bsutton]

I'm not certain this is the correct spot but test is the only way I can see this working so here I am.

I managed to get myself into a right pickle and it's taken me the best part of a day to resolve.

I release a package to pub.dev with a min dartsdk of 2.12 in pubspec.yaml.

The problem was that I was running dart 2.16 on my dev/test system.
I added a feature in the code base which was from dart 2.16.
I successfully ran the unit tests and then published.

So the problem is when a user has dart 2.12 installed.

When a user tries to install my package (it's a CLI script) the install fails because pub global activate searches for the most recent package version that supports dart 2.12.
As soon as they try to run my cli script it fails because the 2.16 method I call doesn't exist and the dill compilation fails.

While the above problem is entirely my fault I really think we should have some systems in place to stop this type of mistake.

I can only think of a few possible solutions:

1. some static analysis process as part of pub publish which checks that the API's used are part of the publish match the pubspec.yaml.
2. pub publish warns if the local SDK version doesn't match the min pubspec version.
   This doesn't seem particularly useful.
3. have the test package check for a matching SDK and warn/error the user if they don't match.
   Error would be my preference with a switch to ignore the problem.

[jakemac53]

In general new APIs should have the @Since annotation, which the analyzer knows about and will warn you if you are using an API that doesn't exist in your min SDK version.

Was there a new api added that is missing this annotation?

[jakemac53]

tentatively assigning this to the core libs area, but we need more info for it to be actionable. If an annotation was missed there isn't much we can do about previously published SDKs, but we could add the annotation for future sdks.

[bsutton]

This is the method that caused the problem:

/// Throws [error] with associated stack trace [stackTrace].
  ///
  /// If [error] extends [Error] and has not yet been thrown,
  /// its [stackTrace] is set as well, just as if it was thrown by a `throw`.
  /// The actual stack trace captured along with the [error],
  /// or set on [error] if it is an [Error],
  /// may not be the [stackTrace] object itself,
  /// but will be a stack trace with the same content.
  @Since("2.16")
  static Never throwWithStackTrace(Object error, StackTrace stackTrace) {
    checkNotNullable(error, "error");
    checkNotNullable(stackTrace, "stackTrace");
    _throw(error, stackTrace);
  }

But as you can see it has the @Since directive.

[bsutton]

I"ve attached a sample app that demonstrates the issue.

since.zip

The pubspec.yaml is set to sdk: '>=2.12.0 <3.0.0'

bin/since.dart makes a call to Error.throwWithStackTrace

My dart version is:

Dart SDK version: 2.16.2 (stable) (Tue Mar 22 13:15:13 2022 +0100) on "linux_x64"

art analyze
Analyzing since...                     0.7s
No issues found!

[bsutton]

And the api documentation on throwWithStackTrace is thoroughly incomprehensible.

[jakemac53]

I wonder if this is because the API is called under bin and not lib? There may be a bug where it isn't treating bin as a public library, but it should be.

[jakemac53]

Huh, I can reproduce this on files under lib as well. It seems to me like @Since is possibly broken?

[bsutton]

No, this is just my little sample. In my real library (dcli) it is called from within lib/src. This is the release that exhibits the issue: https://pub.dev/packages/dcli/versions/1.17.5 S. Brett Sutton Noojee Contact Solutions 03 8320 8100

…

On Tue, 12 Apr 2022 at 07:37, Jacob MacDonald ***@***.***> wrote: I wonder if this is because the API is called under bin and not lib? There may be a bug where it isn't treating bin as a *public* library, but it should be. — Reply to this email directly, view it on GitHub <#48781 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32OF5VVQ3JWMOOLUMB7LVESLQ3ANCNFSM5TDTZKDQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bsutton]

Oh, good. It wasn't just me then :) S. Brett Sutton Noojee Contact Solutions 03 8320 8100

…

On Tue, 12 Apr 2022 at 07:41, Jacob MacDonald ***@***.***> wrote: Huh, I can reproduce this on files under lib as well. It seems to me like @SInCE is possibly broken? — Reply to this email directly, view it on GitHub <#48781 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32ODTK6SRZPA557GZJTTVESL6VANCNFSM5TDTZKDQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[lrhn]

I'm not sure the analyzer actually checks Since annotations at all.

The original bug which made us introduce Since was #34978
It's not closed yet, but that can mean anything for such an old and forgotten bug.
(The Future/Stream exported by dart:core is probably special-cased, the error message seems far too specific.)

[bsutton]

So assuming the analyser doesn't support since, it sounds like full implementation may be some way down the path.

So I would like to suggest placing some interim help in place in the way of the suggested warning.

Pub publish and test seen logical places.

If the current sdk doesn't match the pubspec min we issue at least a warning and preferably an error with a possible switch to ignore the error.

Leaving things as they are feels problematic.

[jakemac53]

cc @bwilkerson can you clarify about @Since possibly? Is that intended to be supported? Should this change to a feature request?

[bwilkerson]

Looking briefly at the code base, it does not appear that there is any support in the analyzer for the @since annotation (if there is it isn't implemented the way other checks are implemented). As far as I'm aware, the analyzer is the correct place to implement such checks, and yes, the analyzer is intended to support checking for all of the annotations in both the SDK libraries and package:meta. I don't know whether that makes this a feature request or a bug.

Adding a check is a fairly small amount of work, but I can't speak to when it will be implemented by the analyzer team. Of course, contributions are always welcome.

[jakemac53]

Ok, I am going to go ahead and just close this issue then, in favor of #34978