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.

Sign up for GitHub

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

Jump to bottom

Audit all exposed APIs to determine if they should actually be private #234

Open
AntonyBlakey opened this issue Dec 14, 2022 · 0 comments
Open

Audit all exposed APIs to determine if they should actually be private #234

AntonyBlakey opened this issue Dec 14, 2022 · 0 comments
Assignees
@OmarTawfik

Comments

@AntonyBlakey
Copy link
Contributor

AntonyBlakey commented Dec 14, 2022 •
edited by OmarTawfik
Loading

Can we generate (and check in/source version) them?

Example snapshot from Kotlin: https://github.com/ktorio/ktor/blob/58f2fa99c24a861e943bf686c6a6b31c6c9dbf7b/ktor-http/api/ktor-http.api

Questions

  • Is it possible to get rid of allow(unused_imports) in the codebase? It is a good way to make sure that any publicly exposed APIs are covered with at least one simple/basic test.
  • Should we review instances of clippy::must_use_candidate (which we currently disable globally)?
  • Can NAPI-exposed properties be turned readonly? they are mutable by default.
@AntonyBlakey AntonyBlakey added this to the 2️⃣ Beta Preview milestone Dec 14, 2022
@AntonyBlakey AntonyBlakey self-assigned this Dec 14, 2022
@AntonyBlakey AntonyBlakey changed the title Audit all exposed APIs to dtermine if they should actually be private Audit all exposed APIs to determine if they should actually be private Dec 20, 2022
@AntonyBlakey AntonyBlakey mentioned this issue Mar 13, 2023
Merged
@OmarTawfik OmarTawfik self-assigned this Jul 10, 2023
@OmarTawfik OmarTawfik removed this from the 2️⃣ Beta Preview milestone Jul 11, 2023
@OmarTawfik OmarTawfik mentioned this issue Jul 19, 2023
Closed
@OmarTawfik OmarTawfik removed their assignment Jul 19, 2023
@Xanewok Xanewok mentioned this issue Aug 3, 2023
Merged
github-merge-queue bot pushed a commit that referenced this issue Aug 10, 2023
@Xanewok
Drive-by tweaks and docs (#561)
cb6a138 
Not touching the grammar definition-related code since that's about to
be changed by
https://github.com/AntonyBlakey/slang/tree/AntonyBlakey/to_rust_types.

Somewhat related to #234,
I noticed that we have public extension traits that seem to only work
with the `LanguageDefinition` type. Maybe we should change these
one-function traits to free functions that accept the language
definition as the argument, instead?

Also not feeling strongly about
84912e8,
thought it's more of a nice-to-have.
@OmarTawfik OmarTawfik self-assigned this May 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@OmarTawfik OmarTawfik

Labels
None yet
Projects
Slang - 2024 H1
Status: ⏳ Todo
Milestone
No milestone
Development

No branches or pull requests
2 participants
@AntonyBlakey @OmarTawfik