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

Introduce a new raw_ptr type a disallow it to be returned from scripts #2551

Closed
mohammadfawaz opened this issue Aug 16, 2022 · 3 comments · Fixed by #2828
Closed

Introduce a new raw_ptr type a disallow it to be returned from scripts #2551

mohammadfawaz opened this issue Aug 16, 2022 · 3 comments · Fixed by #2828
Assignees
Labels
compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen compiler: parser Everything to do with the parser compiler: ui Mostly compiler messages language feature Core language features visible to end users Needs RFC Features that require an RFC before proceeding with an implementation P: critical Should be looked at before anything else

Comments

@mohammadfawaz
Copy link
Contributor

mohammadfawaz commented Aug 16, 2022

For example:

struct RawVec<T> {
    #[pointer]
    ptr: u64,
    cap: u64,
}

The immediate benefit of this is preventing RawVec<T> (and by extension Vec<T>) from being returned from a script because when we cross the script boundary, the ptr value is not meaningful.

This annotation may have future uses as well.

An alliterative is to introduce pointer/reference types (other than mut ref function parameters) but that's a rabbit hole we probably don't want to explore.

Edit: The above proposal has been voted against and the preferred way of doing this seems to be to introduce a raw_ptr type as @canndrew as described in #2699

@mohammadfawaz mohammadfawaz added language feature Core language features visible to end users compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen compiler: parser Everything to do with the parser compiler: ui Mostly compiler messages labels Aug 16, 2022
@mohammadfawaz mohammadfawaz changed the title Introduce a new #[pointer] annotation to indicate that a given struct field is actually pointer Introduce a new #[pointer] annotation to indicate that a given struct field is actually a pointer Aug 16, 2022
@otrho
Copy link
Contributor

otrho commented Aug 17, 2022

This feels a bit hacky, as does a lot of our avoidance of pointers. But I really don't want to add references.

Would an alternative be an 'address' type, which is very much locked down? I.e. you can't create them from anywhere other than a heap or stack allocation. It'd be different to a reference or pointer, where you would take the address of a value. And then we limit it specifically to only do the operations we need in Vec and similar data structures. 🤔

@adlerjohn adlerjohn added the P: critical Should be looked at before anything else label Aug 18, 2022
@tritao
Copy link
Contributor

tritao commented Aug 22, 2022

This feels a bit hacky, as does a lot of our avoidance of pointers. But I really don't want to add references.

Would an alternative be an 'address' type, which is very much locked down? I.e. you can't create them from anywhere other than a heap or stack allocation. It'd be different to a reference or pointer, where you would take the address of a value. And then we limit it specifically to only do the operations we need in Vec and similar data structures. thinking

That does sound better than the #[pointer]. It kinda reminds me of C's intptr_t, which is still an integer in essence, but providing some limited type-safety, and conveying that it's really a pointer inside.

@canndrew
Copy link
Contributor

I also think an untyped pointer type is the way to go. Then, when/if we get typed pointers/references we can have conversion methods for add/removing the pointee type. eg. something like:

impl RawPtr {
    unsafe fn with_type<T>(self) -> *const T;
}

impl<T> *const T {
    fn strip_type(self) -> RawPtr;
}

It's also important if we ever want to start tracking provenance to have a distinction between pointers and pointer-sized ints.

@mohammadfawaz mohammadfawaz changed the title Introduce a new #[pointer] annotation to indicate that a given struct field is actually a pointer Introduce a new raw_ptr type Sep 6, 2022
@sezna sezna added the Needs RFC Features that require an RFC before proceeding with an implementation label Sep 8, 2022
@mohammadfawaz mohammadfawaz assigned AlicanC and unassigned canndrew Sep 21, 2022
@AlicanC AlicanC linked a pull request Sep 22, 2022 that will close this issue
@mohammadfawaz mohammadfawaz changed the title Introduce a new raw_ptr type Introduce a new raw_ptr type a disallow it to be returned from scripts Sep 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen compiler: parser Everything to do with the parser compiler: ui Mostly compiler messages language feature Core language features visible to end users Needs RFC Features that require an RFC before proceeding with an implementation P: critical Should be looked at before anything else
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants