|
1 | 1 | - Start Date: (fill me in with today's date, YYYY-MM-DD)
|
2 |
| -- RFC PR: (leave this empty) |
3 |
| -- Rust Issue: (leave this empty) |
| 2 | +- RFC PR: [rust-lang/rfcs#563](https://github.com/rust-lang/rfcs/pull/563) |
| 3 | +- Rust Issue: [rust-lang/rust#22492](https://github.com/rust-lang/rust/issues/22492) |
4 | 4 |
|
5 | 5 | # Summary
|
6 | 6 |
|
@@ -42,4 +42,22 @@ No real alternatives beyond different names and defaults.
|
42 | 42 |
|
43 | 43 | # Unresolved questions
|
44 | 44 |
|
45 |
| -None. |
| 45 | +From the RFC discussion there remain some unresolved details: |
| 46 | + |
| 47 | +* brson |
| 48 | + [writes](https://github.com/rust-lang/rfcs/pull/563#issuecomment-72549694), |
| 49 | + "I have a minor concern that `-C debug-assertions` might not be the |
| 50 | + right place for this command line flag - it doesn't really affect |
| 51 | + code generation, at least in the current codebase (also `--cfg |
| 52 | + debug_assertions` has the same effect).". |
| 53 | +* huonw |
| 54 | + [writes](https://github.com/rust-lang/rfcs/pull/563#issuecomment-72550619), |
| 55 | + "It seems like the flag could be more than just a boolean, but |
| 56 | + rather take a list of what to enable to allow fine-grained control, |
| 57 | + e.g. none, overflow-checks, debug_cfg,overflow-checks, all. (Where |
| 58 | + -C debug-assertions=debug_cfg acts like --cfg debug.)". |
| 59 | +* huonw |
| 60 | + [writes](https://github.com/rust-lang/rfcs/pull/563#issuecomment-74762795), |
| 61 | + "if we want this to apply to more than just debug_assert do we want |
| 62 | + to use a name other than -C debug-assertions?". |
| 63 | + |
0 commit comments