libexpr: hook up bison destructors for state objects
this doesn't help much yet since the state objects themselves also leak all memory they are given, but it is a first necessary step to properly managing parser memory. notably we have to clear $$ when returning from the parser since even the start symbol is subject to automatic deletion by the bison-generated parser before returning control to the call site Change-Id: I80245b0c747308e80923e7f18ce4e1a4898f93b0
This commit is contained in:
parent
19a93dd025
commit
9592a9fd57
1 changed files with 15 additions and 2 deletions
|
@ -59,6 +59,8 @@ using namespace nix;
|
|||
|
||||
#define CUR_POS state->at(*yylocp)
|
||||
|
||||
// otherwise destructors cause compiler errors
|
||||
#pragma GCC diagnostic ignored "-Wswitch-enum"
|
||||
|
||||
void yyerror(YYLTYPE * loc, yyscan_t scanner, ParserState * state, const char * error)
|
||||
{
|
||||
|
@ -94,7 +96,18 @@ void yyerror(YYLTYPE * loc, yyscan_t scanner, ParserState * state, const char *
|
|||
std::vector<std::pair<nix::PosIdx, std::variant<nix::Expr *, nix::StringToken>>> * ind_string_parts;
|
||||
}
|
||||
|
||||
%type <e> start expr expr_function expr_if expr_op
|
||||
%destructor { delete $$; } <e>
|
||||
%destructor { delete $$; } <list>
|
||||
%destructor { delete $$; } <attrs>
|
||||
%destructor { delete $$; } <formals>
|
||||
%destructor { delete $$; } <formal>
|
||||
%destructor { delete $$; } <attrNames>
|
||||
%destructor { delete $$; } <inheritAttrs>
|
||||
%destructor { delete $$; } <string_parts>
|
||||
%destructor { delete $$; } <ind_string_parts>
|
||||
|
||||
%type <e> start
|
||||
%type <e> expr expr_function expr_if expr_op
|
||||
%type <e> expr_select expr_simple expr_app
|
||||
%type <list> expr_list
|
||||
%type <attrs> binds
|
||||
|
@ -132,7 +145,7 @@ void yyerror(YYLTYPE * loc, yyscan_t scanner, ParserState * state, const char *
|
|||
|
||||
%%
|
||||
|
||||
start: expr { state->result = $1; };
|
||||
start: expr { state->result = $1; $$ = 0; };
|
||||
|
||||
expr: expr_function;
|
||||
|
||||
|
|
Loading…
Reference in a new issue