Skip to content

unsafe expr parsing#991

Open
g-r-a-n-t wants to merge 1 commit intoargotorg:fe-v2from
g-r-a-n-t:v2-parser
Open

unsafe expr parsing#991
g-r-a-n-t wants to merge 1 commit intoargotorg:fe-v2from
g-r-a-n-t:v2-parser

Conversation

@g-r-a-n-t
Copy link
Collaborator

@g-r-a-n-t g-r-a-n-t commented Feb 29, 2024 •
edited
Loading

Implemented parsing for unsafe expressions.

e.g.

unsafe { 
  let a = 42
  foo(42)
}

unsafe bar()

Y-Nak
Y-Nak reviewed Feb 29, 2024
View reviewed changes
Copy link
Member

@Y-Nak Y-Nak left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unsafe should be applied to block expression. Please consider this example.

let x = unsafe {
    unsafe_fn()
}

So basically, what you need to do is

  1. Modify expr parsing
  2. Add unsafe_kw method to ast::BlockExpr
  3. Modify hir::Expr::Block(Vec<StmtId>) to hir::Expr::Block(Vec<StmtId>, bool) or hir::Expr::Block{ stmts: Vec<StmtId>, is_unsafe: bool }
  4. Modify hir::lower::expr::Expr::lower_ast
  5. Define LazyBlockExprSpan and add a method to be able to get unsafe span

@g-r-a-n-t g-r-a-n-t marked this pull request as draft March 2, 2024 03:30
@g-r-a-n-t g-r-a-n-t force-pushed the v2-parser branch 3 times, most recently from 3ad97f3 to c80078a Compare March 7, 2024 00:27
@Y-Nak Y-Nak marked this pull request as ready for review March 7, 2024 10:45
@Y-Nak Y-Nak marked this pull request as draft March 7, 2024 10:46
g-r-a-n-t
g-r-a-n-t commented Mar 7, 2024
View reviewed changes
g-r-a-n-t
g-r-a-n-t commented Mar 16, 2024
View reviewed changes
@g-r-a-n-t g-r-a-n-t marked this pull request as ready for review March 16, 2024 08:41
@g-r-a-n-t g-r-a-n-t changed the title v2 unsafe block parsing unsafe expr parsing Apr 10, 2024
@g-r-a-n-t g-r-a-n-t force-pushed the v2-parser branch 3 times, most recently from a5a1bfe to 21cf6e9 Compare April 15, 2024 16:48
g-r-a-n-t
g-r-a-n-t commented Apr 15, 2024
View reviewed changes
@g-r-a-n-t g-r-a-n-t force-pushed the v2-parser branch 3 times, most recently from c362d7d to e096a5a Compare April 16, 2024 00:26
sbillig
sbillig reviewed Apr 16, 2024
View reviewed changes
@g-r-a-n-t g-r-a-n-t force-pushed the v2-parser branch 2 times, most recently from da36247 to 1645bf6 Compare April 19, 2024 01:39
@g-r-a-n-t
Copy link
Collaborator Author

g-r-a-n-t commented Apr 23, 2024

I will add unsafe expr checking to this as well.

@Y-Nak
Copy link
Member

Y-Nak commented Apr 23, 2024

It's still unclear to me what the unsafe actually means in Fe. Do you have any concrete thoughts on this?

@g-r-a-n-t
Copy link
Collaborator Author

g-r-a-n-t commented Apr 23, 2024

It's still unclear to me what the unsafe actually means in Fe. Do you have any concrete thoughts on this?

In general, code should be labeled as unsafe if it has the potential to introduce undefined behavior during runtime. For instance, an invocation of evm::mstore(..) could alter the value of data that is exclusively used in safe code, thus necessitating the unsafe label.

@Y-Nak
Copy link
Member

Y-Nak commented Apr 23, 2024

Ok. So, in the v1 implementation, there are functions that don't cause undefined behavior (UB) but are still marked as unsafe, like RawCallBuffer::offset, which merely returns an offset. Am I correct in understanding that these should not be marked as unsafe? I felt that unsafe was being somewhat abused in v1, so I want to eliminate any ambiguity in my understanding.

@g-r-a-n-t
Copy link
Collaborator Author

g-r-a-n-t commented Apr 24, 2024 •
edited
Loading

That is correct. I agree that unsafe was overused in v1 and think that it should be used more sparingly in the v2 implementation.

@Y-Nak
Copy link
Member

Y-Nak commented Apr 24, 2024

Ok, thanks!

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

Reviewers

@sbillig sbillig sbillig left review comments

@Y-Nak Y-Nak Y-Nak left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@g-r-a-n-t @Y-Nak @sbillig