-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Merging forward declarations #3762
Merging forward declarations #3762
Conversation
bf55cb9
to
946c340
Compare
b70a45b
to
98a6779
Compare
ae102c1
to
e321f14
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is our story for coherence in the presence of extern
declarations, in particular extern
type and interface declarations?
The best answer I can think of off the top of my head is that an impl
lookup that involves an extern
declaration in any way is invalid -- but that will have some serious implications if we define function calls in terms of impl
lookup!
@josh11b Is this a problem that you've considered previously?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass of comments.
@zygoloid We can't use an There is an issue with
We have these two ingredients in the case of an
This requires agreement of the whole overload set between the library that defines it and the |
507e7ff
to
ad5afce
Compare
Co-authored-by: Chandler Carruth <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the comments!
@jonmeow I talked with @zygoloid yesterday, and I think we ended up in a position in between our original statements:
Bottom line, I think we should include some statement about
It might be good to include the |
d5dc7fe
to
a6973f9
Compare
a6973f9
to
7808d5f
Compare
4cac1da
to
a5c0501
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm largely happy here, but would like @zygoloid to take a look as well before it goes in. Happy for it to merge when it LG to him as well.
0fed7ed
to
6553478
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks. A few nuances, but nothing major.
6553478
to
f081368
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy for this to go forward as-is. Please feel free to merge.
I'd also be happy to add a restriction on forward-declaring an entity in an impl
file if it's also forward-declared in the api
file. I don't see a need for that to be in this proposal, but I'm not hitting the merge button in case you would like to add that rule here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, forgot to publish responses
5369fb9
to
d4a7cda
Compare
…ions. (#3843) Adds ImportIRId::ApiForImpl to reserve a specific slot for the `api` import, so that the code can trivially determine whether an import is from the same library. This is then used for merging function declarations, because the rules for redeclarations in the same library slightly differ as compared to other imports (note they're also not identical to same-file rules). The main thing this leaves from the recent #3762 is verifying that entities forward declared in the `impl` file are also defined, but that's not in-scope for merging; it's moreso post-checking validation. Note, a lot of our `invalid <entity> ID` comments in ids.h were incorrectly copy-pasted, so I've cut `<entity>`.
Trying to pull in key elements of #3762, #3763, and #3980 (decl matching and `extern`, essentially). These aren't specific to any particular declaration type, but are common to entities, so suggesting a new doc oriented on that. There's probably more that could be said here, I'm just focused on getting the recent formal discussion mirrored into the design. --------- Co-authored-by: josh11b <[email protected]>
extern
keyword for forward declarations in libraries that don'tprovide the definition.
and definitions.