Very confusing error on attempt to pass path::Path by value

[kmcallister]

use std::path::Path;

fn f(p: Path) { }

produces

foo.rs:3:6: 3:7 error: the trait `core::marker::Sized` is not implemented for the type `[u8]` [E0277]
foo.rs:3 fn f(p: Path) { }
              ^
foo.rs:3:6: 3:7 note: `[u8]` does not have a constant size known at compile-time
foo.rs:3 fn f(p: Path) { }
              ^

We should give an explicit hint that Path should be passed by reference. Also the error does not mention Path and the type u8 does not appear in the program.

UPDATE: The message now includes a full stack trace of types, but it would be better to start out with the type the user knows about (Path, in this case) and only discuss [u8] last. -- @nikomatsakis

[brson]

I've hit this too and was completely baffled about what the compiler was saying.

[Byron]

Same here, this was my code:

pub fn assure_config_dir_exists(dir: &str) -> Result<Path, ArgumentError> {
    Ok(Path::new(dir))
}

This works. Something that I didn't expect is that Path::new(...) returns a borrow.

pub fn assure_config_dir_exists(dir: &str) -> Result<&Path, ArgumentError> {
    Ok(Path::new(dir))
}

[marcusklaas]

Can confirm that this behaviour is still present in rustc 1.2.0-nightly (9cb7b3ffb 2015-06-01) (built 2015-06-01).

[fcourchesne]

Confirmed in rustc 1.0 and 1.2.0-nightly (613e57b 2015-06-01) (built 2015-06-02).

[luke-gru]

I just hit this and was confused as well. rustc 1.2.0-nightly (c6b148337 2015-06-12)

[aturon]

Nominating. This seems like an important error to try to improve.

triage: I-nominated

[arielb1]

The issue here is how we report errors on trait-matching in the presence of nested obligations - we report the predicate that failed to shallowly match and not the original obligation. We essentially have:

struct Path([u8]);

unsafe impl Sized for Path where foreach_field!(_: T in Struct, T: Sized) {}
// expanded:
unsafe impl Sized for Path where [u8]: Sized {}

and we require that Path: Sized - which then requires [u8]: Sized, which doesn't hold.

[nikomatsakis]

All right, I'll give it P-high. I've been thinking of tackling this issue that @arielb1 is describing as part of another change. This is kind of a dup but I'm going to keep it separate.

triage: P-high

[liigo]

Does #26617 fix this issue?

[arielb1]

@liigo

No it doesn't

[arielb1]

On the other hand, just calling note_obligation_cause after displaying the report_on_unimplemented error gives this nice error:

test.rs:3:6: 3:7 error: the trait `core::marker::Sized` is not implemented for the type `[u8]` [E0277]
test.rs:3 fn f(p: Path) {}
               ^
test.rs:3:6: 3:7 help: run `rustc --explain E0277` to see a detailed explanation
test.rs:3:6: 3:7 note: `[u8]` does not have a constant size known at compile-time
test.rs:3 fn f(p: Path) {}
               ^
test.rs:3:6: 3:7 note: required because it appears within the type `std::sys::os_str::Slice`
test.rs:3 fn f(p: Path) {}
               ^
test.rs:3:6: 3:7 note: required because it appears within the type `std::ffi::os_str::OsStr`
test.rs:3 fn f(p: Path) {}
               ^
test.rs:3:6: 3:7 note: required because it appears within the type `std::path::Path`
test.rs:3 fn f(p: Path) {}
               ^
test.rs:3:6: 3:7 note: all local variables must have a statically known size
test.rs:3 fn f(p: Path) {}
               ^

I am semi-worried about a deep chain of types filling the screen with an error, not sure what to do about that.

[Diggsey]

Here's a possible set of rules to follow which would fix the problem:

1. Is the !Sized type derived from a type parameter? If so, treat the type parameter as the source of the error.
2. Is the !Sized field accessible? If so, treat the field as the source of the error (as it does currently)
3. Otherwise, treat the entire type as an opaque, !Sized type which is the source of the error.

This avoids breaking encapsulation: outside its own module it becomes impossible to tell from an error message that a Path is represented as a [u8] - for all intents and purposes it's a new unsized type, unrelated to any others.

[marcusklaas]

Has this really been fixed? It looks like the error was cleaned up a bit, but it still states that [u8] is unsized, instead of Path..

[Diggsey]

@marcusklaas It should now list all of the steps which result in the Sized bound being violated, including both Path and [u8]

[aturon]

This is definitely an improvement, but the order of information still seems backwards to me: I feel like I want to see first that Path isn't sized -- which is the immediate problem -- and then a kind of "backtrace" for why Path isn't sized. Starting off with the inner reason (about [u8] here) makes it very confusing at first, even if all of the needed information is there.

cc @nikomatsakis

[nikomatsakis]

@aturon

Starting off with the inner reason (about [u8] here) makes it very confusing at first, even if all of the needed information is there.

Hmm, I see your point. The current message reflects more how the compiler operators internally than the mental model of the user. We could invert the message, I imagine, though what I'd really prefer to do is to keep more information than we have now (which @jroesch has been working on) in terms of keeping the full "obligation stack". But in any case that if we wanted to invert the stack trace I imagine we could, with a little bit of legwork. I'd be happy to mentor this. I'll re-open for now.

[suesslin]

With the latest version of Rust.

error[E0277]: the trait bound `[u8]: std::marker::Sized` is not satisfied
 --> src/logic.rs:5:5
  |
5 |     product_path: Path,
  |     ^^^^^^^^^^^^^^^^^^ the trait `std::marker::Sized` is not implemented for `[u8]`
  |
  = note: `[u8]` does not have a constant size known at compile-time
  = note: required because it appears within the type `std::path::Path`
  = note: only the last field of a struct may have a dynamically sized type

[VersBinarii]

+1
This still appears to be an issue:

error[E0277]: the trait bound `[u8]: std::marker::Sized` is not satisfied in `std::path::Path`
 --> src/main.rs:8:5
  |
8 |     scan_dir: Path,
  |     ^^^^^^^^^^^^^^ `[u8]` does not have a constant size known at compile-time
  |
  = help: within `std::path::Path`, the trait `std::marker::Sized` is not implemented for `[u8]`
  = note: required because it appears within the type `std::path::Path`
  = note: only the last field of a struct may have a dynamically sized type

[estebank]

Reopening as the output is still confusing.

[sourcepirate]

Is there any updates on this one ?

[estebank]

@sourcepirate I do not believe anyone has tried to address this recently.

[estebank]

Current output

error[E0277]: the size for values of type `[u8]` cannot be known at compilation time
 --> src/lib.rs:3:6
  |
3 | fn f(p: Path) { }
  |      ^ borrow the `Path` instead
  |
  = help: within `std::path::Path`, the trait `std::marker::Sized` is not implemented for `[u8]`
  = note: to learn more, visit <https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
  = note: required because it appears within the type `std::path::Path`
  = note: all local variables must have a statically known size
  = help: unsized locals are gated as an unstable feature

[marcusklaas]

The current output looks pretty great. Explains what the error is, where it's coming from and how to fix it.

[erayerdin]

The issue is still present. I have a simple struct as below:

pub struct Paths {
    home_config_path: Path,  // "Path" is underlined red
    local_config_path: Path,
    log_path: Path,
}

I use VSCode with rust-analyzer and it complains saying:

the size for values of type `[u8]` cannot be known at compilation time
within `Path`, the trait `Sized` is not implemented for `[u8]`
required because it appears within the type `Path`
only the last field of a struct may have a dynamically sized type
change the field's type to have a statically known sizerustcE0277
app.rs(42, 23): borrowed types always have a statically known size
app.rs(42, 23): the `Box` type always has a statically known size and allocates its contents in the heap

If you prefer screenshot:

cargo build --workspace also fails saying below:

error[E0277]: the size for values of type `[u8]` cannot be known at compilation time
  --> altbinutils_core/src/app.rs:42:23
   |
42 |     home_config_path: Path,
   |                       ^^^^ doesn't have a size known at compile-time
   |
   = help: within `Path`, the trait `Sized` is not implemented for `[u8]`
   = note: required because it appears within the type `Path`
   = note: only the last field of a struct may have a dynamically sized type
   = help: change the field's type to have a statically known size
help: borrowed types always have a statically known size
   |
42 |     home_config_path: &Path,
   |                       ^
help: the `Box` type always has a statically known size and allocates its contents in the heap
   |
42 |     home_config_path: Box<Path>,
   |                       ^^^^    ^

error[E0277]: the size for values of type `[u8]` cannot be known at compilation time
   --> altbinutils_core/src/app.rs:47:6
    |
47  | impl From<Metadata> for Paths {
    |      ^^^^^^^^^^^^^^ doesn't have a size known at compile-time
    | 
   ::: /home/erayerdin/snap/rustup/common/rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/convert/mod.rs:373:20
    |
373 | pub trait From<T>: Sized {
    |                    ----- required by this bound in `From`
    |
    = help: within `Paths`, the trait `Sized` is not implemented for `[u8]`
    = note: required because it appears within the type `Paths`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0277`.
error: could not compile `altbinutils_core`

To learn more, run the command again with --verbose.

(Yes, I have a From implementation.)

---

Environment

• rustc 1.49.0
• cargo 1.49.0
• VSCode 1.52.1

Unfortunately, I have no way to tell the rust-analyzer version because the extension downloads it itself. It's safe to assume it is the latest version at the time I write this reply.

If relevant:

• Kubuntu 20.04.2

---

Possible Questions

Why do I think this is not related to rust-analyzer?

It's because cargo build --workspace also fails. Therefore, I think this is related to this thread.

[estebank]

help: borrowed types always have a statically known size
   |
42 |     home_config_path: &Path,
   |                       ^
help: the `Box` type always has a statically known size and allocates its contents in the heap
   |
42 |     home_config_path: Box<Path>,
   |                       ^^^^    ^

Are neither of these suggestions applicable for your case? Should their wording be made clearer or more prominent?

[erayerdin]

@estebank Actually using PathBuf instead of Path solved my issue.