#fmt accepts some combinations of precision and 0 padding that gcc warns about #2481
Comments
|
Bug triage. Milestone looks right. |
|
Probably fixed, but needs a test. |
|
@alexcrichton: is this still an issue? it seems like it wouldn't be due the trait-based formatting |
|
Most of the formatting code is very similar to what it was before in terms of padding and alignment. I never wrote anything relating to warnings about various specifiers, so this is still an issue in the sense that we don't follow what gcc does exactly in this scenario. That being said, I'm not entirely sure what this is about, and I agree with @catamorphism that this needs some tests showcasing what's going wrong before we can see what we need to do here. |
|
This is quite an old bug, and rethinking on this I think that @thestinger is right in that the compiler cannot warn about situations such as this because the compiler does not understand the semantic meaning of each formatting flags. Implementors can assign meaning to cases such as this even if the standard formatting routines for the standard primitives don't. We could in theory implement this sort of warning for the standard primitives, but that's probably overkill, so I'm going to close this. |
document general shim pattern r? `@oli-obk`
Directly codegen a rust Array into a GOTO array. Before we used to wrap it in a struct. According to the code documentation, we used to wrap it so we could assign an array to another using the struct copy; however, I didn't see any place where this is needed. The cprover bindings crate incorrectly returned that an array was not an lvalue type, which maybe is the reason why we thought that was needed before. However, array is an lvalue, just not a modifiable lvalue, according to the C standard. This simplifies the code and hopefully will help with loop systhesis.
This is one of the tests in
syntax-extension-fmt.rs:In this case the zero-padding overrides the precision (.5) so precision has no effect. Old gcc's accepted this silently, so we do too, but gcc 4.5 (at least) prints a warning about zero-padding and precision being incompatible here, so we should make this (and similar) cases into compile time errors.
The text was updated successfully, but these errors were encountered: