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

turn statically known erroneous code into a warning and continue normal code-generation #1229

Merged
merged 6 commits into from
Sep 4, 2015
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
107 changes: 107 additions & 0 deletions text/0000-compile-time-asserts.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,107 @@
- Feature Name: compile_time_asserts
- Start Date: 2015-07-30
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary

If the constant evaluator encounters erronous code during the evaluation of
an expression that is not part of a true constant evaluation context a warning
must be emitted and the expression needs to be translated normally.

# Definition of constant evaluation context

There are exactly five places where an expression needs to be constant.

- the initializer of a constant `const foo: ty = EXPR` or `static foo: ty = EXPR`
- the size of an array `[T; EXPR]`
- the length of a repeat expression `[VAL; LEN_EXPR]`
Copy link
Contributor

Choose a reason for hiding this comment

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

This isn't a complete list... off the top of my head, patterns and enum discriminants are also required to be constant.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

- C-Like enum variant discriminant values
- patterns

In the future the body of `const fn` might also be interpreted as a constant
evaluation context.

Any other expression might still be constant evaluated, but it could just
as well be compiled normally and executed at runtime.

# Motivation

Expressions are const-evaluated even when they are not in a const environment.

For example

```rust
fn blub<T>(t: T) -> T { t }
let x = 5 << blub(42);
```

will not cause a compiler error currently, while `5 << 42` will.
If the constant evaluator gets smart enough, it will be able to const evaluate
the `blub` function. This would be a breaking change, since the code would not
compile anymore. (this occurred in /~https://github.com/rust-lang/rust/pull/26848).

# Detailed design

The PRs /~https://github.com/rust-lang/rust/pull/26848 and /~https://github.com/rust-lang/rust/pull/25570 will be setting a precedent
for warning about such situations (WIP, not pushed yet).

When the constant evaluator fails while evaluating a normal expression,
a warning will be emitted and normal translation needs to be resumed.

# Drawbacks

None, if we don't do anything, the const evaluator cannot get much smarter.

# Alternatives

## allow breaking changes

Let the compiler error on things that will unconditionally panic at runtime.

## insert an unconditional panic instead of generating regular code

GNAT (an Ada compiler) does this already:

```ada
procedure Hello is
Var: Integer range 15 .. 20 := 21;
begin
null;
end Hello;
```

The anonymous subtype `Integer range 15 .. 20` only accepts values in `[15, 20]`.
This knowledge is used by GNAT to emit the following warning during compilation:

```
warning: value not in range of subtype of "Standard.Integer" defined at line 2
warning: "Constraint_Error" will be raised at run time
```

I don't have a GNAT with `-emit-llvm` handy, but here's the asm with `-O0`:

```asm
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $2, %esi
movl $.LC0, %edi
movl $0, %eax
call __gnat_rcheck_CE_Range_Check
```


# Unresolved questions

## Const-eval the body of `const fn` that are never used in a constant environment

Currently a `const fn` that is called in non-const code is treated just like a normal function.
Copy link
Member

Choose a reason for hiding this comment

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

(brief discussion leads me to think that the context of a body of a const fn is inherited from the context of the call-site. (This is mostly a note to myself; I'll try to write something more coherent later.)


In case there is a statically known erroneous situation in the body of the function,
the compiler should raise an error, even if the function is never called.

The same applies to unused associated constants.