[#113107] [Ruby master Bug#19576] Backport request: Gemfile.lock resolving is broken with bundler shipped with Ruby 3.1.4 — "jprokop (Jarek Prokop) via ruby-core" <ruby-core@...>

Issue #19576 has been reported by jprokop (Jarek Prokop).

8 messages 2023/04/04

[#113112] [Ruby master Bug#19578] abort() shows stack trace when run within rescue clause — "Dan0042 (Daniel DeLorme) via ruby-core" <ruby-core@...>

Issue #19578 has been reported by Dan0042 (Daniel DeLorme).

8 messages 2023/04/04

[#113180] [Ruby master Feature#19588] Allow Comparable#clamp(min, max) to accept nil as a specification — "kyanagi (Kouhei Yanagita) via ruby-core" <ruby-core@...>

Issue #19588 has been reported by kyanagi (Kouhei Yanagita).

7 messages 2023/04/11

[#113209] [Ruby master Bug#19596] Decreased performance after upgrading from ruby 2.7.2 to ruby 3.2.2 — silva96 via ruby-core <ruby-core@...>

Issue #19596 has been reported by silva96 (Benjam=EDn Silva).

7 messages 2023/04/13

[#113238] [Ruby master Misc#19599] DevMeeting-2023-05-10 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #19599 has been reported by mame (Yusuke Endoh).

14 messages 2023/04/14

[#113285] [Ruby master Bug#19607] Introduce `Hash#symbolize_keys`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>

Issue #19607 has been reported by ioquatix (Samuel Williams).

8 messages 2023/04/18

[#113303] [Ruby master Feature#19610] GC.delay_promotion — "peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>

Issue #19610 has been reported by peterzhu2118 (Peter Zhu).

9 messages 2023/04/20

[#113313] [Ruby master Bug#19613] Add version information to all function documentation — "fulldecent (William Entriken) via ruby-core" <ruby-core@...>

Issue #19613 has been reported by fulldecent (William Entriken).

7 messages 2023/04/23

[#113342] [Ruby master Feature#19617] Add Method#binding and UnboundMethod#binding, similar to Proc#binding — "nevans (Nicholas Evans) via ruby-core" <ruby-core@...>

Issue #19617 has been reported by nevans (Nicholas Evans).

9 messages 2023/04/25

[#113381] [Ruby master Bug#19624] Backticks - IO object leakage — pineman via ruby-core <ruby-core@...>

Issue #19624 has been reported by pineman (Jo=E3o Pinheiro).

10 messages 2023/04/30

[ruby-core:113101] [Ruby master Feature#19545] lp/hp logic parsing inconsistency

From: "jeremyevans0 (Jeremy Evans) via ruby-core" <ruby-core@...>
Date: 2023-04-04 04:30:11 UTC
List: ruby-core #113101
Issue #19545 has been updated by jeremyevans0 (Jeremy Evans).


hurricup (Alexandr Evstigneev) wrote in #note-3:
> And any expression is a valid argument for any call.

Just to be clear, while this may be a common belief, this is not the case.  If you define valid expression to be a piece of Ruby code that could be executed by itself without a syntax error, then not all valid expressions are valid arguments in Ruby.  The most obvious reason why not all valid expressions can be arguments is that some valid expressions contain `,`, which is used to separate arguments (e.g. multiple assignment).  However, that isn't the only reason.

>From an CRuby internals perspective, all expressions (`expr`) are statements (`stmt`), and all statements surrounded by parentheses are primaries (`primary`), and all primaries are valid arguments (`arg`).  Consult the `arg` definition in `parse.y` if you want to see what Ruby actually considers valid arguments.

It may be possible to modify the parser to expand the definition of argument to start allowing certain expressions that are not currently supported as arguments. I think doing so would be a feature request and not a bug fix, since we would not consider backporting such changes.  FWIW, modifying the current parser is challenging, at least for me. Hopefully with YARP, it will be easier.

----------------------------------------
Feature #19545: lp/hp logic parsing inconsistency
https://bugs.ruby-lang.org/issues/19545#change-102636

* Author: hurricup (Alexandr Evstigneev)
* Status: Open
* Priority: Normal
----------------------------------------
As far as i get it, low precedence logic should behave the same as high precedence. But:

This is ok:
```
puts(false || !false)
```

And this is not:
```
puts(false or not false)
```

Feels like in latter case there is some mess with comma precedence.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [email protected]
 To unsubscribe send an email to [email protected]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

In This Thread