Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Struct constness/mutability needs to be represented in metadata #3177

Closed
bblum opened this issue Aug 11, 2012 · 6 comments
Closed

Struct constness/mutability needs to be represented in metadata #3177

bblum opened this issue Aug 11, 2012 · 6 comments
Labels
A-trait-system Area: Trait system A-type-system Area: Type system

Comments

@bblum
Copy link
Contributor

bblum commented Aug 11, 2012

Whether or not a struct is const is forgotten across crate boundaries. The compiler should reject this program:

const.rs:

use nonconst;
import nonconst::nonconst;

fn x<T: const>(_x: T) { }

fn main() { x(nonconst()) }

nonconst.rc:

#[crate_type = "lib"];

nonconst.rs:

struct nonconst { mut z: (); }
fn nonconst() -> nonconst { nonconst { mut z: () } }

If you change the type nonconst to be e.g. an old-style record type, the program is correctly rejected.

@catamorphism
Copy link
Contributor

Seems like this bug even manifests with non-cross-crate structs:

struct S<T: Const> {
    s: T,
    mut cant_nest: ()
}

fn main() {
    let a1  = ~S{ s: true, cant_nest: () };
    let _a2 = ~S{ s: move a1, cant_nest: () };
}

This seems like it shouldn't compile, as ~S doesn't have kind Const (it contains a mutable field). Yet it does compile (as of 59a034a ).

catamorphism added a commit that referenced this issue Nov 16, 2012
@emberian
Copy link
Member

@bblum is this still an issue?

@bblum
Copy link
Contributor Author

bblum commented Jun 27, 2013

No, it isn't. The test has bitrotted slightly and should now be:

extern mod extra;
use extra::arc::RWARC;

fn main() {
    let arc1  = ~RWARC(true);
    let _arc2 = ~RWARC(arc1);
}

Anyone who updates it should close.

@bblum
Copy link
Contributor Author

bblum commented Jul 5, 2013

Actually, yes it is. The cant-nest-rw-arcs test seems to work fine, but the OP test case is still broken, not even cross-crate. It correctly falis to compile if the struct has a mutable thing inside (@mut), but not if the only thing making it nonconst is the #[mutable] tag. The problem is likely with ty::type_contents.

I don't know why the mutable tag works for RWARC but not for this.

#[mutable]
struct Nonconst { x: () }
pub fn nonconst() -> Nonconst { Nonconst { x: () } } 

fn x<T: Freeze>(_x: T) { }

fn main() { x((nonconst())) }

@thestinger
Copy link
Contributor

The #[mutable] attribute got renamed to #[no_freeze] so that's the issue. It would be really nice if we only accepted valid attributes...

@bblum
Copy link
Contributor Author

bblum commented Jul 5, 2013

DAMMIT

bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
…ace-leading-ws

Format brace-delimited macros with a space after the name
RalfJung pushed a commit to RalfJung/rust that referenced this issue Nov 25, 2023
…Jung

libc-misc test freebsd fixes attempt
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Dependency upgrade resulting from `cargo update`.

---------

Co-authored-by: tautschnig <[email protected]>
Co-authored-by: Zyad Hassan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

4 participants