- 31 12月, 2020 1 次提交
-
-
由 bors 提交于
Fixes #61592
-
- 21 12月, 2020 34 次提交
-
-
由 bors 提交于
Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749, accidentally, the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec<i32> = Vec::new(); pub const fn bar() -> [Vec<i32>; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast, if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY,).0`), this would have failed. We could take back this stabilization as it was clearly accidental. However, I propose we instead just officially accept this and stabilize a small subset of RFC 2203, while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)), so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities, does not rely on promotion, and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them, possibly using associated consts if generics are involved). Well, I said "no semantic ambiguities", that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]`, or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor, it should run in the former case (but currently doesn't, due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all, the `let`-expansion does *not* work in general, for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147
-
由 bors 提交于
Fix pretty printing an AST representing `&(mut ident)` The PR fixes a misguiding help diagnostic in the parser that I reported in #80186. I discovered that the parsers recovery and reporting logic was correct but the pretty printer produced wrong code for the example. (Details in https://github.com/rust-lang/rust/issues/80186#issuecomment-748498676) Example: ```rust #![allow(unused_variables)] fn main() { let mut &x = &0; } ``` The AST fragment `PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..), Mutability::Not)` was printed to be `&mut ident`. But this wouldn't round trip through parsing again, because then it would be: `PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Not), ..), Mutability::Mut)` Now the pretty-printer prints `&(mut ident)`. Reparsing that code results in the AST fragment `PatKind::Ref(PatKind::Paren(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..)), Mutability::Not)` which I think should behave like the original pattern. Old diagnostic: ``` error: `mut` must be attached to each individual binding --> src/main.rs:3:9 | 3 | let mut &x = &0; | ^^^^^^ help: add `mut` to each binding: `&mut x` | = note: `mut` may be followed by `variable` and `variable @ pattern` ``` New diagnostic: ``` error: `mut` must be attached to each individual binding --> src/main.rs:3:9 | 3 | let mut &x = &0; | ^^^^^^ help: add `mut` to each binding: `&(mut x)` | = note: `mut` may be followed by `variable` and `variable @ pattern` ``` Fixes #80186
-
由 bors 提交于
impl Default for LangString, replacing all_false by default Fix #80015 `@rustbot` label C-cleanup T-rustdoc A-markdown-parsing
-
由 bors 提交于
Rollup of 11 pull requests Successful merges: - #80159 (Add array search aliases) - #80166 (Edit rustc_middle docs) - #80170 (Fix ICE when lookup method in trait for type that have bound vars) - #80171 (Edit rustc_middle::ty::TyKind docs) - #80199 (also const-check FakeRead) - #80211 (Handle desugaring in impl trait bound suggestion) - #80236 (Use pointer type in AtomicPtr::swap implementation) - #80239 (Update Clippy) - #80240 (make sure installer only creates directories in DESTDIR) - #80244 (Cleanup markdown span handling) - #80250 (Minor cleanups in LateResolver) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
由 Dylan DPC 提交于
Minor cleanups in LateResolver - Avoid calculating hash twice - Avoid creating a closure in every iteration of a loop - Reserve space for path in advance - Some readability changes
-
由 Dylan DPC 提交于
Cleanup markdown span handling 1. Get rid of `locate()` in markdown handling This function was unfortunate for several reasons: - It used `unsafe` because it wanted to tell whether a string came from the same *allocation* as another, not just whether it was a textual match. - It recalculated spans even though they were already available from pulldown - It sometimes *failed* to calculate the span, which meant it was always possible for the span to be `None`, even though in practice that should never happen. This has several cleanups: - Make the span required - Pass through the span from pulldown in the `HeadingLinks` and `Footnotes` iterators - Only add iterator bounds on the `impl Iterator`, not on `new` and the struct itself. 2. Remove unnecessary scope in `markdown_links` I recommend reading a single commit at a time. cc ``@bugadani`` - this will conflict with https://github.com/rust-lang/rust/pull/77859, I'll try to make sure that gets merged first.
-
由 Dylan DPC 提交于
make sure installer only creates directories in DESTDIR Fixes #80238 Signed-off-by: NYuxuan Shui <yshuiv7@gmail.com>
-
由 Dylan DPC 提交于
Update Clippy Biweekly Clippy update. r? ``@Manishearth``
-
由 Dylan DPC 提交于
Use pointer type in AtomicPtr::swap implementation Closes #80234.
-
由 Dylan DPC 提交于
Handle desugaring in impl trait bound suggestion Fixes #79843. When an associated type of a generic function parameter needs extra bounds, the diagnostics may suggest replacing an `impl Trait` with a named type parameter so that it can be referenced in the where clause. On stable and nightly, the suggestion can be malformed, for instance transforming: ```rust async fn run(_: &(), foo: impl Foo) -> std::io::Result<()> ``` Into: ```rust async fn run(_: &, F: Foo(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send ^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Where we want something like: ```rust async fn run<F: Foo>(_: &(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send ^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` The problem is that the elided lifetime of `&()` is added as a generic parameter when desugaring the async fn; the suggestion code sees this as an existing generic parameter and tries to use its span as an anchor to inject `F` into the parameter list. There doesn't seem to be an entirely principled way to check which generic parameters in the HIR were explicitly named in the source, so this commit changes the heuristics when generating the suggestion to only consider type parameters whose spans are contained within the span of the `Generics` when determining how to insert an additional type parameter into the declaration. (And to be safe it also excludes parameters whose spans are marked as originating from desugaring, although that doesn't seem to handle this elided lifetime.)
-
由 Dylan DPC 提交于
also const-check FakeRead We need to const-check all statements, including `FakeRead`, to avoid issues like https://github.com/rust-lang/rust/issues/77694. Fixes https://github.com/rust-lang/rust/issues/77694. r? ``@oli-obk``
-
由 Dylan DPC 提交于
Edit rustc_middle::ty::TyKind docs - Add a definition for this enum. - Fix typo and missing punctuation. - Spell out "algebraic data type".
-
由 Dylan DPC 提交于
Fix ICE when lookup method in trait for type that have bound vars Closes #77910
-
由 Dylan DPC 提交于
Edit rustc_middle docs Re-word doc comment for rustc_middle::hir::place::Projection. Also adds: - Missing end stop punctuation, and - Documentation links to `rustc_middle::mir::Place`.
-
由 Dylan DPC 提交于
Add array search aliases Missed this in https://github.com/rust-lang/rust/pull/80068. This one will really fix https://github.com/rust-lang/rust/issues/46075. The last alias especially I'm a little unsure about - maybe fuzzy search should be fixed in rustdoc instead? Happy to make that change although I'd have to figure out how. r? ``@m-ou-se`` although cc ``@GuillaumeGomez`` for the search issue.
-
由 bors 提交于
Fix failing build of std on armv5te-unknown-linux-uclibceabi due to missing cmsg_len_zero I'm getting the following error when trying to build `std` on `armv5te-unknown-linux-uclibceabi`: ``` error[E0425]: cannot find value `cmsg_len_zero` in this scope --> /home/operutka/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/ext/net/ancillary.rs:376:47 | 376 | let data_len = (*cmsg).cmsg_len - cmsg_len_zero; | ^^^^^^^^^^^^^ not found in this scope ``` Obviously, this branch: ```rust cfg_if::cfg_if! { if #[cfg(any(target_os = "android", all(target_os = "linux", target_env = "gnu")))] { let cmsg_len_zero = libc::CMSG_LEN(0) as libc::size_t; } else if #[cfg(any( target_os = "dragonfly", target_os = "emscripten", target_os = "freebsd", all(target_os = "linux", target_env = "musl",), target_os = "netbsd", target_os = "openbsd", ))] { let cmsg_len_zero = libc::CMSG_LEN(0) as libc::socklen_t; } } ``` does not cover the case `all(target_os = "linux", target_env = "uclibc")`.
-
由 Dániel Buga 提交于
-
由 Dániel Buga 提交于
-
由 Dániel Buga 提交于
-
由 Joshua Nelson 提交于
-
由 Dániel Buga 提交于
-
由 Dániel Buga 提交于
-
由 Dániel Buga 提交于
-
由 Dániel Buga 提交于
-
由 Joshua Nelson 提交于
-
由 Joshua Nelson 提交于
This function was unfortunate for several reasons: - It used `unsafe` because it wanted to tell whether a string came from the same *allocation* as another, not just whether it was a textual match. - It recalculated spans even though they were already available from pulldown - It sometimes *failed* to calculate the span, which meant it was always possible for the span to be `None`, even though in practice that should never happen. This commit has several cleanups: - Make the span required - Pass through the span from pulldown in the `HeadingLinks` and `Footnotes` iterators - Only add iterator bounds on the `impl Iterator`, not on `new` and the struct itself.
-
由 bors 提交于
Turn quadratic time on number of impl blocks into linear time Previously, if you had a lot of inherent impl blocks on a type like: ```Rust struct Foo; impl Foo { fn foo_1() {} } // ... impl Foo { fn foo_100_000() {} } ``` The compiler would be very slow at processing it, because an internal algorithm would run in O(n^2), where n is the number of impl blocks. Now, we add a new algorithm that allocates but is faster asymptotically. Comparing rustc nightly with a local build of rustc as of this PR (results in seconds): | N | real time before | real time after | | - | - | - | | 4_000 | 0.57 | 0.46 | | 8_000 | 1.31 | 0.84 | | 16_000 | 3.56 | 1.69 | | 32_000 | 10.60 | 3.73 | I've tuned up the numbers to make the effect larger than the startup noise of rustc, but the asymptotic difference should hold for smaller n as well. Note: current state of the PR omits error messages if there are other errors present already. For now, I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!
-
由 pierwill 提交于
Re-word doc comment for rustc_middle::hir::place::Projection. Also adds: - Missing end stop punctuation, and - Documentation links to `rustc_middle::mir::Place`.
-
由 Yuxuan Shui 提交于
Fixes #80238 Signed-off-by: NYuxuan Shui <yshuiv7@gmail.com>
-
由 pierwill 提交于
- Add a definition for this enum. - Fix typo and missing punctuation. - Spell out "algebraic data type".
-
由 bors 提交于
Mark `-1` as an available niche for file descriptors Based on discussion from <https://internals.rust-lang.org/t/can-the-standard-library-shrink-option-file/12768>, the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen, particularly on Linux, but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the "upper" bound, which is actually -1, to be expressed in two's complement.
-
由 ldm0 提交于
-
由 flip1995 提交于
-
- 20 12月, 2020 5 次提交