Uh oh!
There was an error while loading. Please reload this page.
rename the Ptr trait to RawPtr - #6913
Merged
Merged
Conversation
flip1995 pushed a commit
to flip1995/rust
that referenced
this pull request
Apr 8, 2021
Destructure args in `methods`
changelog: none
This changes the main pattern in `methods` to match and destructure the method call args at the same time as the method name, and pass individual arg `Expr`s to the lint impls.
```rust
// before
["expect", ..] => expect::check(cx, expr, arg_lists[0]);
// after
("expect", [arg]) => expect::check(cx, expr, recv, arg);
```
This makes the code safer since there is no risk of out of bounds `args[n]` everywhere. There will be no more collecting `method_names`, `arg_lists`, `method_spans` as a separate step - everything comes out of the `match`es. Chained methods are parsed in a nested `match`. This makes the code more verbose in some ways, but IMO it is much easier to follow.
~Definitely should wait for rust-lang#6896. Just putting out the idea.~U007D pushed a commit
to U007D/rust-mos
that referenced
this pull request
Aug 21, 2026
U007D pushed a commit
to U007D/rust-mos
that referenced
this pull request
Aug 21, 2026
7115: Migrate HasSource::source to return Option r=matklad a=nick96 I've made a start on fixing rust-lang#6913 based on the provided work plan, migrating `HasSource::source` to return an `Option`. The simple cases are migrated but there are a few that I'm unsure exactly how they should be handled: - Logging the processing of functions in `AnalysisStatsCmd::run`: In verbose mode it includes the path to the module containing the function and the syntax range. I've handled this with an if-let but would it be better to blow up here with `expect`? I'm not 100% on the code paths but if we're processing a function definition then the source should exist. I've handled `source()` in all code paths as `None` being a valid return value but are there some cases where we should just blow up? Also, all I've done is bubble up the returned `None`s, there may be some places where we can recover and still provide something. Co-authored-by: Nick Spain <nicholas.spain@stileeducation.com> Co-authored-by: Nick Spain <nicholas.spain96@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
2 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.
Closes#6607
I went with
RawPtrinstead ofUnsafePtrbecause not all of these operations areunsafe, so to me it makes more sense to refer to it as a "raw" (not wrapped/abstracted) pointer. If we decide on something else in #6608 it can be renamed again.