I was hoping to add another option to --parser which would be --parser=prism_without_warning. The issue is that it's making it hard to run the tests/specs that test against the output of stderr. This would do the exact same thing as --parser=prism it just wouldn't warn. (The name is derived from --dump=insns_without_opt, but I'm okay with anything.
Do you have an example? That could help to clarify the need for this.
Is it problematic to modify these tests/specs to accept Prism warnings too? I think that would be best (since it would be needed longer-term anyway).
For compatibility, --parser=prism should at some point pass the test suite and specs, so that will mean some modifications to expected warning/parse errors.
I think you misunderstood what I'm asking for. Right now CRuby warns with:
The compiler based on the Prism parser is currently experimental and compatibility with the compiler based on parse.y is not yet complete. Please report any issues you find on the `ruby/prism` issue tracker.
when you pass --parser=prism. I'm specifically asking to turn this off with --parser=prism_without_warning. I'm not asking to change the warning messages within Ruby itself.
The specs assert against the output of stderr, which means if this warning gets emitted, a lot of them fail. Specifically there are 70 specs that fail when this warning is present. In order to run the spec suite, I am currently manually commenting this out and recompiling.
Oh right, that makes a lot more sense.
I wonder if it could be a configure flag or so to disable that warning, until it's stable enough to remove the warning entirely.
@mame (Yusuke Endoh) would you mind reviewing? I had to add rb_warning_category_update(opt->warn.mask, opt->warn.set); when the -W option is passed because it needs to get updated before ruby_opt_init is called in order to properly track the state of the warning category. I hope that's okay.