zero_ptr lint detected for any lazy_static code

[vitiral]

I'm running clippy v0.0.115

This code

pub const ART_VALID_STR: &'static str = "(REQ|SPC|RSK|TST)(-[A-Z0-9_-]*[A-Z0-9_])?";

lazy_static!{
    // must start with artifact type, followed by "-", followed by at least 1 valid character
    // cannot end with "-"
    pub static ref ART_VALID: Regex = Regex::new(
        &format!("^{}$", ART_VALID_STR)).unwrap();
    pub static ref PARENT_PATH: PathBuf = PathBuf::from("PARENT");
    pub static ref INCREMENTING_ID: AtomicUsize = AtomicUsize::new(0);
}

Is generating this error repeatedely:

warning: `0 as *const _` detected. Consider using `ptr::null()`
  --> src/core/types.rs:26:1
   |
26 |   lazy_static!{
   |  _^ starting here...
27 | |     // must start with artifact type, followed by "-", followed by at least 1 valid character
28 | |     // cannot end with "-"
29 | |     pub static ref ART_VALID: Regex = Regex::new(
30 | |         &format!("^{}$", ART_VALID_STR)).unwrap();
31 | |     pub static ref PARENT_PATH: PathBuf = PathBuf::from("PARENT");
32 | |     pub static ref INCREMENTING_ID: AtomicUsize = AtomicUsize::new(0);
33 | | }
   | |_^ ...ending here
   |
   = note: #[warn(zero_ptr)] on by default
   = help: for further information visit https://github.com/Manishearth/rust-clippy/wiki#zero_ptr
   = note: this error originates in a macro outside of the current crate

This never happened before. All I did was update clippy to the latest version.

[vitiral]

I also can't seem to silence the lint with #![allow(zero_ptr)] put at the top of the file

[vitiral]

nevermind, the allow flag works -- it was just that I needed to enable it for my whole library since I use lazy_static! everywhere

[Arnavion]

Unfortunately, just changing lazy_static to use ptr::null() doesn't work since it would require const functions support.

[oli-obk]

I don't see any reason why ptr::null() couldn't be const fn. But we should probably not lint zero_ptr inside macro invocations.

[Arnavion]

It is a const fn already. The issue is that using const fns requires opting in to the feature.

[aldanor]

I don't see any reason why ptr::null() couldn't be const fn. But we should probably not lint zero_ptr inside macro invocations

Disabling inside macro invocations sounds like a hack; could constexpr context be detected? At least this case (which is what causes false positives in lazy_static):

(static|static mut) <var>: <ty> = /* disable zero_ptr for RHS of the assignment */;

[oli-obk]

yea, but you also have [T; N] and the bodies of const fn. And

static FOO: fn() -> *const i32 = {
    fn f() -> *const i32 {
        0 as *const i32
    }
    f
};

Should not lint, ...

I'm working on trying to fully fix this instead of going for a partial fix. The same issues apply to other lints like cmp_nan, too.

[mcarton]

Automatically closed but reopening as long as it's not fully fixed (see #1610).

[Jarcho]

I assume this is fixed now as all the relevant PR's are merged.