- 30 7月, 2023 15 次提交
-
-
由 bors 提交于
Remove redundant example of `BTreeSet::iter` The usage and that `Values returned by the iterator are returned in ascending order` are already demonstrated by the other example and the description, so I removed the useless one.
-
由 Matthias Krüger 提交于
Mark `lazy_type_alias` as incomplete This feature is very not complete: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AF-lazy_type_alias r? types
-
由 Matthias Krüger 提交于
[rustc][data_structures] Simplify binary_search_slice. Instead of using `binary_search_by_key`, it's possible to use `partition_point` to find the lower bound. This avoids the need to locate the leftmost matching entry separately. It's also possible to use `partition_point` to find the upper bound, so I plan to send a separate PR for your consideration.
-
由 Matthias Krüger 提交于
Rustdoc small cleanups Each commit does some little cleanups: * We had some `Res` comparisons in multiple places (and still do, but unless we use a macro, it's not possible to "merge" any further) so I moved it into a function. * It was weird to have some utils function used everywhere in `visit_ast` so I instead moved it into `clean/utils.rs`. * In HTML rendering, we had some write "issues": * Multiple calls that could be merged into one. * Some `write!` that could be `write_str`. * We didn't use the new `format!` args much. r? `@notriddle`
-
由 bors 提交于
Make RPITITs inherit the `assumed_wf_types` of their parent method ... and then move the RPITIT well-formedness check to just use the regular logic of wfchecking an associated type. --- We need to inherit the `assumed_wf_types` of the RPITIT's parent function in order for the given code to be considered well-formed: ```rust trait Foo { fn bar<'a, T>(_: &'a T) -> impl Iterator<Output = &'a T>; } ``` Since for `&'a T` to be WF, we need `T: 'a`. In order for this to work for late-bound lifetimes, we need to do some additional mapping of any late-bound lifetimes captured by these assumed wf types. This is because within the body of the function (and thus in the `assumed_wf_types`), they're represented as `ReFree` variants of the original late-bound lifetimes declared in the function's generics, but in the RPITIT's GAT, they're represented as "reified" `ReEarlyBound` vars (duplicated during opaque type lowering). Luckily, the mapping between these two is already [stored in the opaque](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.OpaqueTy.html#structfield.lifetime_mapping). Fixes #113796
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 Michael Goulet 提交于
-
由 bors 提交于
Add simd_bswap, simd_bitreverse, simd_ctlz, and simd_cttz intrinsics cc `@workingjubilee`
-
由 bors 提交于
TB: Redefine trigger condition for protectors The Coq formalization revealed that as currently implemented, read accesses did not always commute. Indeed starting from a lazily initialized `Active` protected tag, applying a foreign read then a child read produces `Frozen`, but child read then foreign read triggers UB (because the child read initializes _before_ the `Active -> Frozen`). This reformulation of when protectors trigger fixes that issue: - instead of `Active + foreign read -> Frozen` and `Active -> Frozen` when protected is UB - we do `Active + foreign read -> if protected { Disabled } else { Frozen }` There is already precedent for transitions being dependent on the presence of a protector (`Reserved + foreign read -> if protected { Frozen } else { Reserved }`), and this has the nice side-effect of simplifying the protector trigger condition to just an equality check against `Disabled` since now there is protector UB iff a protected tag becomes `Disabled`. In order not to introduce an extra `if`, it was decided that `Disabled -> Disabled` would be UB when protected, which was not the case previously. This is merely a theoretical for now because a protected `Disabled` is unreachable in the first place. The extra test is not directly related to this modification, but also checks things related to protectors and lazy initialization.
-
由 bors 提交于
Gracefully handle ternary operator Fixes #112578 ~~May not be the best way to do this as it doesn't check for a single `:`, so it could perhaps appear even when the actual issue is just a missing semicolon. May not be the biggest deal, though?~~ Nevermind, got it working properly now ^^
-
由 Neven Villani 提交于
-
- 29 7月, 2023 25 次提交
-
-
由 bors 提交于
Update the minimum external LLVM to 15 With this change, we'll have stable support for LLVM 15 through 17 (pending release). For reference, the previous increase to LLVM 14 was #107573.
-
由 Taras Tsugrii 提交于
-
由 bors 提交于
Refactor + improve diagnostics for `&mut T`/`T` mismatch inside Option/Result Follow up to #114052. This also makes the diagnostics structured + translatable. r? `@WaffleLapkin`
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 bors 提交于
Change LLVM BOLT flags I talked to the BOLT maintainers about the binary size effect of BOLT. Currently, BOLTing LLVM increases its binary size from ~120 MiB to ~170 MiB, which is not ideal. Now we can track both runtime performance and (rustc, LLVM, ...) artifact sizes in perf.RLO, so I'd like to try experimenting with changing the flags to reduce `libLLVM.so` size without regressing the performance gains of BOLT too much. r? `@ghost`
-
由 bors 提交于
Rename and allow `cast_ref_to_mut` lint This PR is a small subset of https://github.com/rust-lang/rust/pull/112431, that is the renaming of the lint (`cast_ref_to_mut` -> `invalid_reference_casting`). BUT also temporarily change the default level of the lint from deny-by-default to allow-by-default until https://github.com/rust-lang/rust/pull/112431 is merged. r? `@Nilstrieb`
-
由 bors 提交于
fix(resolve): update the ambiguity glob binding as warning recursively Fixes #47525 Fixes #56593, but `issue-56593-2.rs` is not fixed to ensure backward compatibility. Fixes #98467 Fixes #105235 Fixes #112713 This PR had added a field called `warn_ambiguous` in `NameBinding` which is only for back compatibly reason and used for lint. More details: https://github.com/rust-lang/rust/pull/112743 r? `@petrochenkov`
-
由 bors 提交于
Rollup of 7 pull requests Successful merges: - #113773 (Don't attempt to compute layout of type referencing error) - #114107 (Prevent people from assigning me as a PR reviewer) - #114124 (tests/ui/proc-macro/*: Migrate FIXMEs to check-pass) - #114171 (Fix switch-stdout test for none unix/windows platforms) - #114172 (Fix issue_15149 test for the SGX target) - #114173 (btree/map.rs: remove "Basic usage" text) - #114174 (doc: replace wrong punctuation mark) r? `@ghost` `@rustbot` modify labels: rollup
-
由 Matthias Krüger 提交于
doc: replace wrong punctuation mark
-
由 Matthias Krüger 提交于
btree/map.rs: remove "Basic usage" text Not useful, for there is just a single example
-
由 Matthias Krüger 提交于
Fix issue_15149 test for the SGX target PR https://github.com/rust-lang/rust/pull/112390 moved tests to std. Unfortunately, this caused the `issue_15149` test to be enabled for the SGX target. This is incorrect as the SGX target does not support the `env::current_exe()` call.
-
由 Matthias Krüger 提交于
Fix switch-stdout test for none unix/windows platforms PR #112390 moved tests to std. Unfortunately, there is a typo which causes issues on platforms other than unix and windows.
-
由 Matthias Krüger 提交于
tests/ui/proc-macro/*: Migrate FIXMEs to check-pass proc-macros are processed early in the compiler pipeline. There is no need to involve codegen. So change to check-pass. I have also looked through each changed test and to me it is sufficiently clear that codegen is not needed for the purpose of the test. I skipped changing `tests/ui/proc-macro/no-missing-docs.rs` in this commit because it was not clear to me that it can be changed to check-pass. Part of #62277
-
由 Matthias Krüger 提交于
Prevent people from assigning me as a PR reviewer depends on https://github.com/rust-lang/triagebot/pull/1712
-
由 Matthias Krüger 提交于
Don't attempt to compute layout of type referencing error Leads to more ICEs and strange diagnostics than are worth it. Fixes #113760
-
由 bors 提交于
make `noop_method_call` warn by default r? `@compiler-errors`
-
由 bors 提交于
Rollup of 7 pull requests Successful merges: - #114099 (privacy: no nominal visibility for assoc fns ) - #114128 (When flushing delayed span bugs, write to the ICE dump file even if it doesn't exist) - #114138 (Adjust spans correctly for fn -> method suggestion) - #114146 (Skip reporting item name when checking RPITIT GAT's associated type bounds hold) - #114147 (Insert RPITITs that were shadowed by missing ADTs that resolve to [type error]) - #114155 (Replace a lazy `RefCell<Option<T>>` with `OnceCell<T>`) - #114164 (Add regression test for `--cap-lints allow` and trait bounds warning) r? `@ghost` `@rustbot` modify labels: rollup
-
由 bors 提交于
Implement generic const items This implements generic parameters and where-clauses on free and associated const items under the experimental feature gate `generic_const_items`. See rust-lang/lang-team#214. Tracking issue: #113521. Fixes #104400. This PR doesn't include rustfmt support as per [nightly style procedure](https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md) and it doesn't add rustdoc JSON support (see [related Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Rustdoc.20JSON.3A.20Experimental.20rustc.20features)). CC `@scottmcm` `@compiler-errors` `@WalterSmuts` r? `@oli-obk` <details><summary>Resolved Questions</summary> * Q: Should `const ADD<const N: usize, const M: usize>: usize = N + M; ADD::<0, 1>` trigger the error *generic parameters may not be used in const operations* (which can be unlocked with `#![feature(generic_const_exprs)]`). Currently it doesn't. Or does this fall under [this paragraph](https://github.com/rust-lang/rust/blob/71f71a5397c42fec01f5c1045c638d961fa9f7ca/compiler/rustc_resolve/src/late.rs#L191)? * A: No, https://github.com/rust-lang/rust/pull/113522#issuecomment-1628634092 * Q: Should `const UNUSED: () = () where String: Copy;` (with `#![feature(trivial_bounds)]` and with `UNUSED` unused) succeed compilation? Currently it doesn't: *evaluation of constant value failed // entering unreachable code* * A: Yes, but postponed until stabilization (latest), https://github.com/rust-lang/rust/pull/113522#issuecomment-1628634092 </details>
-
-
-
-
-
-