Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 4 pull requests #97591

Closed
wants to merge 9 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

CAD97 and others added 9 commits May 23, 2022 09:20
As currently written, when a logic error occurs in a collection's trait
parameters, this allows *completely arbitrary* misbehavior, so long as
it does not cause undefined behavior in std. However, because the extent
of misbehavior is not specified, it is allowed for *any* code in std to
start misbehaving in arbitrary ways which are not formally UB; consider
the theoretical example of a global which gets set on an observed logic
error. Because the misbehavior is only bound by not resulting in UB from
safe APIs and the crate-level encapsulation boundary of all of std, this
makes writing user unsafe code that utilizes std theoretically
impossible, as it now relies on undocumented QOI that unrelated parts of
std cannot be caused to misbehave by a misuse of std::collections APIs.

In practice, this is a nonconcern, because std has reasonable QOI and an
implementation that takes advantage of this freedom is essentially a
malicious implementation and only compliant by the most langauage-lawyer
reading of the documentation.

To close this hole, we just add a small clause to the existing logic
error paragraph that ensures that any misbehavior is limited to the
collection which observed the logic error, making it more plausible to
prove the soundness of user unsafe code.

This is not meant to be formal; a formal refinement would likely need to
mention that values derived from the collection can also misbehave after a
logic error is observed, as well as define what it means to "observe" a
logic error in the first place. This fix errs on the side of informality
in order to close the hole without complicating a normal reading which
can assume a reasonable nonmalicious QOI.

See also [discussion on IRLO][1].

[1]: https://internals.rust-lang.org/t/using-std-collections-and-unsafe-anything-can-happen/16640
A pointer to address cast are often special-cased.
Introduce a dedicated cast kind to make them easy distinguishable.
Linux's `checkpatch.pl` reports:

```txt
rust-lang#42544: FILE: rust/alloc/vec/mod.rs:2692:
WARNING: Possible repeated word: 'to'
+            // - Elements are :Copy so it's OK to to copy them, without doing
```

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Put a bound on collection misbehavior

As currently written, when a logic error occurs in a collection's trait parameters, this allows *completely arbitrary* misbehavior, so long as it does not cause undefined behavior in std. However, because the extent of misbehavior is not specified, it is allowed for *any* code in std to start misbehaving in arbitrary ways which are not formally UB; consider the theoretical example of a global which gets set on an observed logic error. Because the misbehavior is only bound by not resulting in UB from safe APIs and the crate-level encapsulation boundary of all of std, this makes writing user unsafe code that utilizes std theoretically impossible, as it now relies on undocumented QOI (quality of implementation) that unrelated parts of std cannot be caused to misbehave by a misuse of std::collections APIs.

In practice, this is a nonconcern, because std has reasonable QOI and an implementation that takes advantage of this freedom is essentially a malicious implementation and only compliant by the most langauage-lawyer reading of the documentation.

To close this hole, we just add a small clause to the existing logic error paragraph that ensures that any misbehavior is limited to the collection which observed the logic error, making it more plausible to prove the soundness of user unsafe code.

This is not meant to be formal; a formal refinement would likely need to mention that values derived from the collection can also misbehave after a logic error is observed, as well as define what it means to "observe" a logic error in the first place. This fix errs on the side of informality in order to close the hole without complicating a normal reading which can assume a reasonable nonmalicious QOI.

See also [discussion on IRLO][1].

[1]: https://internals.rust-lang.org/t/using-std-collections-and-unsafe-anything-can-happen/16640

r? rust-lang/libs-api ``@rustbot`` label +T-libs-api -T-libs

This technically adds a new guarantee to the documentation, though I argue as written it's one already implicitly provided.
alloc: remove repeated word in comment

Linux's `checkpatch.pl` reports:

```txt
rust-lang#42544: FILE: rust/alloc/vec/mod.rs:2692:
WARNING: Possible repeated word: 'to'
+            // - Elements are :Copy so it's OK to to copy them, without doing
```

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
…rrors

Add regression test for rust-lang#71546

Closes rust-lang#71546
r? `@compiler-errors`
…-obk

Add a pointer to address cast kind

A pointer to address cast are often special-cased. Introduce a dedicated cast kind to make them easy distinguishable.
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels May 31, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=4

@bors
Copy link
Contributor

bors commented May 31, 2022

📌 Commit c7dd5bc has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label May 31, 2022
@bors
Copy link
Contributor

bors commented May 31, 2022

⌛ Testing commit c7dd5bc with merge 83477a9c08131a77b51ac0d632635682be91bf9e...

@bors
Copy link
Contributor

bors commented May 31, 2022

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 31, 2022
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-nopt failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [ui (nll)] src/test/ui/borrowck/issue-71546.rs stdout ----
diff of stderr:

- error[E0310]: the associated type `<&'a V as IntoIterator>::Item` may not live long enough
+ error: higher-ranked lifetime error
3    |
4 LL |       let csv_str: String = value


7 LL | |         .map(|elem| elem.to_string())
9    |
9    |
-    = help: consider adding an explicit lifetime bound `<&'a V as IntoIterator>::Item: 'static`...
-    = note: ...so that the type `<&'a V as IntoIterator>::Item` will meet its required lifetime bounds...
- note: ...that is required by this bound
-   --> $DIR/issue-71546.rs:7:55
+    = note: could not prove for<'r> [closure@$DIR/issue-71546.rs:11:14: 11:37] well-formed
+ error: higher-ranked lifetime error
+   --> $DIR/issue-71546.rs:9:27
14    |
14    |
- LL |     for<'a> <&'a V as IntoIterator>::Item: ToString + 'static,
+ LL |       let csv_str: String = value
+    |  ___________________________^
+ LL | |         .into_iter()
+ LL | |         .into_iter()
+ LL | |         .map(|elem| elem.to_string())
+    |
+    |
+    = note: could not prove for<'r, 's> Map<<&'r V as IntoIterator>::IntoIter, [closure@$DIR/issue-71546.rs:11:14: 11:37]> well-formed
- error: aborting due to previous error
+ error: higher-ranked lifetime error
+   --> $DIR/issue-71546.rs:9:27
+    |
+    |
+ LL |       let csv_str: String = value
+    |  ___________________________^
+ LL | |         .into_iter()
+ LL | |         .map(|elem| elem.to_string())
+ LL | |         .collect::<String>();
+    |
+    |
+    = note: could not prove for<'r, 's> Map<<&'r V as IntoIterator>::IntoIter, [closure@$DIR/issue-71546.rs:11:14: 11:37]> well-formed
- For more information about this error, try `rustc --explain E0310`.
+ error: higher-ranked lifetime error
+   --> $DIR/issue-71546.rs:11:14
+    |
+    |
+ LL |         .map(|elem| elem.to_string())
+    |
+    |
+    = note: could not prove for<'a> <&'a V as IntoIterator>::Item: 'static
+ error: higher-ranked lifetime error
+   --> $DIR/issue-71546.rs:12:10
+    |
+    |
+ LL |         .collect::<String>();
+ 
+ error: aborting due to 5 previous errors
+ 
21 
21 


The actual stderr differed from the expected stderr.
Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/borrowck/issue-71546.nll/issue-71546.nll.stderr
To only update this specific test, also pass `--test-args borrowck/issue-71546.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
status: exit status: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/borrowck/issue-71546.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/borrowck/issue-71546.nll" "-Zborrowck=mir" "-A" "unused" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/borrowck/issue-71546.nll/auxiliary"
stdout: none
--- stderr -------------------------------
error: higher-ranked lifetime error
   |
   |
LL |       let csv_str: String = value //~ ERROR: the associated type `<&'a V as IntoIterator>::Item` may not live long enough
LL | |         .into_iter()
LL | |         .into_iter()
LL | |         .map(|elem| elem.to_string())
   |
   |
   = note: could not prove for<'r> [closure@/checkout/src/test/ui/borrowck/issue-71546.rs:11:14: 11:37] well-formed
error: higher-ranked lifetime error
  --> /checkout/src/test/ui/borrowck/issue-71546.rs:9:27
   |
   |
LL |       let csv_str: String = value //~ ERROR: the associated type `<&'a V as IntoIterator>::Item` may not live long enough
LL | |         .into_iter()
LL | |         .into_iter()
LL | |         .map(|elem| elem.to_string())
   |
   |
   = note: could not prove for<'r, 's> Map<<&'r V as IntoIterator>::IntoIter, [closure@/checkout/src/test/ui/borrowck/issue-71546.rs:11:14: 11:37]> well-formed
error: higher-ranked lifetime error
  --> /checkout/src/test/ui/borrowck/issue-71546.rs:9:27
   |
   |
LL |       let csv_str: String = value //~ ERROR: the associated type `<&'a V as IntoIterator>::Item` may not live long enough
LL | |         .into_iter()
LL | |         .into_iter()
LL | |         .map(|elem| elem.to_string())
LL | |         .collect::<String>();
   | |____________________________^
Some tests failed in compiletest suite=ui compare_mode=Nll mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu
   |
   = note: could not prove for<'r, 's> Map<<&'r V as IntoIterator>::IntoIter, [closure@/checkout/src/test/ui/borrowck/issue-71546.rs:11:14: 11:37]> well-formed
error: higher-ranked lifetime error
  --> /checkout/src/test/ui/borrowck/issue-71546.rs:11:14
   |
   |
LL |         .map(|elem| elem.to_string())
   |
   |
   = note: could not prove for<'a> <&'a V as IntoIterator>::Item: 'static
error: higher-ranked lifetime error
  --> /checkout/src/test/ui/borrowck/issue-71546.rs:12:10
   |
   |
LL |         .collect::<String>();

error: aborting due to 5 previous errors
------------------------------------------

@matthiaskrgr matthiaskrgr deleted the rollup-0pr9wue branch July 30, 2022 10:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants