Cleans up four items I came across in ActiveSupport::Dependencies:
- DependenciesTest#
test_dependency_which_raises_exception_isnt_added_to_loaded_set:
Fixes current implementation which will pass no matter what since the
filepath is never added to "loaded" or "history" without being
expanded first.
- Remove DependenciesTest#test_unhook. Seems leftover from when
alias_method_chain was used in Loadable and ModuleConstMissing.
The test will always pass since Module never responds to those methods
- WatchStack#new_constants documentation: update self to @stack.
Looks like self was leftover from when WatchStack inherited from Hash
- Remove ActiveSupport namespace from call to
Dependencies.constant_watch_stack.watching? since the namespace is not
needed, Dependencies is called two other times in the same method
without it (even on the same line) and it brings the line to within
80 characters
The check for circular loading should depend on a stack of files being
loaded at the moment, rather than the collection of loaded files.
This showed up indirectly in #16468, where a misspelled helper would
incorrectly result in a circularity error message.
References #16468
Change most tests to make use of assert_raise returning the raised
exception rather than relying on a combination of flunk + rescue to
check for exception types/messages.
In Minitest, the second argument of assert_raise(s) accepts a string as
the message that should be shown in case of a failure in the assertion
(eg nothing was raised when it should), and not the exception message to
be matched.
To do that we need to save the exception returned from assert_raise(s)
into a local variable and check for the exception message using it.
load_missing_constant is a private method that basically plays the role of const_missing.
This method has an error condition that is surprising: it raises if the class or module
already has the missing constant. How is it possible that if the class of module has
the constant Ruby has called const_missing in the first place?
The answer is that the from_mod argument is self except for anonymous modules, because
const_missing passes down Object in such case (see the comment in the source code of the
patch for the rationale).
But then, it is better to pass down Object *if Object is also missing the constant* and
otherwise err with an informative message right away.
Previously, an autoloaded constant `HTML::SomeClass` would not be marked
as autoloaded by AS::Dependencies. This is because the
`#loadable_constants_for_path` method uses `String#camelize` on the
inferred file path, which in turn means that, unless otherwise directed,
AS::Dependencies watches for loaded constants in the `Html` namespace.
By passing the original qualified constant name to `#load_or_require`,
this inference step is avoided, and the new constant is picked up in the
correct namespace.
It is possible under some environments to receive an Exception that is
not extended with Blamable (e.g. JRuby).
ActiveSupport::Dependencies::Loadable#load_dependency blindly call
blame_file! on the exception which throws it's own NoMethodError
exception and hides the original Exception.
This commit fixes#9521
The AS utility silence_warnings does not really silence this
one, because it is issued at parse-time. It seemed to in
some places because the constant was the only expression in
the block and therefore it was its return value, that could
potentially be used by silence_warnings are return value of
the yield call.
To bypass the warning we assign to a variable. The chosen
variable is "_" because it is special-cased in parse.c not
to issue an "assigned but unused variable" warning in turn.
Nowadays circular autoloads do not work, but the user gets a NameError
that says some constant is undefined. That's puzzling, because he is
normally trying to autoload a constant he knows can be autoloaded.
With this check we can give a better error message.
Ruby 2.0.0 implements LoadError#path, but newly raised load errors will
not contain the path information. Replace the error message, copy
blame, and rereaise the same exception object
This is an obsolete method from the very early days,
apparently it was used circa 2004 because STI support
was not smart enough. This method is not public
interface, and we are heading a major version, so
removal seems right.
