Skip to content

New compiler error in beta: this constant cannot be used, attempted to read undefined bytes #54387

Closed

Description

@sdroege

Since latest beta (and nightly), some of my crates have errors like the following

error: this constant cannot be used
  --> src/udpsrc.rs:47:1
   |
47 | const DEFAULT_CAPS: Option<gst::Caps> = None;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempted to read undefined bytes

A standalone testcase replicating all the involved types can be found below (depends only on the libc crate).

I don't know if the error is valid, but in any case I don't understand what it means so at least the error message could be improved a bit :)

use std::marker;
use std::ptr;

extern crate libc;
use libc::{c_int, c_uint, c_void, size_t};

#[repr(C)]
pub struct CapsRef(ffi::GstCaps);

pub type Caps = GstRc<CapsRef>;

pub trait MiniObject {}
impl MiniObject for CapsRef {}

pub struct GstRc<T: MiniObject> {
    obj: ptr::NonNull<T>,
    borrowed: bool,
    phantom: marker::PhantomData<T>,
}

mod ffi {
    use super::*;

    #[repr(C)]
    #[derive(Copy, Clone)]
    pub struct GstCaps {
        pub mini_object: GstMiniObject,
    }

    #[repr(C)]
    #[derive(Copy, Clone)]
    pub struct GstMiniObject {
        pub type_: GType,
        pub refcount: c_int,
        pub lockstate: c_int,
        pub flags: c_uint,
        pub copy: GstMiniObjectCopyFunction,
        pub dispose: GstMiniObjectDisposeFunction,
        pub free: GstMiniObjectFreeFunction,
        pub n_qdata: c_uint,
        pub qdata: gpointer,
    }

    pub type GstMiniObjectCopyFunction =
        Option<unsafe extern "C" fn(*const GstMiniObject) -> *mut GstMiniObject>;
    pub type GstMiniObjectDisposeFunction =
        Option<unsafe extern "C" fn(*mut GstMiniObject) -> gboolean>;
    pub type GstMiniObjectFreeFunction = Option<unsafe extern "C" fn(*mut GstMiniObject)>;

    pub type gboolean = c_int;

    pub type GType = size_t;

    pub type gpointer = *mut c_void;

}

const FOO: Option<Caps> = None;

fn main() {
    let _meh = FOO;
}

Activity

  1. csmoe commented on Sep 20, 2018

    @csmoe
    Contributor

    the testcase compiles with stable-1.29.0.

  2. added
    A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)
    on Sep 20, 2018
  3. hanna-kruppe commented on Sep 21, 2018

    @hanna-kruppe
    Contributor

    Minimized:

    pub struct GstRc {
        _obj: *const (),
        _borrowed: bool,
    }
    
    const FOO: Option<GstRc> = None;
    
    fn main() {
        let _meh = FOO;
    }
  4. pnkfelix commented on Sep 27, 2018

    @pnkfelix
    Contributor

    Visited during T-compiler meeting. Tentatively assigning to @eddyb for investigation.

  5. eddyb commented on Sep 27, 2018

    @eddyb
    Contributor

    cc @RalfJung @oli-obk I can't find anything in the validation code that's reading the wrong thing - it should be able to tell this is a None, which has 0 fields.

  6. AstralSorceress commented on Sep 27, 2018

    @AstralSorceress
    Contributor

    I've been looking into this. It seems that the issue stems from here. Specifically, because the niche-filling enum representation is used for Option<GstRc> and similar types, and the niche that gets filled is the second field (the bool), it is actually the second part of the ScalarPair that is defined, not the first.

  7. eddyb commented on Sep 28, 2018

    @eddyb
    Contributor

    Ahh, you're right! I don't know why only the second component was special-cased.

  8. RalfJung commented on Sep 29, 2018

    @RalfJung
    Member

    Seems like @oli-obk's quest to keep Undef contained within the CTFE engine failed at last. :/

    However, in this case nothing should even be trying to convert to a ConstValue. So I am not sure if that's really the problem.

  9. RalfJung commented on Sep 29, 2018

    @RalfJung
    Member

    Actually it looks like this is not a ScalarPair, but a Scalar being undef. At least that's what the line numbers are saying. It does not make much sense though.

    EDIT: It is definitely a ScalarPair, just the line numbers seem to be wrong.

  10. assigned and unassigned on Sep 30, 2018
  11. RalfJung commented on Sep 30, 2018

    @RalfJung
    Member

    I am working on a fix.

    EDIT: Submitted as #54693

  12. added a commit that references this issue on Oct 1, 2018
  13. eddyb commented on Oct 2, 2018

    @eddyb
    Contributor

    Should this be closed before we get a beta backport?

  14. reopened this on Oct 2, 2018
  15. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Oct 4, 2018
  16. emilyalbini commented on Oct 9, 2018

    @emilyalbini
    Member

    Backported to beta. Closing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions