The `find_a_program`/`for_each_path` machine-prefix patch series has now
landed on gcc `master`, so point the `fetchpatch` entries at the
`gcc-mirror/gcc` commit `.diff`s rather than the v5 mailing-list `raw`
URLs (matching the existing `for_each_path` rework patch).
Linking the approving mailing list posts, along with the commit hash
each of the 4 commits (by title) landed as.
- <https://inbox.sourceware.org/gcc-patches/6c3a085d-fa62-4b24-b4ca-ee5c6ac11be0@oss.qualcomm.com/>
Approved the first two patches together.
1. `find_a_program: Separate from find_a_file` → 948eb02800777d0318ee2a38bf32076afee739f2
2. `driver: Simplify find_a_program and find_a_file` → 073b4656d07e40f83a1db7f4462ab2d68b1875a2
- <https://inbox.sourceware.org/gcc-patches/324798d3-effb-4dc5-86ab-a1c461390d64@oss.qualcomm.com/>
3. `for_each_path: Pass to callback whether dir is machine-disambiguated` → f62f68e7c4bde0385fbd2dba3e926586dd2f1281
- <https://inbox.sourceware.org/gcc-patches/ae270a41-fae9-4442-a276-0433ea752f2e@oss.qualcomm.com/>
4. `find_a_program: Search with machine prefix in some cases` → a514707ffd7d58b140686036c2dece43ecb7d33c
We also include an additional commit,
6b008944e7bc3a342a734c4fcf1001d63fd0a6f8, a one-line `for_each_path` fix
against a mistake that I made in the previous commit. It is applied as a
prerequisite both so we also have the fix, and because without the
latter patches would have conflicts.
In 0.101 & on non-macOS builds, Factor added a .out extension to
deployments. The current Nix derivation is built with path assumptions
in mind. Rather than running switch-cases on versions+OS or relying on
globbing in the shell scripts, the deploy script has been modified to
print its resolved deploy path to a file so that the build can continue
knowing exactly where the files are / should go. This handles both with
& without .out extension as the tests pass on 0.99, 0.100, & 0.101.
tree-sitter can highlight these (& more depending on editor setup), &
for the rest of users, it’s still an annotation that helps keep track of
what language we are working in.
Scope:
- Combination of
- Textual matches of "baseNameOf (toString"
- Redundant toString calls I've found with my latest
"lazy paths" nix branch as they force lazy fetches into
the store. More info and new PR soon.
- Only cases I believe are worthwhile or easily determined
I've determined the validity by
- testing llvmPackages instantiation
- figuring out which types can pass into any particular
toString call - "human fuzzy type checker"
Behavior considerations by type:
- `path`: converted back to a string *without* context
`baseNameOf` does not copy things to the store on its own,
equivalent to its behavior for string inputs
- `null`: converted to `""` -> may be valid input!
ok if "" would not have been acceptable anyway
- `string` itself: passed through identically -> trivial
- `attrset` with `outPath`: same coercion as built into
the `baseNameOf` function -> trivial
- other atomic types: generally not sensible inputs to
`baseNameOf` -> fuzzy but true
