Comments (5)
I guess approach four is, do nothing, and let authors figure it out when they get a compile error. While I think we could be a little more helpful (it’s not immediately obvious to make the connection from an error in codegen to “oh, right, I can’t name this argument func
in Swift” or “hmmm, it doesn’t like my Lowerable
type, I guess there’s already a helper that defines one”), our target languages do have good compiler errors.
from uniffi-rs.
Approach 1 seems totally fine to me. Its not like these names are very likely to cause collisions, but it would be good to give good error messages in the very unlikely case that collisions happen.
I think if it could piggyback off of whatever approach is used to complain about using other reserved words that would be good.
prefix or suffix internal stuff (and reserved words!) with _
Note that if we do this for C it's a problem, all symbols beginning with _ in the global namespace are reserved IIRC (and all symbols that are _ followed by a capital in any namespace, including local vars, are reserved).
That said suffix is probably fine so long as it doesn't have __
, which is also reserved in all namespaces.
from uniffi-rs.
That said suffix is probably fine so long as it doesn't have __, which is also reserved in all namespaces.
It occurs to me that we should probably error for this too if a user symbol in rust has it after our transformations. I'd rather not invent our own mangling scheme to solve these (although in principal it would probably work), so I think we'll probably need a function that validates that an identifier is valid to expose.
from uniffi-rs.
I think if it could piggyback off of whatever approach is used to complain about using other reserved words that would be good.
Such a thing doesn't really exist yet, but 100% should and definitely sounds like the right place to do these checks..!
from uniffi-rs.
Approach 3.1: prefix or suffix internal stuff (and reserved words!) with _. Also easy, and probably good enough!
In my head, I think I was more-or-less intending to take this approach, but @thomcc raises a good point about it conflicting with other naming conventions.
Another option I was thinking about, which makes more sense in some target languages than others, was to actually move all of those helpers out of the public classes themselves. Strawman: if we expose a record name Point
as a class, then the only methods on that class are the ones defined by the component. Internally, we have a separate helper class named _Uniffi_PointRecord
on which we define the helpers like lift
, lower
, etc. Instead of calling p.lower()
, the generated code would call _Uniffi_PointRecord.lower(p)
.
This would keep the exported namespaces nice and clean, but might make the generated code much messier and harder to debug. It might also show up as visible artifacts when using the public interface, such as confusing lines in your tracebacks.
Starting with Approach One (the blanket ban) seems like the right move I think, since it's easier to loosen restrictions in future then to tighten them.
Unconditionally append a random, short ID to internal symbols. [...] though we can make the scheme predictable—again,
borrowing from how name mangling works in other languages).
Unrelated to the public API surface, I was wondering whether we should try something like this as a safety measure for the extern C
layer:
- Predictably generate a "tag" for every item in the FFI layer, perhaps as a hash of its components in the IDL. It would be important for this value to be a deterministic function of the IDL.
- Append this tag to all symbols exported from the dylib, so that e.g. the
fxa_new
function becomesfxa_new_1234
. - Have both sides of the FFI expect to find the exported symbols under their tagged names.
That's a bit of extra complexity in the generated bindings, but it would help prevent accidentally using the Kotlin bindings from version X or a component with the dylib from version Y; it wouldn't even be able to load the dylib successfully because all the symbol names would be different!
from uniffi-rs.
Related Issues (20)
- `RustCallStatus::error_buf` should be `ManuallyDrop`, not `MaybeUninit`?
- Add implemented traits to generated code, or add extension? HOT 2
- [Swift] Would it be possible to use checked exceptions? HOT 6
- Only invoke cargo metadata for desired targets HOT 7
- Add a conversion pass before rendering the bindings templates HOT 3
- How to get Rust panic backtrace?
- Swift classes are not generated properly with their Protocol as Generic Type HOT 2
- Interface/Protocol use in foreign generated code HOT 4
- FR: Optionally disable exception catching in foreign trait code
- Tell the bindings about traits implemented by objects.
- Allow trait interfaces without a Send + Sync bound
- Undefined features `log_panics` and `log_backtraces` HOT 1
- How to implement builder pattern using uniffi? HOT 6
- Uniffi ForeignFuture inconsistenty dropped HOT 10
- Add tracing to FFI calls
- Make it possible to rename structs HOT 8
- ld: building for 'macOS', but linking in object file built for 'iOS' HOT 1
- Change introduced in v0.28.1 breaks cargo-swift
- swift: record: drop explicit implementation of Equatable and Hashable?
- Async runtime for function binding defined in UDL file HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uniffi-rs.