From: merch-redmine@...
Date: 2020-11-30T16:15:00+00:00
Subject: [ruby-core:101159] [Ruby master Bug#17354] Module#const_source_location is misleading for constants awaiting autoload

Issue #17354 has been updated by jeremyevans0 (Jeremy Evans).


ufuk (Ufuk Kayserilioglu) wrote in #note-2:
> @mame In my use-case, I would very much like `Module#const_source_location` to tell me where the constant is loaded or *would be loaded from if it is autoloaded*. I am doing runtime reflection to discover types in gems and their associated methods, constants, etc in Tapioca, and my biggest problem so far has been detecting which file a constant is originally loaded from. I'd been waiting for `Module#const_source_location` to give me that information, even if the constant has not been loaded yet. The autoload file location, theoretically, could point to a file in a different gem or even to `bootsnap` if it is in play, which stops this use-case from working properly.
> 
> I would very much like `Module#const_source_location` to work like this:
> ```ruby
> % echo 'class Foo; end' > foo.rb
> 
> % irb
> >> Module.const_defined?(:Foo)
> => false
> >> Module.const_source_location(:Foo)
> => nil
> 
> >> autoload :Foo, './foo'
> => nil
> 
> >> Module.const_defined?(:Foo)
> => true
> >> Module.const_source_location(:Foo)
> => ["./foo.rb", nil]
> 
> >> Module.const_get(:Foo)
> => Foo
> 
> >> Module.const_defined?(:Foo)
> => true
> >> Module.const_source_location(:Foo)
> => ["./foo.rb", 1]
> ```
> since Ruby basically knows where `Foo` *will be* loaded from, but cannot tell us what line number it will be from without actually loading the file. Thus, I propose the line number be `nil` in that case.

This is not always true.  Ruby does not know that the constant's location will be in that file.  All it knows is that requiring that file should result in the constant being available after. The file mentioned may require or load another file with the constant definition.  It may not even load it, you could end up with a NameError when referencing the constant.  

If the location of the autoload definition is not useful, I think the main reasonable alternative would be `[]`, as Ruby does not know where the constant will be defined.  This is the same value used for constants defined in C.

----------------------------------------
Bug #17354: Module#const_source_location is misleading for constants awaiting autoload
https://bugs.ruby-lang.org/issues/17354#change-88845

* Author: tomstuart (Tom Stuart)
* Status: Open
* Priority: Normal
* ruby -v: ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
Feature #10771 added `Module#const_source_location` as a way to find the source location of a constant���s definition. Bug #16764 reported that it didn���t work correctly for autoloaded constants, instead giving the source location of the `autoload` call site. This was fixed in `v3_0_0_preview1` in commit:92730810 and backported to `v2_7_2` in commit:c65aae11.

However, `#const_source_location` still returns the `autoload` call site for constants which have not yet been loaded:

```
% echo 'class Foo; end' > foo.rb

% irb
>> Module.const_defined?(:Foo)
=> false
>> Module.const_source_location(:Foo)
=> nil

>> autoload :Foo, './foo'
=> nil

>> Module.const_defined?(:Foo)
=> true
>> Module.const_source_location(:Foo)
=> ["(irb)", 3]

>> Module.const_get(:Foo)
=> Foo

>> Module.const_defined?(:Foo)
=> true
>> Module.const_source_location(:Foo)
=> ["./foo.rb", 1]
```

This edge case is undocumented and surprising. It looks like a bug to the programmer who receives the `autoload` location instead of one of the documented return values of `#const_source_location` (`nil`, `[]`, or the definition���s source location).

We could either:

* change the behaviour of `#const_source_location` to return `[]` for constants awaiting autoload, which is consistent with the [return value of `Module#const_defined?`](https://docs.ruby-lang.org/en/2.7.0/Module.html#method-i-const_defined-3F) in this case (���if the constant is not present but there is an autoload for it, `true` is returned directly���), as well as the [return value of `#const_source_location`](https://docs.ruby-lang.org/en/2.7.0/Module.html#method-i-const_source_location) for other constants whose source location is unknown (���if the constant is found, but its source location can not be extracted (constant is defined in C code), empty array is returned���); or
* document the current behaviour of `#const_source_location` to make it less surprising.

I recommend the first option ��� although the current behaviour was recently specified in source:spec/ruby/core/module/const_source_location_spec.rb@6d059674#L209, it doesn���t seem intentional ��� but if that���s not feasible, simply documenting this edge case would also be an improvement.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>