Uh oh!
There was an error while loading. Please reload this page.
Compile speed - #8802
Closed
pcwalton wants to merge 13 commits into
Closed
Conversation
They are still present as part of the borrow check.
For example, `foo::<T>::bar::<U>`. This doesn't enforce that the type parameters are in the right positions, however.
…aths. This removes the stacking of type parameters that occurs when invoking trait methods, and fixes all places in the standard library that were relying on it. It is somewhat awkward in places; I think we'll probably want something like the `Foo::<for T>::new()` syntax.
10% win or so for small crates.
This does not implement lazy symbol resolution yet.
This is only for implementations defined in the same crate as the trait they implement.
bors added a commit
that referenced
this pull request
Aug 28, 2013
xFrednet pushed a commit
to xFrednet/rust
that referenced
this pull request
May 21, 2022
… r=llogiq Optionally allow `expect` and `unwrap` in tests This addresses rust-lang#1015, except it makes the new behavior optional. The reason for the msrv-related changes is as follows. Rather than expand `check_methods` list of arguments, it seemed easier to make `check_methods` a method of `Methods`, so that `check_methods` could access `Methods`' fields. `check_methods` had an `msrv` parameter, which I consequently made a field of `Methods`. But, to avoid adding a lifetime parameter to `Methods`, I made the field type `Option<RustcVersion>` instead of the parameter's existing type, `Option<&RustcVersion>`. This seemed sensible since `RustcVersion` implements `Copy`. But this broke a lot of code that expected an `Option<&RustcVersion>` or `&Option<RustcVersion>`. I changed all of those occurrences to `Option<RustcVersion>`. IMHO, the code is better as a result of these changes, though. The msrv-related changes are in their own commit to (hopefully) ease review. Closesrust-lang#1015 changelog: optionally allow `expect` and `unwrap` in tests r? `@llogiq`
U007D pushed a commit
to U007D/rust-mos
that referenced
this pull request
Aug 21, 2026
8802: Keep comments and attrs when extracting struct from enum variant r=Veykril a=DropDemBits Fixesrust-lang#6730 Still unsure if existing visibilities of fields should be forced to pub (which is what was previously done), or if it's okay to keep it in the extracted struct. Co-authored-by: DropDemBits <r3usrlnd@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
r? @brson