Fix tab completion in Logging for functions from CoreLogging

[c42f]

CoreLogging is an implementation detail, but the fact that Logging
imports things from there breaks tab completion of Logging.<tab> even though these
symbols are exported again. Fix this by explicitly creating bindings for
each imported symbol.

[c42f]

Tests added.

[StefanKarpinski]

Any thoughts on who might review?

[KristofferC]

We do the same in Pkg: https://github.com/JuliaLang/Pkg.jl/blob/0dabd4e1729e244371da7b0bd73e5ad31f7cce7f/src/Pkg.jl#L60.

[c42f]

Yes, I'm doing this for the same reasons as Pkg (I think).

It's a minor change though there are alternatives such as just exporting these parts of the public API. @oxinabox any thoughts?

[oxinabox]

On the one hand this is gross, and we should just fix tab-completion.

On the other hand, indeed I do indeed only access these things via Loghing. never CoreLogging

[c42f]

Fixing tab completion "properly" depends on having the right information in the runtime about the desired visibility of symbols. One way to give this information is just to create the bindings explicitly, as I've done here. It's gross but in a reasonably maintainable kind of way ;-)

The root of the issue is in the flags on jl_binding_t and how these are set when bindings are created:

julia/src/julia.h

Lines 456 to 466 in 61a0b04

	typedef struct {
	// not first-class
	jl_sym_t *name;
	jl_value_t *value;
	jl_value_t *globalref; // cached GlobalRef for this binding
	struct _jl_module_t *owner; // for individual imported bindings
	uint8_t constp:1;
	uint8_t exportp:1;
	uint8_t imported:1;
	uint8_t deprecated:2; // 0=not deprecated, 1=renamed, 2=moved to another package
	} jl_binding_t;

From reading module_import_ in module.c, the imported flag is set from import statements, but not from using statements. So we could change REPL tab completion such that it uses names(mod; imported=true) and this would fix the problem for Logging in particular.

Perhaps this is a reasonable alternative; using import in source code rather than using could be seen as a sign that one will treating the binding as "native to the module".

[oxinabox]

Perhaps this is a reasonable alternative; using import in source code rather than using could be seen as a sign that one will treating the binding as "native to the module".

What about export?
the Logging stdlib reexports all of those

[c42f]

It doesn't export handle_message and friends. The idea of not exporting those being that there's generally no reason you want to call them unless you're making a logging extension module.

Anyway, this will work for now, cheers for just going ahead with the merge.