[Tools - Toolchains] Allow dependency parsing to fail, gracefully continuing #3229
Conversation
|
What I am missing how was this patch tested (partially that info is in the issue, but we should encourage users and we should do the same, add tests info to the pull requests). Commands used, targets , toolchains, anything relevant. |
|
/morph test |
|
@0xc0170 is the Reproducing the issue section what you were looking for (I added it since you commented) |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 1034 All builds and test passed! |
| deps = self.parse_dependencies(dep_path) if (exists(dep_path)) else [] | ||
| try: | ||
| deps = self.parse_dependencies(dep_path) if (exists(dep_path)) else [] | ||
| except: |
There was a problem hiding this comment.
A bare "except:" is generally considered poor practice. E.g. a well-timed Ctrl-C, instead of stopping compilation, may instead cause more compilation to take place.
theotherjimmy
force-pushed
the
allow-deps-to-fail
branch
from
05f9216 to
c391521
Compare
|
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 1071 All builds and test passed! |
|
@mazimkhan @marhil01 Can API rate limit error be handled more gracefully or fixed? |
|
Sure I will schedule some time to fix it. Thanks for the patience. |
Description
If, say, you compile with gcc_arm and kill it at just the right time you will have an empty dependency file. This empty dependency file will cause a python traceback in dependency parsing, preventing you from compiling until you next clean.
This PR lets that weird corner case compile.
Status
READY
Reviews
should resolve #3226
Reproducing the issue
We can simulate the very precise timing needed to reproduce this bug by simply emptying a
.dfile.dfile for the project (for example I'll useBUILD/k64f/gcc_arm/main.d)