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

use cbuilder for most braced initializers #24259

Merged
merged 3 commits into from
Oct 13, 2024

Conversation

metagn
Copy link
Collaborator

@metagn metagn commented Oct 8, 2024

StructInitializer is now used for most braced initializers in the C generation, mostly in genBracedInit, getNullValueAux, getDefaultValue. The exceptions are:

  • the default case branch initializer for objects uses C99 designated initializers with field names, which are not implemented for StructInitializer yet (siNamedStruct)
  • the uses in ccgliterals are untouched so all of ccgliterals can be done separately and in 1 go

There is one case where genBracedInit does not use cbuilder, which is the global literal variable for openarrays. The reason for this is simply that variables with C array type are not implemented, which I thought would be best to leave out of this PR.

For the simplicity of the implementation, code in getNullValueAuxT that reset the initializer back to its initial state if the Sup field did not have any fields itself, is now disabled. This was so the compiler does not generate {} for the Sup field, i.e. {{}}, but every call to getNullValueAuxT still generates {} if the struct doesn't have any fields, so I don't know if it really breaks anything. The case where the Sup field doesn't have any fields but the struct does also would have generated {{}, field}.

Worst case, we can implement either the "resetting" or just disable the generation of the Sup field if there are no fields total. But a better fix might be to always generate {0} if the struct has no fields, in line with the char dummy field that gets added for all objects with no fields. This doesn't seem necessary for now but might be for the NIFC output, in which case we can probably keep the logic contained inside cbuilder (if no fields generated for siOrderedStruct/siNamedStruct, we add a 0 for the dummy field). This would stipulate that all uses of struct initializers are exhaustive for every field in structs.

@Araq Araq merged commit 07628b0 into nim-lang:devel Oct 13, 2024
19 checks passed
Copy link
Contributor

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 07628b0

Hint: mm: orc; opt: speed; options: -d:release
175209 lines; 8.420s; 655.324MiB peakmem

metagn added a commit to metagn/Nim that referenced this pull request Oct 13, 2024
Araq pushed a commit that referenced this pull request Oct 14, 2024
follows up #24259 

This was the only use of the `STRING_LITERAL` macro in `nimbase.h`, so
this macro is now removed. We don't have to remove it though, maybe
people use it.
metagn added a commit to metagn/Nim that referenced this pull request Oct 15, 2024
Araq pushed a commit that referenced this pull request Oct 16, 2024
…ces (#24312)

follows up #24259

This is the remaining missing use of `StructInitializer` in
`getDefaultValue` after #24259 and #24302. The only remaining direct C
code in getDefaultValue is [this
line](https://github.com/nim-lang/Nim/blob/922f7dfd712130bb68a16336085c0320afceb273/compiler/ccgexprs.nim#L3525)
which creates a global array variable, which isn't implemented yet. Next
steps would be all remaining variable and `typedef` declarations, then
hopefully we can move on to general statements and expressions.
Araq pushed a commit that referenced this pull request Oct 18, 2024
The remaining followup from #24259. A body for building the type doesn't
seem necessary here since the types with array fields are generally
atomic/already built from `getTypeDescAux`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants