|
5 | 5 |
|
6 | 6 | # Summary |
7 | 7 |
|
8 | | -If the compiler can detect at compile-time that something will always |
9 | | -cause a `debug_assert` or an `assert` it should instead |
10 | | -insert an unconditional runtime-panic and issue a warning. |
| 8 | +If the constant evaluator encounters erronous code during the evaluation of |
| 9 | +an expression that is not part of a true constant evaluation context a warning |
| 10 | +must be emitted and the expression needs to be translated normally. |
11 | 11 |
|
12 | 12 | # Definition of constant evaluation context |
13 | 13 |
|
@@ -41,6 +41,26 @@ If the constant evaluator gets smart enough, it will be able to const evaluate |
41 | 41 | the `blub` function. This would be a breaking change, since the code would not |
42 | 42 | compile anymore. (this occurred in https://github.com/rust-lang/rust/pull/26848). |
43 | 43 |
|
| 44 | +# Detailed design |
| 45 | + |
| 46 | +The PRs https://github.com/rust-lang/rust/pull/26848 and https://github.com/rust-lang/rust/pull/25570 will be setting a precedent |
| 47 | +for warning about such situations (WIP, not pushed yet). |
| 48 | + |
| 49 | +When the constant evaluator fails while evaluating a normal expression, |
| 50 | +a warning will be emitted and normal translation needs to be resumed. |
| 51 | + |
| 52 | +# Drawbacks |
| 53 | + |
| 54 | +None, if we don't do anything, the const evaluator cannot get much smarter. |
| 55 | + |
| 56 | +# Alternatives |
| 57 | + |
| 58 | +## allow breaking changes |
| 59 | + |
| 60 | +Let the compiler error on things that will unconditionally panic at runtime. |
| 61 | + |
| 62 | +## insert an unconditional panic instead of generating regular code |
| 63 | + |
44 | 64 | GNAT (an Ada compiler) does this already: |
45 | 65 |
|
46 | 66 | ```ada |
@@ -75,38 +95,8 @@ call __gnat_rcheck_CE_Range_Check |
75 | 95 | ``` |
76 | 96 |
|
77 | 97 |
|
78 | | -# Detailed design |
79 | | - |
80 | | -The PRs https://github.com/rust-lang/rust/pull/26848 and https://github.com/rust-lang/rust/pull/25570 will be setting a precedent |
81 | | -for warning about such situations (WIP, not pushed yet). |
82 | | -All future additions to the const-evaluator need to notify the const evaluator |
83 | | -that when it encounters a statically known erroneous situation while evaluating |
84 | | -an expression outside of a constant evaluation environment, the |
85 | | -entire expression must be replaced by a panic and a warning must be emitted. |
86 | | - |
87 | | -# Drawbacks |
88 | | - |
89 | | -None, if we don't do anything, the const evaluator cannot get much smarter. |
90 | | - |
91 | | -# Alternatives |
92 | | - |
93 | | -## allow breaking changes |
94 | | - |
95 | | -Let the compiler error on things that will unconditionally panic at runtime. |
96 | | - |
97 | | -## only warn, don't influence code generation |
98 | | - |
99 | | -The const evaluator should simply issue a warning and notify it's caller that the expression cannot be evaluated and should be translated. |
100 | | -This has the disadvantage, that in release-mode statically known issues like |
101 | | -overflow or shifting more than the number of bits available will not be |
102 | | -caught even at runtime. |
103 | | - |
104 | | -On the other hand, this alternative does not change the behavior of existing code. |
105 | | - |
106 | 98 | # Unresolved questions |
107 | 99 |
|
108 | | -## How to implement this? |
109 | | - |
110 | 100 | ## Const-eval the body of `const fn` that are never used in a constant environment |
111 | 101 |
|
112 | 102 | Currently a `const fn` that is called in non-const code is treated just like a normal function. |
|
0 commit comments