- 20 8月, 2019 20 次提交
-
-
由 Simon Sapin 提交于
It was accidentally removed in a rebase of https://github.com/rust-lang/rust/pull/62727 Fixes https://github.com/rust-lang/rust/issues/63729
-
由 bors 提交于
rustc_mir: fix miri substitution/"universe" discipline. Alternative to #61041, based on @RalfJung's own attempt at it. I haven't done a full audit, but I believe everything is fixed now. Fixes #61432. Closes #61336, as a drive-by fix (for a subset of #43408, that is already special-cased). r? @oli-obk / @RalfJung cc @varkor @yodaldevoid
-
由 bors 提交于
Deprecate using rustc_plugin without the rustc_driver dylib. CC https://github.com/rust-lang/rust/pull/59800, https://github.com/rust-lang/rust/commit/7198687bb2df13a3298ef1e8f594753073d6b9e8 Fix https://github.com/rust-lang/rust/issues/62717
-
由 bors 提交于
Rollup of 5 pull requests Successful merges: - #63252 (Remove recommendation about idiomatic syntax for Arc::clone) - #63376 (use different lifetime name for object-lifetime-default elision) - #63620 (Use constraint span when lowering associated types) - #63699 (Fix suggestion from incorrect `move async` to `async move`.) - #63704 ( Fixed: error: unnecessary trailing semicolon) Failed merges: r? @ghost
-
由 Mazdak Farrokhzad 提交于
Fixed: error: unnecessary trailing semicolon
-
由 Mazdak Farrokhzad 提交于
Fix suggestion from incorrect `move async` to `async move`. PR for #61920. Happy with the test. There must be a better implementation though - possibly a MIR visitor to estabilsh a span that doesn't include the `async` keyword?
-
由 Mazdak Farrokhzad 提交于
Use constraint span when lowering associated types Fix #63594. r? @Centril
-
由 Mazdak Farrokhzad 提交于
use different lifetime name for object-lifetime-default elision Introduce a distinct value for `LifetimeName` to use when this is a object-lifetime-default elision. This allows us to avoid creating incorrect lifetime parameters for the opaque types that result. We really need to overhaul this setup at some point! It's getting increasingly byzantine. But this seems like a relatively... surgical fix. r? @cramertj Fixes #62517
-
由 Mazdak Farrokhzad 提交于
Remove recommendation about idiomatic syntax for Arc::clone I believe we should not make this recommendation. I don't want to argue that `Arc::clone` is less idiomatic than `arc.clone`, but that the choice is not clear cut and that we should not be making this kind of call in the docs. The `.clone()` form has advantages too: it is more succinct, it is more likely to be understood by beginners, and it is more uniform with other `clone` calls, indeed with most other method calls. Whichever approach is better, I think that this discussion belongs in a style guide or textbook, rather than the library docs. We don't talk much about idiomatic code in the docs, this place is pretty exceptional. The recommendation is also not followed in this repo. It is hard to figure out how many calls there are of the `.clone()` form, but there are 1550 uses of `Arc` and only 65 uses of `Arc::clone`. The recommendation has existed for over two years. The recommendation was added in https://github.com/rust-lang/rust/pull/42137, as a result of https://github.com/rust-lang/rfcs/pull/1954. However, note that that RFC was closed because it was not necessary to change the docs (the original RFC proposed a new function instead). So I don't think an RFC is necessary here (and I'm not trying to re-litigate the discussion on that RFC (which favoured `Arc::clone` as idiomatic) in any case). cc @nical (who added the docs in the first place; sorry :-) ) r? @alexcrichton (or someone else on @rust-lang/libs )
-
由 Esteban Küber 提交于
-
由 Esteban Küber 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
Currently the default is "inherited" from context, so e.g. `&impl Foo<Item = dyn Bar>` would default to `&'x impl Foo<Item = dyn Bar + 'x>`, but this triggers an ICE and is not very consistent. This patch doesn't implement what I expect would be the correct semantics, because those are likely too complex. Instead, it handles what I'd expect to be the common case -- where the trait has no lifetime parameters.
-
由 Niko Matsakis 提交于
Object-lifetime-default elision is distinct from other forms of elision; it always refers to some enclosing lifetime *present in the surrounding type* (e.g., `&dyn Bar` expands to `&'a (dyn Bar + 'a)`. If there is no enclosing lifetime, then it expands to `'static`. Therefore, in an `impl Trait<Item = dyn Bar>` setting, we don't expand to create a lifetime parameter for the `dyn Bar + 'X` bound. It will just be resolved to `'static`. Annoyingly, the responsibility for this resolution is spread across multiple bits of code right now (`middle::resolve_lifetimes`, `lowering`). The lowering code knows that the default is for an object lifetime, but it doesn't know what the correct result would be. Probably this should be fixed, but what we do now is a surgical fix: we have it generate a different result for elided lifetimes in a object context, and then we can ignore those results when figuring out the lifetimes that are captured in the opaque type.
-
由 Niko Matsakis 提交于
-
由 bors 提交于
Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository, with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo, but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph, it simply reencodes the lock file with a new format.
-
由 Alex Crichton 提交于
This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository, with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo, but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph, it simply reencodes the lock file with a new format.
-
由 Eduard-Mihai Burtescu 提交于
-
由 Giles Cope 提交于
-
- 19 8月, 2019 17 次提交
-
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Ralf Jung 提交于
fix an ICE fix method name
-
由 Baoshan 提交于
Fixed: error: unnecessary trailing semicolon
-
由 bors 提交于
std: Update `backtrace` crate dependency This commit updates the `backtrace` crate from 0.3.34 to 0.3.35. The [included set of changes][changes] for this update mostly includes some gimli-related improvements (not relevant for the standard library) but critically includes a fix for rust-lang/backtrace-rs#230. The standard library will not aqcuire a session-local lock whenever a backtrace is generated on Windows to allow external synchronization with the `backtrace` crate itself, allowing `backtrace` to be safely used while other threads may be panicking. [changes]: https://github.com/rust-lang/backtrace-rs/compare/0.3.34...0.3.35
-
由 Alex Crichton 提交于
This commit updates the `backtrace` crate from 0.3.34 to 0.3.35. The [included set of changes][changes] for this update mostly includes some gimli-related improvements (not relevant for the standard library) but critically includes a fix for rust-lang/backtrace-rs#230. The standard library will not aqcuire a session-local lock whenever a backtrace is generated on Windows to allow external synchronization with the `backtrace` crate itself, allowing `backtrace` to be safely used while other threads may be panicking. [changes]: https://github.com/rust-lang/backtrace-rs/compare/0.3.34...0.3.35
-
由 bors 提交于
Size has a ::zero
-
由 bors 提交于
Don't special case the `Self` parameter by name This results in a couple of small diagnostic regressions. They could be avoided by keeping the special case just for diagnostics, but that seems worse. closes #50125 cc #60869
-
由 bors 提交于
Change the placement of two functions. Right now, the order is as follows: `pop_front()` `push_front()` `push_back()` `pop_back()` `swap_remove_back()` `swap_remove_front()` I believe it would be more natural, and easier to follow, if we place `pop_back()` right after the `pop_front()`, and `swap_remove_back()` after the `swap_remove_front()` like this: `pop_front()` `pop_back()` `push_front()` `push_back()` `swap_remove_front()` `swap_remove_back()` The rest of the documentation (at least in this module) adheres to the same logic, where the 'front' function always precedes its 'back' equivalent.
-
由 Matthew Jasper 提交于
Use this to simplify the object safety code a bit.
-
由 bors 提交于
Improved error message for break in async block Fixes #63391
-
- 18 8月, 2019 3 次提交
-
-
由 bors 提交于
Do not generate allocations for zero sized allocations Alternative to https://github.com/rust-lang/rust/issues/62487 r? @EddyB There are other places where we could do this, too, but that would cause `static FOO: () = ();` to not have a unique address
-
由 Giles Cope 提交于
-
由 bors 提交于
Serialize additional data for procedural macros Split off from #62855 This PR serializes the declaration `Span` and attributes for all procedural macros. This allows Rustdoc to properly render doc comments and source links when performing inlinig procedural macros across crates
-