ruby.git/bootstraptest/test_syntax.rb, branch v3_4_9 The Ruby Programming Language Skip flaky RJIT tests 2024-06-03T23:50:43+00:00 Takashi Kokubun takashikkbn@gmail.com 2024-06-03T23:50:42+00:00 e7e83a313c6aac9d57e17a021c24a9c8e2167cca https://github.com/ruby/ruby/actions/runs/9352283948/job/25740049841 https://github.com/ruby/ruby/actions/runs/9350872852/job/25735280811 Not a high priority to fix right now, so skipping until we get to fix it. 
https://github.com/ruby/ruby/actions/runs/9352283948/job/25740049841
https://github.com/ruby/ruby/actions/runs/9350872852/job/25735280811

Not a high priority to fix right now, so skipping until we get to fix
it.
[PRISM] Fix up syntax error message parsing in btests 2024-04-03T21:34:12+00:00 Kevin Newton kddnewton@gmail.com 2024-04-03T18:54:50+00:00 ffba484754bd5bed0f7c69646291fd99ed8959cc 






[PRISM] Include file and line in error message
2024-03-27T18:19:58+00:00

Kevin Newton
kddnewton@gmail.com

2024-03-27T17:37:01+00:00

eb995a64108d18fb809f02fa90e085f843ae4309












Refactor frozen_string_literal check during compilation
2024-03-15T14:52:33+00:00

Jean Boussier
byroot@ruby-lang.org

2024-03-15T11:38:39+00:00

91bf7eb274e0b6e431b4f89a6dc814701a4d8739

In preparation for https://bugs.ruby-lang.org/issues/20205.

The `frozen_string_literal` compilation option will no longer
be a boolean but a tri-state: `on/off/default`.





In preparation for https://bugs.ruby-lang.org/issues/20205.

The `frozen_string_literal` compilation option will no longer
be a boolean but a tri-state: `on/off/default`.







Ensure test suite is compatible with --frozen-string-literal
2024-03-14T16:56:15+00:00

Jean Boussier
byroot@ruby-lang.org

2024-03-13T11:50:11+00:00

09d8c99cdcb04fb6c6c8e61c9dea28927a3a0b46

As preparation for https://bugs.ruby-lang.org/issues/20205
making sure the test suite is compatible with frozen string
literals is making things easier.





As preparation for https://bugs.ruby-lang.org/issues/20205
making sure the test suite is compatible with frozen string
literals is making things easier.







Do not include a backtick in error messages and backtraces
2024-02-15T09:42:31+00:00

Yusuke Endoh
mame@ruby-lang.org

2024-01-19T07:03:38+00:00

25d74b9527cd525042ad0b612b794fa331d3a318

[Feature #16495]





[Feature #16495]







[PRISM] Switch bootstraptest syntax error assertions to handle multiline
2024-02-14T02:19:12+00:00

Kevin Newton
kddnewton@gmail.com

2024-02-14T01:00:58+00:00

8ec955d1f53b96c99cf85fda8f5153e9e0ec9ba1












[Bug #19882] Reject tokens invalid as symbols
2023-09-15T08:27:36+00:00

Nobuyoshi Nakada
nobu@ruby-lang.org

2023-09-15T06:39:58+00:00

89802078f9f406be411032814e1960e62dbc7ce2












btest: assign $stderr = STDOUT instead of IO#reopen to be more portable
2021-12-16T07:16:40+00:00

Yuta Saito
kateinoigakukun@gmail.com

2021-12-13T07:48:57+00:00

332d1e52e62735ff16e5fb9207ce86695369555d

`IO#reopen` internally uses dup syscall but some platforms don't support
the syscall. re-assigning `$stderr` is enough to capture the interpreter's
errors and warnings.





`IO#reopen` internally uses dup syscall but some platforms don't support
the syscall. re-assigning `$stderr` is enough to capture the interpreter's
errors and warnings.







Turn class variable warnings into exceptions
2020-04-10T07:29:05+00:00

Jeremy Evans
code@jeremyevans.net

2020-03-27T22:08:52+00:00

900e83b50115afda3f79712310e4cb95e4508972

This changes the following warnings:

* warning: class variable access from toplevel
* warning: class variable @foo of D is overtaken by C

into RuntimeErrors.  Handle defined?(@@foo) at toplevel
by returning nil instead of raising an exception (the previous
behavior warned before returning nil when defined? was used).

Refactor the specs to avoid the warnings even in older versions.
The specs were checking for the warnings, but the purpose of
the related specs as evidenced from their description is to
test for behavior, not for warnings.

Fixes [Bug #14541]





This changes the following warnings:

* warning: class variable access from toplevel
* warning: class variable @foo of D is overtaken by C

into RuntimeErrors.  Handle defined?(@@foo) at toplevel
by returning nil instead of raising an exception (the previous
behavior warned before returning nil when defined? was used).

Refactor the specs to avoid the warnings even in older versions.
The specs were checking for the warnings, but the purpose of
the related specs as evidenced from their description is to
test for behavior, not for warnings.

Fixes [Bug #14541]