- 26 8月, 2021 2 次提交
-
-
由 Léo Lanteri Thauvin 提交于
-
由 Léo Lanteri Thauvin 提交于
-
- 25 8月, 2021 9 次提交
-
-
由 bors 提交于
Don't mark `if_let_guard` as an incomplete feature I don't think there is any reason for `if_let_guard` to be an incomplete feature, and I think the reason they were marked in the first place was simply because they weren't implemented at all. r? `@pnkfelix` cc tracking issue #51114
-
由 bors 提交于
Correctly handle remapping from path containing the current directory with trailing paths If we have a `auxiliary/lib.rs`, and we generate the metadata with `--remap-path-prefix $PWD/auxiliary=xyz`, the path to `$PWD/auxiliary/lib.rs` won't be correctly remapped in the metadata. This is because internally, path to the working directory itself and relative paths to files under the working directory are remapped separately (hence neither are affected since neither has `$PWD/auxiliary` as prefix), but the concatenation between the working directory and the relative path is not remapped. This PR fixes that.
-
由 bors 提交于
Improve detection of generics on lang items Adds detection for the required generics for all lang items. Many lang items require an exact or minimum amount of generic arguments and if they don't exist, the compiler will ICE. This does not add any additional validation about bounds on generics or any other lang item restrictions. Fixes one of the ICEs in #87573 cc `@FabianWolff`
-
由 bors 提交于
Improve liveness analysis for generators Liveness analysis for generators assumes that execution always continues normally after a yield point, not accounting for the fact that generator could be dropped before completion. If generators captures any variables by reference, those variables could be used within a generator, or when the generator completes, but also after each yield point in the case the generator is dropped. Account for the case when generator is dropped after yielding, but before running to the completion. This effectively considers all variables captured by reference to be used after a yield point. Fixes #84292.
-
由 bors 提交于
Use custom wrap-around type instead of RangeInclusive Two reasons: 1. More memory is allocated than necessary for `valid_range` in `Scalar`. The range is not used as an iterator and `exhausted` is never used. 2. `contains`, `count` etc. methods in `RangeInclusive` are doing very unhelpful(and dangerous!) things when used as a wrap-around range. - In general this PR wants to limit potentially confusing methods, that have a low probability of working. Doing a local perf run, every metric shows improvement except for instructions. Max-rss seem to have a very consistent improvement. Sorry - newbie here, probably doing something wrong.
-
由 bors 提交于
2229: Consider varaiables mentioned in closure as used Fixes: https://github.com/rust-lang/project-rfc-2229/issues/57 r? `@nikomatsakis`
-
由 bors 提交于
resolve type variables after checking casts r? `@jackh726` Fixes #87814 Fixes #88118 Supercedes #87879 (cc `@ldm0)`
-
由 Andreas Liljeqvist 提交于
-
由 bors 提交于
Stabilize and document `--force-warn` This PR will stabilize and document the `--force-warn` command line option. It is currently a draft, pending an FCP. I've taken the liberty of tidying up the lint level command line options a bit as part of this. The changes are quite minor and should only affect rustc's help output. I'm making them here because they're trivial and, in one case, necessary to unify the way `--force-warn` with the way the other options are displayed. I also want to mention that `@rylev` has done a ton of work on moving this along and deserves most of the credit. I'm just the one who landed up writing this particular PR. Resolves #86516.
-
- 24 8月, 2021 29 次提交
-
-
由 inquisitivecrystal 提交于
This updates tests to reflect that `force-warn` is now stable.
-
由 inquisitivecrystal 提交于
Co-authored-by: NMark Rousskov <mark.simulacrum@gmail.com>
-
由 inquisitivecrystal 提交于
-
由 inquisitivecrystal 提交于
-
由 bors 提交于
Use bound vars for GAT params in param_env in check_type_bounds Fixes #87429
-
由 Andy Wang 提交于
-
由 bors 提交于
Allow specifying an deployment target version for all iOS llvm targets Closes: https://github.com/rust-lang/rust/issues/79408 This pull requests adds the same procedure to define the iOS-version for the LLVM-target as was used for the simulator target and the desktop target. This then closes the original problem mentioned in the above issue. The problem with incompatible bitcode remains, but is probably not easy fixable. I realised that something is still not right. Try to fix that. r? `@petrochenkov`
-
由 Tomasz Miąsko 提交于
Liveness analysis for generators assumes that execution always continues normally after a yield point, not accounting for the fact that generator could be dropped before completion. If generators captures any variables by reference, those variables could be used within a generator, or when the generator completes, but also after each yield point in the case the generator is dropped. Account for the case when generator is dropped after yielding, but before running to the completion. This effectively considers all variables captured by reference to be used after a yield point.
-
由 Andreas Liljeqvist 提交于
-
由 Patrick Amrein 提交于
-
由 bors 提交于
Remove `Session.used_attrs` and move logic to `CheckAttrVisitor` Instead of updating global state to mark attributes as used, we now explicitly emit a warning when an attribute is used in an unsupported position. As a side effect, we are to emit more detailed warning messages (instead of just a generic "unused" message). `Session.check_name` is removed, since its only purpose was to mark the attribute as used. All of the callers are modified to use `Attribute.has_name` Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed used' attribute is implemented by simply not performing any checks in `CheckAttrVisitor` for a particular attribute. We no longer emit unused attribute warnings for the `#[rustc_dummy]` attribute - it's an internal attribute used for tests, so it doesn't mark sense to treat it as 'unused'. With this commit, a large source of global untracked state is removed.
-
由 bors 提交于
Warn about unreachable code following an expression with an uninhabited type This pull request fixes #85071. The issue is that liveness analysis currently is "smarter" than reachability analysis when it comes to detecting uninhabited types: Unreachable code is detected during type checking, where full type information is not yet available. Therefore, the check for type inhabitedness is quite crude: https://github.com/rust-lang/rust/blob/fc81ad22c453776de16acf9938976930cf8c9401/compiler/rustc_typeck/src/check/expr.rs#L202-L205 i.e. it only checks for `!`, but not other, non-trivially uninhabited types, such as empty enums, structs containing an uninhabited type, etc. By contrast, liveness analysis, which runs after type checking, can benefit from the more sophisticated `tcx.is_ty_uninhabited_from()`: https://github.com/rust-lang/rust/blob/fc81ad22c453776de16acf9938976930cf8c9401/compiler/rustc_passes/src/liveness.rs#L981 https://github.com/rust-lang/rust/blob/fc81ad22c453776de16acf9938976930cf8c9401/compiler/rustc_passes/src/liveness.rs#L996 This can lead to confusing warnings when a variable is reported as unused, but the use of the variable is not reported as unreachable. For instance: ```rust enum Foo {} fn f() -> Foo {todo!()} fn main() { let x = f(); let _ = x; } ``` currently leads to ``` warning: unused variable: `x` --> t1.rs:5:9 | 5 | let x = f(); | ^ help: if this is intentional, prefix it with an underscore: `_x` | = note: `#[warn(unused_variables)]` on by default warning: 1 warning emitted ``` which is confusing, because `x` _appears_ to be used in line 6. With my changes, I get: ``` warning: unreachable expression --> t1.rs:6:13 | 5 | let x = f(); | --- any code following this expression is unreachable 6 | let _ = x; | ^ unreachable expression | = note: `#[warn(unreachable_code)]` on by default note: this expression has type `Foo`, which is uninhabited --> t1.rs:5:13 | 5 | let x = f(); | ^^^ warning: unused variable: `x` --> t1.rs:5:9 | 5 | let x = f(); | ^ help: if this is intentional, prefix it with an underscore: `_x` | = note: `#[warn(unused_variables)]` on by default warning: 2 warnings emitted ``` My implementation is slightly inelegant because unreachable code warnings can now be issued in two different places (during type checking and during liveness analysis), but I think it is the solution with the least amount of unnecessary code duplication, given that the new warning integrates nicely with liveness analysis, where unreachable code is already implicitly detected for the purpose of finding unused variables.
-
由 bors 提交于
Get piece unchecked in `write` We already use specialized `zip`, but it seems like we can do a little better by not checking `pieces` length at all. `Arguments` constructors are now unsafe. So the `format_args!` expansion now includes an `unsafe` block. <details> <summary>Local Bench Diff</summary> ```text name before ns/iter after ns/iter diff ns/iter diff % speedup fmt::write_str_macro1 22,967 19,718 -3,249 -14.15% x 1.16 fmt::write_str_macro2 35,527 32,654 -2,873 -8.09% x 1.09 fmt::write_str_macro_debug 571,953 575,973 4,020 0.70% x 0.99 fmt::write_str_ref 9,579 9,459 -120 -1.25% x 1.01 fmt::write_str_value 9,573 9,572 -1 -0.01% x 1.00 fmt::write_u128_max 176 173 -3 -1.70% x 1.02 fmt::write_u128_min 138 134 -4 -2.90% x 1.03 fmt::write_u64_max 139 136 -3 -2.16% x 1.02 fmt::write_u64_min 129 135 6 4.65% x 0.96 fmt::write_vec_macro1 24,401 22,273 -2,128 -8.72% x 1.10 fmt::write_vec_macro2 37,096 35,602 -1,494 -4.03% x 1.04 fmt::write_vec_macro_debug 588,291 589,575 1,284 0.22% x 1.00 fmt::write_vec_ref 9,568 9,732 164 1.71% x 0.98 fmt::write_vec_value 9,516 9,625 109 1.15% x 0.99 ``` </details>
-
由 Aman Arora 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 jackh726 提交于
-
由 jackh726 提交于
-
由 jackh726 提交于
-
由 bors 提交于
Rollup of 6 pull requests Successful merges: - #87976 (Account for tabs when highlighting multiline code suggestions) - #88174 (Clarify some wording in Rust 2021 lint docs) - #88188 (Greatly improve limitation handling on parallel rustdoc GUI test run) - #88230 (Fix typos “a”→“an”) - #88232 (Add notes to macro-not-found diagnostics to point out how things with the same name were not a match.) - #88259 (Do not mark `-Z thir-unsafeck` as unsound anymore) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
The changes to dumping expressions seem particularly useful
-
由 Niko Matsakis 提交于
-
由 liudingming 提交于
Otherwise, we can get into a situation where you have a subtype obligation `#1 <: #2` pending, #1 is constrained by `check_casts`, but #2` is unaffected. Co-authored-by: NNiko Matsakis <niko@alum.mit.edu>
-
由 Mara Bos 提交于
Do not mark `-Z thir-unsafeck` as unsound anymore The initial implementation of the THIR unsafety checker is now complete (rust-lang/project-thir-unsafeck#7). r? `@oli-obk`
-
由 Mara Bos 提交于
Add notes to macro-not-found diagnostics to point out how things with the same name were not a match. This adds notes like: ``` error: cannot find derive macro `Serialize` in this scope --> $DIR/issue-88206.rs:22:10 | LL | #[derive(Serialize)] | ^^^^^^^^^ | note: `Serialize` is imported here, but it is not a derive macro --> $DIR/issue-88206.rs:17:11 | LL | use hey::{Serialize, Deserialize}; | ^^^^^^^^^ ``` Fixes https://github.com/rust-lang/rust/issues/88206 Includes https://github.com/rust-lang/rust/pull/88229 r? `@estebank`
-
由 Mara Bos 提交于
Fix typos “a”→“an” Fix typos in comments; found using a regex to find some easy instance of incorrect usage of a vs. an. While automation was used to find these, every change was checked manually. Changes in submodules get separate PRs: * https://github.com/rust-lang/stdarch/pull/1201 * https://github.com/rust-lang/cargo/pull/9821 * https://github.com/rust-lang/miri/pull/1874 * https://github.com/rust-lang/rls/pull/1746 * https://github.com/rust-analyzer/rust-analyzer/pull/9984 _folks @ rust-analyzer are fast at merging…_ * https://github.com/rust-analyzer/rust-analyzer/pull/9985 * https://github.com/rust-analyzer/rust-analyzer/pull/9987 * https://github.com/rust-analyzer/rust-analyzer/pull/9989 _For `clippy`, I don’t know if the changes should better better be moved to a PR to the original repo._ <hr> This has some overlap with #88226, but neither is a strict superset of the other. If you want multiple commits, I can split it up; in that case, make sure to suggest a criterion for splitting.
-
由 Mara Bos 提交于
Greatly improve limitation handling on parallel rustdoc GUI test run Follow-up of https://github.com/rust-lang/rust/pull/88082. r? `@dns2utf8`
-
由 Mara Bos 提交于
Clarify some wording in Rust 2021 lint docs Also added some inline code styling.
-