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

type_annotate_public_apis reports issues over local non-API functions #1108

Closed
chalin opened this issue Aug 3, 2018 · 8 comments
Closed
Labels
false-positive type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@chalin
Copy link
Contributor

chalin commented Aug 3, 2018

Consider the local good() function declared in this test:

test('foo', () {
  good() { ... }
  expect(good, ...);
});

The type_annotate_public_apis lint causes this issue to be reported:

lint • Type annotate public APIs at test/effective_dart_test.dart:28:7 • type_annotate_public_apis

Being a local function, good() should not be considered in this lint.

cc @munificent @kevmoo

@kevmoo
Copy link
Member

kevmoo commented Aug 3, 2018 via email

@pq pq added false-positive type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) labels Aug 7, 2018
@pq
Copy link
Member

pq commented Aug 7, 2018

+1.

Good catch!

@srawlins
Copy link
Member

Ouch, also methods of private classes.

class _C {
  m() {} // BAD LINT
}

@chalin
Copy link
Contributor Author

chalin commented Jan 3, 2019

Can you add a comment here once this is released publicly?

@srawlins
Copy link
Member

srawlins commented Jan 3, 2019

I can't promise that. I wish there was a bot for such things.

@pq
Copy link
Member

pq commented Jan 3, 2019

@chalin, @srawlins: I'm curious if you have any thoughts on how we could do better at documenting and publicizing releases. I'm very open to a bot actually if we could decide what exactly it should do.

One thing that occurs to me right away is that the published lint docs reflect HEAD but there's no easy way to see what is defined in a particular SDK. I don't want to clutter the docs w/ badges but maybe something could be done?

image

For example, what if we added an SDK badge w/ the number of the minimum supporting SDK?

@kevmoo
Copy link
Member

kevmoo commented Jan 3, 2019

what if we added an SDK badge w/ the number of the minimum supporting SDK?

❤️ ❤️ ❤️

@srawlins
Copy link
Member

srawlins commented Jan 3, 2019

+10, love that idea. Would be very simple to implement with a String API on each rule.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
false-positive type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

4 participants