From: merch-redmine@... Date: 2021-05-05T16:47:35+00:00 Subject: [ruby-core:103748] [Ruby master Bug#15928] Constant declaration does not conform to JIS 3017:2013 Issue #15928 has been updated by jeremyevans0 (Jeremy Evans). Eregon (Benoit Daloze) wrote in #note-10: > > This is a bug fix, not a feature change, and should be treated like other bug fixes. > > Like other bug fixes, none of them removes specs. They add a version guard. 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. > A new example for the new behavior would be great, so we can clearly see what changed, but I won't fight for that in this issue (every other committer does it though AFAIK). From a cursory analysis of the CRuby commit log, looking for commits that make modifications to either `test` or `spec`, the most common case is only files in `test` are modified. Modifications to `spec` are less frequent, with the vast majority of changes to `spec` coming from merges from `ruby/spec`, not direct commits. So `every other committer does it though` does not appear to be accurate. > I recommend to see ruby/spec as a test suite shared between Ruby implementations (so it must support multiple Ruby versions), and to which all Ruby implementations can easily contribute (the name is confusing, I know, we all make mistakes). > Maybe it's easier to understand my point of view that way. > And since I'm the main maintainer/contributor of ruby/spec, I believe I get to define the vision and what is its purpose. 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. I've updated the pull request to guard the current spec. I also added a basic spec for single constant assignment after this change. ---------------------------------------- Bug #15928: Constant declaration does not conform to JIS 3017:2013 https://bugs.ruby-lang.org/issues/15928#change-91849 * 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: