ml.ruby-lang.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

ruby-core

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
ruby-core@ml.ruby-lang.org

June 2026

  • 4 participants
  • 94 discussions
[ruby-core:125562] [Ruby Bug#22078] mswin: `gmp.h` not found with `--with-opt-dir` on Ruby 3.3/3.4
by hsbt (Hiroshi SHIBATA) 02 Jun '26

02 Jun '26
Issue #22078 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22078: mswin: `gmp.h` not found with `--with-opt-dir` on Ruby 3.3/3.4 https://bugs.ruby-lang.org/issues/22078 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: DONTNEED ---------------------------------------- On mswin builds, `win32/Makefile.sub` builds `XCFLAGS` without `XINCFLAGS`, so the include path written by `configure.bat --with-opt-dir=...` never reaches `cl.exe` and `#include <gmp.h>` cannot be resolved. `master` and `ruby_4_0` are fixed by https://github.com/ruby/ruby/commit/13c64a8a20, but neither `ruby_3_4` nor `ruby_3_3` has it. How it surfaces differs between the two: - `ruby_3_4`: `win32/setup.mak` auto-enables GMP whenever gmp is present, so the build tries to use it and fails on the missing `gmp.h`. - `ruby_3_3`: `win32/setup.mak` only enables GMP when `--with-gmp` is explicitly passed. Without the flag the build passes but GMP is never used; with the flag, it fails the same way as 3.4. -- https://bugs.ruby-lang.org/
1 1
0 0
[ruby-core:125602] [Ruby Bug#22089] Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects
by kddnewton (Kevin Newton) 01 Jun '26

01 Jun '26
Issue #22089 has been updated by kddnewton (Kevin Newton). Status changed from Open to Closed Closed by 9e8ad9ac0489d8390bc11e5b18f4af065d60898c ---------------------------------------- Bug #22089: Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects https://bugs.ruby-lang.org/issues/22089#change-117449 * Author: Anonymous * Status: Closed * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following is accepted by Prism but rejected by parse.y: ``` $ ruby -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] Syntax OK $ ruby --parser=parse.y -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) [arm64-darwin25] -e:1: syntax error, unexpected 'if' modifier, expecting 'then' or '\n' or ';' if a if b then end ^~ ruby: compile error (SyntaxError) ``` The same applies to other statement modifiers (`unless`/`while`/`until`) and to `unless`/`elsif` conditions. For example, all of the following are accepted by Prism but rejected by parse.y: ```ruby if a if b then end if a unless b then end if a while b then end if a until b then end unless a until b then end if x then elsif a if b then end ``` I can also reproduce this on Prism's main branch (1.9.0). Prism already treats the same syntax as a syntax error in `while`/`until` conditions, so it looks like `if`/`unless`/`elsif` conditions should reject it as well, matching both parse.y and Prism's own handling of `while`/`until` conditions. I have a draft patch here: https://github.com/ruby/prism/pull/4120 -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-core:125600] [Ruby Bug#22089] Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects
by Kai (kai matsudate) 01 Jun '26

01 Jun '26
Issue #22089 has been updated by Kai (kai matsudate). I'm the reporter. It shows as anonymous due to recreating my account, but I'm following this. ---------------------------------------- Bug #22089: Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects https://bugs.ruby-lang.org/issues/22089#change-117442 * Author: Anonymous * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following is accepted by Prism but rejected by parse.y: ``` $ ruby -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] Syntax OK $ ruby --parser=parse.y -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) [arm64-darwin25] -e:1: syntax error, unexpected 'if' modifier, expecting 'then' or '\n' or ';' if a if b then end ^~ ruby: compile error (SyntaxError) ``` The same applies to other statement modifiers (`unless`/`while`/`until`) and to `unless`/`elsif` conditions. For example, all of the following are accepted by Prism but rejected by parse.y: ```ruby if a if b then end if a unless b then end if a while b then end if a until b then end unless a until b then end if x then elsif a if b then end ``` I can also reproduce this on Prism's main branch (1.9.0). Prism already treats the same syntax as a syntax error in `while`/`until` conditions, so it looks like `if`/`unless`/`elsif` conditions should reject it as well, matching both parse.y and Prism's own handling of `while`/`until` conditions. I have a draft patch here: https://github.com/ruby/prism/pull/4120 -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-core:125599] [Ruby Bug#22089] Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects
by Impotency6272 (kai matsudate) 01 Jun '26

01 Jun '26
Issue #22089 has been reported by Impotency6272 (kai matsudate). ---------------------------------------- Bug #22089: Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects https://bugs.ruby-lang.org/issues/22089 * Author: Impotency6272 (kai matsudate) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following is accepted by Prism but rejected by parse.y: ``` $ ruby -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] Syntax OK $ ruby --parser=parse.y -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) [arm64-darwin25] -e:1: syntax error, unexpected 'if' modifier, expecting 'then' or '\n' or ';' if a if b then end ^~ ruby: compile error (SyntaxError) ``` The same applies to other statement modifiers (`unless`/`while`/`until`) and to `unless`/`elsif` conditions. For example, all of the following are accepted by Prism but rejected by parse.y: ```ruby if a if b then end if a unless b then end if a while b then end if a until b then end unless a until b then end if x then elsif a if b then end ``` I can also reproduce this on Prism's main branch (1.9.0). Prism already treats the same syntax as a syntax error in `while`/`until` conditions, so it looks like `if`/`unless`/`elsif` conditions should reject it as well, matching both parse.y and Prism's own handling of `while`/`until` conditions. I have a draft patch here: https://github.com/ruby/prism/pull/4120 -- https://bugs.ruby-lang.org/
1 0
0 0
  • ← Newer
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.