Array lengths do not inherit outer unsafe blocks -- bad diagnostics

[denisandroid]

#![feature(const_slice_len)]
#![feature(const_fn)]
#![allow(unused_variables)]
#![allow(dead_code)]

//rustc 1.35.0-nightly (88f755f8a 2019-03-07)

//Amusing requirement of two UNSAFE blocks. Or and has to be???
//Забавное требование двух небезопасных блоков. Или так и должно быть ???

fn main() {
    unsafe {
        unsafe_fn::<[u8; slice_len(b"  ")]>()
        //error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
    }
    
    //ЗАМЕНИТЕ slice_len(b"  ") -> unsafe{ slice_len(b"  ") }
    //PLEASE, REPLACE slice_len(b"  ") -> unsafe{ slice_len(b"  ") }
}

const unsafe fn unsafe_fn<TArray>() where TArray: Copy {
    
}

const unsafe fn slice_len<T>(a: &[T]) -> usize {
    a.len()
}

PLAY: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e7374b639482f0ac6d0b168ff0c07a62

[Centril]

This is interesting...

cc @oli-obk @varkor @eddyb @RalfJung

Is this a consequence of "anonymous constant"?

I'd add a test for now checking that the code above not compile so we can change it deliberately when we want.

[RalfJung]

Seems like unsafety is not propagated into constants. Not sure if it should.

For const items, not propagating seems consistent with not propagating into nested fn. But for embedded constants like this, it seems surprising, given taht we do propagate unsafe into closures.

[oli-obk]

I think we want this to stay as it is, but we should improve the diagnostic to inform you about what's going on.

[eddyb]

I think it's unintuitive, just like it would be for closures.

[oli-obk]

Oh definitely, but do you think sufficiently good diagnostics cannot alleviate that enough for us to keep the current checks? On the other hand, the inconsistency with closures alone is enough to make me want to leak the unsafety into the constant.

[RalfJung]

In terms of consistency, I think it would make sense to treat const items like fn items (not propagate), but embedded constants (that are not their own items) like closures (that are not their own items either).

[RalfJung]

I propose to close this as "works as intended": unsafe does not propagate into const items.

[oli-obk]

I agree it works as intended, but the diagnostic could explain this (especially for anonymous constants) by adding a span to the outer unsafe mentioning that it does not affect constants within it.

[estebank]

Current output:

error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
  --> src/main.rs:11:26
   |
10 |     unsafe {
   |     ------ items do not inherit unsafety from separate enclosing items
11 |         unsafe_fn::<[u8; slice_len(b"  ")]>()
   |                          ^^^^^^^^^^^^^^^^ call to unsafe function
   |
   = note: consult the function's documentation for information on how to avoid undefined behavior

Only outstanding action would be to suggest unsafe around slice_len(b" ").

[estebank]

I will close this. I feel that if a user doesn't know enough to add unsafe {} around this function call, then they should probably not be doing so. The rest of the error is already addressing the original request.