-
Notifications
You must be signed in to change notification settings - Fork 89
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
More noexcept #80
Comments
Suggested by Don Macpherson. <#80> * data/skeletons/c++.m4, data/skeletons/glr2.cc, * data/skeletons/lalr1.cc, data/skeletons/stack.hh: Use YY_NOEXCEPT where it helps constructors.
Hi Don, Cheers! |
Hi Akim,
Yes, these are part of the warnings issued by MSVC.
Currently, I am using VS 2022 preview, but these warnings should be
visible in released versions.
I haven't set up a mechanism to create pull requests/standard diffs yet.
Although it is common(?) for gcc users to unconditionally turn off
exceptions when compiling, it is probably not so much in the Microsoft
world, so the noexcepts can help code generation.
I can post to bison-patches, but that mailing list appeared to be expecting
diff type submissions.
Thanks,
Don
…On Sat, 18 Sept 2021 at 16:19, Akim Demaille ***@***.***> wrote:
Hi Don,
What do you think about this patch? I suppose you used some compiler
warning to get these places?
Please, prefer ***@***.*** You've been lucky I saw your issue
so soon (I came to check an issue I did not see for months).
Cheers!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#80 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG2XUCP2YJ33KDPFQJWFDW3UCQVNRANCNFSM5EIYXS6Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
There is no strong rule. Using bug-bison@gnu.org would have been more appropriate, indeed, but it's quite customary to discuss evolutions on bison-patches. Even if not as a diff. Cheers! |
Installed in master. |
Hi,
The following lines should have YY_NOEXCEPT as shown below
c++.m4: line 311
basic_symbol () YY_NOEXCEPT
c++.m4: line 493
symbol_type () TT_NOEXCEPT {}
lalr1.cc: line 477
void yypop_ (int n = 1) YY_NOEXCEPT;
lalr1.cc : line 782
]b4_parser_class[::yypop_ (int n) YY_NOEXCEPT
lalr1.cc; line 324
static state_type yy_lr_goto_state_ (state_type yystate, int yysym) YY_NOEXCEPT;
lalr1.cc: line 815
]b4_parser_class[::yy_lr_goto_state_ (state_type yystate, int yysym) YY_NOEXCEPT
lalr1.cc: line 328
static bool yy_pact_value_is_default_ (int yyvalue) YY_NOEXCEPT;
lalr1.cc: line 825
]b4_parser_class[::yy_pact_value_is_default_ (int yyvalue) YY_NOEXCEPT
lalr1.cc: line 332
static bool yy_table_value_is_error_ (int yyvalue) YY_NOEXCEPT;
lalr1.cc: line 831
]b4_parser_class[::yy_table_value_is_error_ (int yyvalue) YY_NOEXCEPT
c++.m4: line 441
by_kind () YY_NOEXCEPT;
c++.m4: line 449
by_kind (const by_kind& that) YY_NOEXCEPT;
c++.m4: line 463
by_kind (kind_type t) YY_NOEXCEPT;
c++.m4: line 567
]b4_inline([$1])b4_parser_class[::by_kind::by_kind () YY_NOEXCEPT
c++.m4: line 579
]b4_inline([$1])b4_parser_class[::by_kind::by_kind (const by_kind& that) YY_NOEXCEPT
c++.m4: line 583
]b4_inline([$1])b4_parser_class[::by_kind::by_kind (token_kind_type t)
c++.m4: line 646
]b4_parser_class[::yytranslate_ (int t) YY_NOEXCEPT
lalr1.cc: line 340
static symbol_kind_type yytranslate_ (int t) YY_NOEXCEPT;
stack.hh: line 40
stack (size_type n = 200) YY_NOEXCEPT
stack.hh: line 119
slice (const stack& stack, index_type range) YY_NOEXCEPT
The text was updated successfully, but these errors were encountered: