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

Suggest ?Sized when applicable for ADTs #73261

Merged
merged 4 commits into from
Jun 20, 2020
Merged

Conversation

estebank
Copy link
Contributor

@estebank estebank commented Jun 12, 2020

Address #71790, fix #27964.

@rust-highfive
Copy link
Collaborator

r? @matthewjasper

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 12, 2020
@estebank
Copy link
Contributor Author

cc @lcnr

@estebank

This comment has been minimized.

@estebank
Copy link
Contributor Author

r? @nikomatsakis

Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you test the example I gave?

hir::intravisit::NestedVisitorMap::None
}

fn visit_ty(&mut self, ty: &hir::Ty<'_>) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, this analysis doesn't seem right. For example, consider an example like this:

struct Foo<T> {
    x: Vec<T>, // requires `T: Sized`
    y: Box<T>, // does not require `T: Sized`
}

if I'm reading the code correctly, it is going to highlight both of those uses of T?

Doing this correctly is going to be a touch tricky at least, but we could make it more precise in various ways. For example, we could go over the list of fields and look at their Ty<'tcx> type to see if its WF conditions require that T: Sized, and only then walk over the HIR for the type.

Copy link
Contributor Author

@estebank estebank Jun 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We now only point at the uses of T when it is bare, otherwise we assume that they allow ?Sized. That example will suggest T: ?Sized:

error[E0277]: the size for values of type `T` cannot be known at compilation time
 --> file6.rs:6:21
  |
1 | struct Foo<T> {
  |            - required by this bound in `Foo`
...
6 | struct X<T: ?Sized>(Foo<T>);
  |          -          ^^^^^^ doesn't have a size known at compile-time
  |          |
  |          this type parameter needs to be `std::marker::Sized`
  |
  = help: the trait `std::marker::Sized` is not implemented for `T`
  = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
help: consider relaxing the implicit `Sized` restriction
  |
1 | struct Foo<T: ?Sized> {
  |             ^^^^^^^^

When applying it you get

error[E0277]: the size for values of type `T` cannot be known at compilation time
   --> file6.rs:2:5
    |: aborting due to previous error
1   | struct Foo<T: ?Sized> {
    |            - this type parameter needs to be `std::marker::Sized`
2   |     x: Vec<T>,
    |     ^^^^^^^^^ doesn't have a size known at compile-time
    |
    = help: the trait `std::marker::Sized` is not implemented for `T`
    = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>

I am indeed not verifying whether Vec or Box have a T: ?Sized or T: Sized constraint. That would be a good thing to add, but I feel that the current behavior is good enough before adding more code to probe Vec and Box to identify what their bounds are.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK -- can you maybe add some comments into the code explaining that a bit? i.e., what is the goal of this visitor and can you clarify where it makes 'safe assumptions'?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment.

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Jun 19, 2020

📌 Commit 40b27ff has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 19, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 19, 2020
…arth

Rollup of 13 pull requests

Successful merges:

 - rust-lang#71568 (Document unsafety in slice/sort.rs)
 - rust-lang#72709 (`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc)
 - rust-lang#73214 (Add asm!() support for hexagon)
 - rust-lang#73248 (save_analysis: improve handling of enum struct variant)
 - rust-lang#73257 (ty: projections in `transparent_newtype_field`)
 - rust-lang#73261 (Suggest `?Sized` when applicable for ADTs)
 - rust-lang#73300 (Implement crate-level-only lints checking.)
 - rust-lang#73334 (Note numeric literals that can never fit in an expected type)
 - rust-lang#73357 (Use `LocalDefId` for import IDs in trait map)
 - rust-lang#73364 (asm: Allow multiple template string arguments; interpret them as newline-separated)
 - rust-lang#73382 (Only display other method receiver candidates if they actually apply)
 - rust-lang#73465 (Add specialization of `ToString for char`)
 - rust-lang#73489 (Refactor hir::Place)

Failed merges:

r? @ghost
@bors bors merged commit 4910206 into rust-lang:master Jun 20, 2020
@cuviper cuviper added this to the 1.46 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Note where implicit Sized requirement comes from
6 participants