Borrow checking for overloaded indexing #15656
Merged
Conversation
This file contains 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
| @@ -1129,6 +1155,9 @@ impl<'t,TYPER:Typer> MemCategorizationContext<'t,TYPER> { | |||
| } | |||
| _ => { | |||
| match pk { | |||
| Implicit(..) => { | |||
| "dereference (dereference is implict, due to indexing)".to_string() | |||
|
r=me with typo fixed |
bors
added a commit
that referenced
this pull request
Jul 16, 2014
Closes #15525 The important bit of this are the changes from line 445 in mem_categorization.rs. Most of the other changes are about adding an Implicit PointerKind, and this is only necessary for getting a decent error message :-s An alternative would have been to add an implciti/explicit flag to cat_deref, which could be mostly ignored and so would mean much fewer changes. However, the implicit state would only be valid if the PointerKind was BorrowedPtr, so it felt like it ought to be another kind of PointerKind. I still don't know which is the better design.
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 27, 2023
Partially fixes rust-lang#15656 . When a crate graph is extended which is the case when new workspaces are added to the project the rules for deduplication were too strict. One problem that arises from this is that in certain conditions when we see the same crate having different `CrateOrigin`s the first form would be maintained. This approach however results in some unwanted results such as making renaming forbidden as this has been recently only made available for local crates. The given example in rust-lang#15656 can still not be resolved with this PR as that involves taking inconsistencies between dependencies into consideration. This will be addressed in a future PR.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 27, 2023
…ocal_too, r=Veykril fix: Dedup duplicate crates with differing origins in CrateGraph construction Partially fixes rust-lang#15656 . Until now the condition for deduplication in crate graphs were the strict equality of two crates. One problem that arises from this is that in certain conditions when we see the same crate having different `CrateOrigin`s the first occurrence would be kept. This approach however results in some unwanted results such as making renaming forbidden as this has been recently only made available for local crates. The given example in rust-lang#15656 can still not be resolved with this PR as that involves taking inconsistencies between dependencies into consideration. This will be addressed in a future PR.
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 21, 2024
With rust-lang#15656 we started disallowing renaming of non-local items. Although this makes sense there are some false positives that impacted users' workflows. So this config aims to mitigate this by giving users the liberty to disable this feature.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 21, 2024
…onfig, r=Veykril Add a new config to allow renaming of non-local defs With rust-lang#15656 we started disallowing renaming of non-local items. Although this makes sense there are some false positives that impacted users' workflows. So this config aims to mitigate this by giving users the liberty to disable this feature. The reason why this is a draft is that I saw one of the tests fail and I am not sure if the "got" result even syntactically makes sense Test case is : ```rust check( "Baz", r#" //- /lib.rs crate:lib new_source_root:library pub struct S; //- /main.rs crate:main deps:lib new_source_root:local use lib::S$0; "#, "use lib::Baz;" ); ``` ``` Left: use lib::Baz; Right: use lib::Baz;Baz Diff: use lib::Baz;Baz ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #15525
The important bit of this are the changes from line 445 in mem_categorization.rs. Most of the other changes are about adding an Implicit PointerKind, and this is only necessary for getting a decent error message :-s An alternative would have been to add an implciti/explicit flag to cat_deref, which could be mostly ignored and so would mean much fewer changes. However, the implicit state would only be valid if the PointerKind was BorrowedPtr, so it felt like it ought to be another kind of PointerKind. I still don't know which is the better design.