Handle missing output directory better

[fliiiix]

Improve the error message when the output directory is not writable.

After:

error:
  Output path: readonly/ is not writable

Before:

error:
  Unable to generate Rust for monster

This runs only if the cpp version is 17 or higher since writing this check platform independent without std::filesystem would be a huge pain and a lot more code. Pre cpp17 versions will just fall back to the error message from before and assume the directory is always writable.

[fliiiix]

@aardappel any thoughts on this?

[aardappel]

Hmm, I am not sure how I feel about creating a file and then deleting it just for the purpose of seeing if a directory is writable. It seems messy an possibly inefficient.

And if all we're doing is checking if the file fails to open for writing, can't we derive that same information from the actual files we're trying to write and produce a better error there? Or just Unable to generate Rust for monster (failed to open file for writing) or whatever?

Esp since dirs locked for writing doesn't seem like a frequent occurrence.

[fliiiix]

It seems messy an possibly inefficient.

I looked into it and it seems that is unfortunately the most reliable way to check for it.

can't we derive that same information from the actual files we're trying to write and produce a better error there?

I guess you are correct that is what we should do. I think i did not go down this path because this requires a bit more refactoring. But since this also came up here that we need a better way to forward errors from the code generators itself i will look into how we could achieve this.
This has the added benefit that this should also work with cpp-11.

Esp since dirs locked for writing doesn't seem like a frequent occurrence.

the usecase we had is that src is mounted read-only into the container, and it took us a long time to figure out why flatc was failing.

[fliiiix]

@aardappel or @jtdavis777 i guess we should not use exceptions?

This leaves me with the following option to handle it similar to idl_gen_text.cpp or is there any better ideas?
Basically returning a nullptr for success and a const char * for and error, see the example in the diff.

If thats the way we want to go i would go on and update this mr with replacing all the bool returns with error messages for the useful cases.

The example will print error messages like this (note the message at the end) ->

./flatc -p --python-version=6.6.6.6 ../tests/monster_extra.fbs
Usage: ./flatc [-b|--binary, -c|--cpp, -n|--csharp, -d|--dart, -g|--go,
-j|--java, -t|--json, --jsonschema, --kotlin, --kotlin-kmp, --lobster, -l|--lua,
--nim, --php, --proto, -p|--python, -r|--rust, --swift, -T|--ts, -o, -I, -M,
--version, -h|--help, --strict-json, --allow-non-utf8, --natural-utf8,
--defaults-json, --unknown-json, --no-prefix, --scoped-enums,
--no-emit-min-max-enum-values, --swift-implementation-only, --gen-includes,
--no-includes, --gen-mutable, --gen-onefile, --gen-name-strings,
--gen-object-api, --gen-compare, --gen-nullable, --java-package-prefix,
--java-checkerframework, --gen-generated, --gen-jvmstatic, --gen-all,
--gen-json-emit, --cpp-include, --cpp-ptr-type, --cpp-str-type,
--cpp-str-flex-ctor, --cpp-field-case-style, --cpp-std, --cpp-static-reflection,
--object-prefix, --object-suffix, --go-namespace, --go-import, --go-module-name,
--raw-binary, --size-prefixed, --proto-namespace-suffix, --oneof-union,
--keep-proto-id, --proto-id-gap, --grpc, --schema, --bfbs-filenames,
--bfbs-absolute-paths, --bfbs-comments, --bfbs-builtins, --bfbs-gen-embed,
--conform, --conform-includes, --filename-suffix, --filename-ext,
--include-prefix, --keep-prefix, --reflect-types, --reflect-names,
--rust-serialize, --rust-module-root-file, --root-type, --require-explicit-ids,
--force-defaults, --force-empty, --force-empty-vectors, --flexbuffers,
--no-warnings, --warnings-as-errors, --cs-global-alias,
--cs-gen-json-serializer, --json-nested-bytes, --ts-flat-files,
--ts-entry-points, --annotate-sparse-vectors, --annotate,
--no-leak-private-annotation, --python-no-type-prefix-suffix, --python-typing,
--python-version, --python-decode-obj-api-strings, --python-gen-numpy,
--ts-omit-entrypoint, --file-names-only, --grpc-filename-suffix,
--grpc-additional-header, --grpc-use-system-headers, --grpc-search-path,
--grpc-python-typed-handlers, --grpc-callback-api]... FILE... [--
BINARY_FILE...]

error:
  Unable to generate Python for monster_extra The provided Python version is not valid

[aardappel]

Yes, this project has always been under the google C++ guidelines, which have always forbidden exceptions.

Your solution seems good to me.