The config_namespace! macro requires datafusion::common::Result to be in scope

[davisp]

Describe the bug

Just got caught by this. If you don't have datafusion::common::Result in scope as Result when using config_namespace!, rust-analyzer returns diagnostics for enum takes 2 generic arguments but 1 generic argument was supplied. I ended up having to cargo expand the module and paste it into an editor to figure out what it was complaining about.

I'm pretty sure I just need to fully specify the Result type here:

datafusion/datafusion/common/src/config.rs

Line 142 in 304488d

fn set(&mut self, key: &str, value: &str) -> Result<()> {

As in, just prefix it with ::datafusion::common:: on that line.

To Reproduce

use datafusion::common::config::{ConfigField, Visit};
use datafusion::common::config_namespace;
use datafusion::common::error::_config_err;

// This has to be uncommented to fix the compiler error.
// use datafusion::common::Result;

config_namespace! {
    /// Options for controlling TileDB specific optimizations
    pub struct ExampleOptions {
        /// Control whether TileDB will attempt to do predicate pushdown.
        /// Setting this to false will disable all predicate push down analysis
        /// and rely on DataFusion to filter returned data. Generally speaking,
        /// this should only be disabled when testing predicate pushdown
        /// logic.
        pub some_setting: String, default = String::new()
    }
}

Expected behavior

I would expect config_namespace! to work whether or not I have a specific identifier in scope.

Additional context

I'm more than happy to post a PR for this as long as someone Ok's the proposed solution (or can point me at a better approach).

[rkrishn7]

Your solution makes sense to me @davisp! Consider using the $crate metavariable within the macro definition.

Also, it looks like the macro was removed as an export in #14188 🤔 . We'll likely want to add back the #[macro_export] attribute if there's use of it outside datafusion_common.

[logan-keede]

you are right, removing #[macro_export] does not seem to be related to the issue I was trying to solve.
It was a miss on my part. Perhaps @davisp can fix that, while solving this issue.

Also, is it the cause of this issue? it seems like we can still load the macro just not by #[macro_use].(I haven't use macros much in rust.)

[davisp]

@rkrishn7 Awesome, I'll open a PR in a few minutes. Thanks for the reminder on $crate being a thing.

@logan-keede I'll add it back, no problem! Also that's not the cause of this issue so no worries there.