From: eregontp@... Date: 2021-05-05T17:12:47+00:00 Subject: [ruby-core:103749] [Ruby master Bug#15928] Constant declaration does not conform to JIS 3017:2013 Issue #15928 has been updated by Eregon (Benoit Daloze). jeremyevans0 (Jeremy Evans) wrote in #note-11: > Stating absolutes without confirming them is risky. Looking through the commits to `spec`, commit:c881678cd75432f47903a5d1d8b86a7a723cb023 just removed specs stating `It is not a spec [...] of Ruby`. I will grant that that most bug fixes add guards instead of removing specs. Indeed. I think it holds for the vast majority though. That case is not fixing a bug in Ruby, it's handling a spec that does not work due to external changes. > So `every other committer does it though` does not appear to be accurate. I meant that, AFAIK in most cases, when spec/ruby needs to be adapted when behavior changes the existing spec example(s) was kept under a version guard and a new spec example was added for the new behavior. I and other Ruby implementations devs really appreciate this, and that way the coverage is kept as good as before and there is a very clear test that demonstrates the changed behavior. > If the purpose of `ruby/spec` is testing for observed behavior of CRuby, without consideration for whether the behavior is feature or bug, then it makes sense to keep the existing spec. Yes, pretty much. It tries to also document the behavior and other things, but indeed it tests what CRuby does, since there is no actual standard/formal specification that CRuby follows, CRuby is the de-facto standard and the reference implementation. Other general-purpose Ruby implementations (e.g. aim to run Rails/arbitrary gems like JRuby/TruffleRuby) need to be compatible (and sometimes bug-compatible too) with CRuby to support a maximum number of gems/applications. > I've updated the pull request to guard the current spec. I also added a basic spec for single constant assignment after this change. Thank you! ---------------------------------------- Bug #15928: Constant declaration does not conform to JIS 3017:2013 https://bugs.ruby-lang.org/issues/15928#change-91850 * Author: yugui (Yuki Sonoda) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.0dev (2019-06-16T14:01:46Z master d4929f5185) [x86_64-darwin18] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- The order of evaluation in constant declaration does not conform to JIS 3017:2013 11.4.2.2.3. # Problem Suppose that we are evaluating the following program. ``` expr::C = lhs ``` The standard seems to be requiring the following evaluation order: 1. expr * raise a TypeError if the value is not a kind of Module 2. lhs 3. rb_const_set(expr, :C, lhs) However, the actual implementation evaluates in the following order 1. lhs 2. expr 3. rb_const_set(expr, :C, lhs) * raise a TypeError if the expr is not a kind of Module # How to reproduce The next program does not raise "recv" but raises "value" ``` raise("recv")::C = raise("value") ``` The next program does not raise a TypeError but raises a RuntimeError ``` A = 1 A::C = raise("value") ``` # Question * Is this interpretation of the standard correct? * If it is, Should we change the current behavior? * If we shouldn't, does it mean an issue in the standard? c.f. * https://twitter.com/n0kada/status/1140234416175763456 -- https://bugs.ruby-lang.org/ Unsubscribe: