- 20 8月, 2020 2 次提交
- 19 8月, 2020 8 次提交
-
-
由 Joshua Nelson 提交于
-
由 Joshua Nelson 提交于
-
由 Rich Kadel 提交于
-
由 Bastian Kauschke 提交于
-
由 Bastian Kauschke 提交于
-
由 Bastian Kauschke 提交于
-
由 Tyson Nottingham 提交于
Avoid showing this error where it doesn't make sense by not assuming "and" and "or" were intended to mean "&&" and "||" until after we decide to continue parsing input as an associative expression. Note that the decision of whether or not to continue parsing input as an associative expression doesn't actually depend on this assumption. Fixes #75599
-
由 Josh Stone 提交于
-
- 18 8月, 2020 9 次提交
-
-
由 Guillaume Gomez 提交于
-
由 Ralf Jung 提交于
-
由 Aleksey Kladov 提交于
It has been deny_by_default since 2017 (and warned for some time before that), so it seems reasonable to promote it. The specific technical motivation to do this now is to remove a field from `ParseSess` -- it is a global state, and global state makes extracting libraries annoying. Closes #40107
-
由 Aleksey Kladov 提交于
-
由 Joshua Nelson 提交于
-
由 Austin Lasher 提交于
-
由 Ujjwal Sharma 提交于
-
由 jumbatm 提交于
-
由 jumbatm 提交于
-
- 17 8月, 2020 5 次提交
-
-
由 Oliver Scherer 提交于
-
由 David Wood 提交于
This commit modifies polymorphization's handling of predicates so that if any generic parameter is used in a predicate then all parameters in that predicate are used. Signed-off-by: NDavid Wood <david@davidtw.co>
-
由 5M1Sec 提交于
Change `UnsafetyViolationKind::General` to `UnsafetyViolationKind::GeneralAndConstFn` in check_unsafety.rs Remove unsafe in min_const_fn_unsafe_bad.rs Bless min_const_fn Add the test case from issue 75340 Co-authored-by: Nlzutao <taolzu@gmail.com>
-
由 Esteban Küber 提交于
When a user tries to use a method as if it returned a new value of the same type as its receiver, we will emit a type error. Try to detect this and provide extra explanation that the method modifies the receiver in-place. This has confused people in the wild, like in https://users.rust-lang.org/t/newbie-why-the-commented-line-stops-the-snippet-from-compiling/47322
-
由 Simon Vandel Sillesen 提交于
Implement 'considered equal' for statements, so that for example `_0 = _1` and `discriminant(_0) = discriminant(0)` are considered equal if 0 is a fieldless variant of an enum
-
- 16 8月, 2020 3 次提交
-
-
由 David Wood 提交于
This commit simplifies `is_range_literal` by checking for `QPath::LangItem` containing range-related lang items, rather than using a heuristic. Co-authored-by: NMatthew Jasper <mjjasper1@gmail.com> Signed-off-by: NDavid Wood <david@davidtw.co>
-
由 David Wood 提交于
This commit introduces `QPath::LangItem` to the HIR and uses it in AST lowering instead of constructing a `hir::Path` from a slice of symbols. This might be better for performance, but is also much cleaner as the previous approach is fragile. In addition, it resolves a bug (#61019) where an extern crate imported as "std" would result in the paths created during AST lowering being resolved incorrectly (or not at all). Co-authored-by: NMatthew Jasper <mjjasper1@gmail.com> Signed-off-by: NDavid Wood <david@davidtw.co>
-
由 David Wood 提交于
This commit adds a test for #61019 where a extern crate is imported as `std` which results in name resolution to fail due to the uses of `std` types introduced from lowering. Signed-off-by: NDavid Wood <david@davidtw.co>
-
- 15 8月, 2020 8 次提交
-
-
由 Tomasz Miąsko 提交于
The match branch simplification is applied when target blocks contain statements that are either equal or perform a const bool assignment with different values to the same place. Previously, when constructing new statements, only statements from a single block had been examined. This lead to a misoptimization when statements are equal because the assign the *same* const bool value to the same place. Fix the issue by examining statements from both blocks when deciding on replacement.
-
由 David Wood 提交于
This commit adjusts polymorphization's handling of predicates so that after ensuring that `T` is used in `I: Foo<T>` if `I` is used, it now ensures that `I` is used if `T` is used in `I: Foo<T>`. This is necessary to mark generic parameters that only exist in impl parameters as used - thereby avoiding symbol clashes when using the new mangling scheme. Signed-off-by: NDavid Wood <david@davidtw.co>
-
由 Tomasz Miąsko 提交于
It might be necessary to use its value more than once.
-
由 Esteban Küber 提交于
When encountering multiple non-auto trait bounds suggest creating a new trait and explain what auto-traits are.
-
由 Esteban Küber 提交于
-
由 Matthew Jasper 提交于
-
由 Matthew Jasper 提交于
-
由 Matthew Jasper 提交于
-
- 14 8月, 2020 5 次提交
-
-
由 Rich Kadel 提交于
I found some areas for improvement while attempting to debug the SegFault issue when running rust programs compiled using MSVC, with coverage instrumentation. I discovered that LLVM's coverage writer was generating incomplete function name variable names (that's not a typo: the name of the variable that holds a function name). The existing implementation used one-up numbers to distinguish variables, and correcting the names did not fix the MSVC coverage bug, but the fix in this PR makes the names and resulting LLVM IR easier to follow and more consistent with Clang's implementation. I also changed the way the `-Zinstrument-coverage` option is supported in symbol_export.rs. The original implementation was incorrect, and the corrected version matches the handling for `-Zprofile-generate`, as it turns out. (An argument could be made that maybe `-Zinstrument-coverage` should automatically enable `-Cprofile-generate`. In fact, if `-Cprofile-generate` is analagous to Clang's `-fprofile-generate`, as some documentation implies, Clang always requires this flag for its implementation of source-based code coverage. This would require a little more validation, and if implemented, would probably require updating some of the user-facing messages related to `-Cprofile-generate` to not be so specific to the PGO use case.) None of these changes fixed the MSVC coverage problems, but they should still be welcome improvements. Lastly, I added some additional FIXME comments in instrument_coverage.rs describing issues I found with the generated LLVM IR that would be resolved if the coverage instrumentation is injected with a `Statement` instead of as a new `BasicBlock`. I describe seven advantages of this change, but it requires some discussion before making a change like this.
-
由 Esteban Küber 提交于
-
由 Esteban Küber 提交于
Emit E0288 (lifetime bound for trait object cannot be deduced) only on bare trait objects. When the trait object is in the form of `&dyn Trait`, E0106 (missing lifetime specifier) will have been emitted, making the former redundant.
-
由 kadmin 提交于
This also explicitly checks that the types are `bool`. `try_eval_bool` also appears to just succeed for `u8`, so this ensures that it actually is a bool before casting.
-
由 Esteban Küber 提交于
-