Hello Mark, Mark H Weaver <m...@netris.org> skribis:
> Furthermore, it will be important for a static code analyzer to be able > to infer that phases and snippets always return #t, so let's try not to > be too clever about it. We'll need a static analyzer to gain confidence > that we can start ignoring the return values without losing failure > reports. > > Quite a while ago, I hacked up a preliminary static analyzer to do this. > Obviously it would be good to integrate something like this into our > linter, but I haven't gotten around to it yet. In the meantime, I've > attached my preliminary code below. Here's how it's used: Nice! It’ll greatly help gain confidence that the code is correct when we decide to switch. IIUC it only works for ‘gnu-build-system’, right? If the analyzer doesn’t cover 100% of the packages, we’ll rely on manual testing as we rebuild everything anyway—pretty much like when we do a regular ‘core-updates’ cycle. It’s possible but unlikely that packages that include a phase returning #false would succeed if we ignore that return value, so hopefully we’ll catch residual issues when we build things. Thoughts? Ludo’.
