- 26 4月, 2018 1 次提交
-
-
由 Irina Popa 提交于
-
- 18 4月, 2018 1 次提交
-
-
由 Eduard-Mihai Burtescu 提交于
Fixes #50041
-
- 14 3月, 2018 1 次提交
-
-
由 Andrew Cann 提交于
Types will no longer default to `()`, instead always defaulting to `!`. This disables the associated warning and removes the flag from TyTuple
-
- 13 3月, 2018 2 次提交
-
-
由 Niko Matsakis 提交于
Consolidate `trans_apply_param_substs` and `trans_apply_param_substs_env`. Also remove `trans_impl_self_ty`
-
由 Niko Matsakis 提交于
In particular: - `fully_normalize_monormophic_ty` => `normalize_erasing_regions` - `normalize_associated_type_in_env` => `normalize_erasing_regions` - `fully_normalize_associated_types_in` => `normalize_erasing_regions` - `erase_late_bound_regions_and_normalize` => `normalize_erasing_late_bound_regions`
-
- 08 3月, 2018 1 次提交
-
-
由 Oliver Schneider 提交于
-
- 01 3月, 2018 1 次提交
-
-
由 Alex Crichton 提交于
This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups, accidentally running the "abort the program" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics, and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions, it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp, so we'll probably still recommend "don't have destructors on the stack", but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.
-
- 24 1月, 2018 1 次提交
-
-
由 Josh Stone 提交于
We needed to manually added the `DW_OP_deref` ourselves in earlier LLVM, but starting with [D31439] in LLVM 5, it appears that LLVM will always handle this itself. When we were still adding this manually, the resulting `.debug_loc` had too many derefs, and this failed test `debuginfo/by-value-self-argument-in-trait-impl.rs`. [D31439]: https://reviews.llvm.org/D31439 Fixes #47611. cc @alexcrichton r? @michaelwoerister
-
- 20 1月, 2018 1 次提交
-
-
由 Josh Stone 提交于
LLVM <= 4.0 used a non-standard interpretation of `DW_OP_plus`. In the DWARF standard, this adds two items on the expressions stack. LLVM's behavior was more like DWARF's `DW_OP_plus_uconst` -- adding a constant that follows the op. The patch series starting with [D33892] switched to the standard DWARF interpretation, so we need to follow. [D33892]: https://reviews.llvm.org/D33892
-
- 16 1月, 2018 1 次提交
-
-
由 Robin Kruppe 提交于
Closes #47278
-
- 14 1月, 2018 5 次提交
-
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
- 17 12月, 2017 2 次提交
-
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
- 06 12月, 2017 1 次提交
-
-
由 Oliver Schneider 提交于
-
- 02 12月, 2017 2 次提交
-
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
- 19 11月, 2017 13 次提交
-
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
- 26 10月, 2017 1 次提交
-
-
由 Björn Steinbrink 提交于
Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
-
- 18 10月, 2017 1 次提交
-
-
由 Björn Steinbrink 提交于
The extra alloca was only necessary because it made LLVM implicitly handle the necessary deref to get to the actual value. The same happens for indirect arguments that have the byval attribute. But the Rust ABI does not use the byval attribute and so we need to manually add the deref operation to the debuginfo.
-
- 30 8月, 2017 1 次提交
-
-
由 Vadim Petrochenkov 提交于
-
- 16 8月, 2017 1 次提交
-
-
由 Zack M. Davis 提交于
Like #43008 (f6689991), but _much more aggressive_.
-
- 12 8月, 2017 1 次提交
-
-
由 Bastien Orivel 提交于
-
- 28 7月, 2017 2 次提交
-
-
由 Alex Crichton 提交于
-
由 John Kåre Alsaker 提交于
-