- 11 4月, 2022 1 次提交
-
-
由 Jakob Degen 提交于
-
- 09 3月, 2022 2 次提交
- 28 2月, 2022 1 次提交
-
-
由 Camille GILLOT 提交于
-
- 22 2月, 2022 1 次提交
-
-
由 lcnr 提交于
-
- 21 11月, 2021 1 次提交
-
-
由 Cameron Steffen 提交于
-
- 29 8月, 2021 1 次提交
-
-
由 Michael Howell 提交于
Before: help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped | LL | for x in DroppingSlice(&*v).iter(); { | + After: help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped | LL | }; | + This seems like a reasonable fix: since the desugared "expr_drop_temps_mut" contains the entire desugared loop construct, its span should contain the entire loop construct as well.
-
- 26 8月, 2021 1 次提交
-
-
由 Wesley Wiser 提交于
Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
-
- 27 5月, 2021 1 次提交
-
-
由 Jacob Pratt 提交于
-
- 01 3月, 2021 1 次提交
-
-
由 Tomasz Miąsko 提交于
The storage markers constitute a substantial portion of all MIR statements. At the same time, for builds without any optimizations, the storage markers have no further use during and after MIR optimization phase. If storage markers are not necessary for code generation, remove them.
-