unsafe expr parsing

[g-r-a-n-t]

Implemented parsing for unsafe expressions.

e.g.

unsafe { 
  let a = 42
  foo(42)
}

unsafe bar()

[Y-Nak]

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]

I will add unsafe expr checking to this as well.

[Y-Nak]

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]

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]

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]

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]

Ok, thanks!