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

Create a Generic object to represent a generic. #4081

Merged
merged 11 commits into from
Jun 26, 2024

Conversation

zygoloid
Copy link
Contributor

@zygoloid zygoloid commented Jun 26, 2024

Build a Generic object for generic functions. This object tracks the generic parameters that are in scope for the generic entity. Eventually it will track other information about the generic too.

Add basic SemIR formatting support for generic functions.

Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these changes make sense, but I'd like to confirm whether "Generic" includes template generics.

@@ -208,6 +211,9 @@ class File : public Printable<File> {
// Storage for impls.
ImplStore impls_;

// Storage for generics.
ValueStore<GenericId> generics_;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be printed as part of the yaml IR?

Maybe we should evaluate getting rid of the yaml given it's not really well maintained, since it's not well tested?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added to YAML output.

Comment on lines +12 to +13
// Information for a generic entity, such as a generic class, a generic
// interface, or generic function.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you say generic, do you mean both checked generics and template generics, or just checked generics? I think we should be precise here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean all generics -- the post-#2138 terminology. I've added to this comment to remind the reader of our terminology choice here.

// The first declaration of the generic entity.
InstId decl_id;
// A block containing the IDs of compile time bindings in this generic scope.
// The index in this block will match the `bind_index` of the instruction.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little uncertain here, we only have bind_index on BindNameInfo, is that what you mean here?

Suggested change
// The index in this block will match the `bind_index` of the instruction.
// In this block, each instruction's index will match its BindNameInfo's
// `bind_index`.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@@ -210,6 +224,8 @@ struct ScopeStack::SuspendedScope {
// to keep the size of a `SuspendedFunction` reasonable while avoiding heap
// allocations most of the time.
llvm::SmallVector<LexicalLookup::SuspendedResult, 8> suspended_lookups;
// The compile-time bindings that were introduced in this scope.
llvm::SmallVector<SemIR::InstId, 8> compile_time_bindings;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 8? There's a comment on suspended_lookups, but it doesn't clearly apply to this member.

If this is because we expect it to be 1:1 (or thereabout) with LexicalLookup::SuspendedResult, could they be combined? In part, I think there's a benefit to avoiding an additional vector if they're expected to be similar size; for things with a few parameters, even with no compile time bindings, it'll be smaller or equivalent just because of vector overhead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, we could almost avoid storing the compile time bindings entirely, but the list of bindings and the list of lookups can be out of sync due to error recovery. For

fn F(T:! type, T:! type)

we have two compile-time bindings but only one lookup result. I've combined these into a single vector as suggested.

if (result.entry.scope_id.is_valid()) {
non_lexical_scope_stack_.pop_back();
}
for (auto name_id : result.entry.names) {
result.suspended_lookups.push_back(lexical_lookup_.Suspend(name_id));
}
// Move any compile-time bindings into the suspended scope.
{
Copy link
Contributor

@jonmeow jonmeow Jun 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, this extra scope mostly reads weird to me -- you might consider blank lines to separate logic (instead). The separation of the comment is also an odd result.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@zygoloid zygoloid requested a review from jonmeow June 26, 2024 19:24
Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@zygoloid zygoloid added this pull request to the merge queue Jun 26, 2024
Merged via the queue into carbon-language:trunk with commit e7b0529 Jun 26, 2024
7 checks passed
@zygoloid zygoloid deleted the toolchain-generic-1 branch June 26, 2024 20:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants