Forbid unsized structs which are non-instantiable #16985
Conversation
| E0160 | ||
| E0160, | ||
| E0162, | ||
| E0163 |
There was a problem hiding this comment.
Because I added it in a different PR and it will make rebasing easier :-)
|
Addressed kballard's comments |
|
|
||
| if !check_ty_may_be_sized(ccx.tcx, ty::node_id_to_type(ccx.tcx, it.id)) { | ||
| span_err!(ccx.tcx.sess, it.span, E0163, | ||
| "struct cannot be instantiated since it can never have statically known size"); |
There was a problem hiding this comment.
I still think the word "a" is necessary here. It should be more obvious if you get rid of the words "statically known": "it can never have size". Structs don't "have size", they "have a size". Therefore they should also "have a statically known size".
There was a problem hiding this comment.
The English in error messages is abbreviated, so it's slightly odd grammar. To my ears, omitting the 'a' sounds better. Even with it, the English is not great (it should be something like 'The struct Foo cannot be instantiated because its size can never be statically known by the compiler'),
There was a problem hiding this comment.
+1 to the 'a' here, even though it's chopped. I have a hard time parsing
this as written.
There was a problem hiding this comment.
Abbreviated grammar is fine. But the lack of an "a" looks like a straight-up error, not an abbreviation. It would be like emitting an error for let x; with the string "this variable must have value", instead of the much more correct "this variable must have a value".=
There was a problem hiding this comment.
OK, I'll stick an 'a' in. 'size' does feel different to 'value' to me, but I can't explain why.
|
Now with more 'a's |
|
Turns out I can fix this ICE without banning always-unsized structs. So, closing for now. |
update: add editor/extension information to bug report template When attempting to reproduce issues, I encounter difficulties due to differences in versions of LSP clients and editors (such as rust-lang#16985, rust-lang#16867, and more) This sometimes consumes a lot of efforts from contributors to communicate the details about LSP client information. Therefore, I believe adding editor/extension information to the issue template would be helpful for problem reproduction.
update: add editor/extension information to bug report template When attempting to reproduce issues, I encounter difficulties due to differences in versions of LSP clients and editors (such as rust-lang#16985, rust-lang#16867, and more) This sometimes consumes a lot of efforts from contributors to communicate the details about LSP client information. Therefore, I believe adding editor/extension information to the issue template would be helpful for problem reproduction.
Closes #16977
r?