Issue #20188 has been updated by Eregon (Benoit Daloze). Maybe the idea was because of autoload thread-safety the value is not published to other threads until the autoload completes, and so maybe const_source_location was done that way too. I don't see the need to delay that though as it should not matter for thread-safety, as long as if the assignment happens for the autoload constant it cannot be undone and so the location will be the same once the autoload is completed (even with an exception after the assignment). It might be good to check the current behavior of `const_source_location` if an exception happens after the assignment but in the same file of the autoload. ---------------------------------------- Bug #20188: `Module#const_source_location` returns wrong information when real constant was defined but autoload is still ongoing https://bugs.ruby-lang.org/issues/20188#change-106266 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ref: https://github.com/fxn/zeitwerk/issues/281 `const_source_location` keeps returning the location of the `autoload` call, even after the real constant was defined. It only starts returning the real constant location once the autoload was fully completed. ```ruby # /tmp/autoload.rb File.write("/tmp/const.rb", <<~RUBY) module Const LOCATION = Object.const_source_location(:Const) end RUBY autoload :Const, "/tmp/const" p Const::LOCATION ``` Expected Output: ```ruby ["/tmp/const.rb", 1] ``` Actual Output: ```ruby ["/tmp/autoload.rb", 8] ``` Potential patch: https://github.com/ruby/ruby/pull/9549 -- https://bugs.ruby-lang.org/