Remove redundant and incorrect target FPU check #185
Conversation
Most target triples with FPU end in `gnueabihf` or `musleabihf`, so this isn't catching them. Since the `has_fpu` function does, this shouldn't change behavior.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @therealprof (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
I'm a little confused by this. I thought cortex-m-rt only supported bare-metal no_std thumbv[678]e?m-none-eabi(hf)? So it doesn't matter if it can't parse gnueabi and musl targets? |
|
Yes, that's true, sorry for the confusion. There might be more targets added in the future which use a different ABI, but for now this just removes redundant code. |
|
How else would the 'has_fpu' feature get set, which is used in src/lib.rs to gate whether to include the FPU-enable code? |
|
There's a |
|
Oh yes. I was confused by the two identical pieces of code, and how "View File" in Github opens the file in your branch (i.e. post-changes). |
|
@bors r+ |
|
bors r+ |
185: Remove redundant and incorrect target FPU check r=therealprof a=jonas-schievink Most target triples with FPU end in `gnueabihf` or `musleabihf`, so this isn't catching them. Since the `has_fpu` function does, this shouldn't change behavior. Co-authored-by: Jonas Schievink <[email protected]>
Build succeeded |
Most target triples with FPU end in
gnueabihformusleabihf, so this isn't catching them. Since thehas_fpufunction does, this shouldn't change behavior.