setup: return to single setup_func() call site

Now that all the module setup_funcs are returning a res_setting
w/-EINVAL in res_setup baking, it should be fine for
setup_interactively() to resume using the single setup_func()
loop passing res_setup, and always using res_setting on -EINVAL.

This is especially desirable now that :-prefix settings are
accepted as overrides.  You can now get arbitrary values down to
the res_setup baking phase, previously when you got something
wrong there you'd get an ambiguous error without a setting path.
With this commit, you should get a much more useful error
including a setting path.

This partially undoes 5191d68, where res_setup-baking was split
off from the core loop, to occur after the res_failed_desc on
EINVAL storage.

1 files changed, 4 insertions, 9 deletions

diff --git a/src/setup.c b/src/setup.c
index bf74cfb..6812795 100644
--- a/src/setup.c
+++ b/src/setup.c
@@ -44,12 +44,7 @@ int setup_interactively(til_settings_t *settings, int (*setup_func)(const til_se
 
 	/* TODO: regex and error handling */
 
-	/* until all the setup_funcs guarantee they return the failed setting on -EINVAL w/non-NULL res_setup (finalizing),
-	 * this will be done in two steps; this first loop just constructs the settings heirarchy, and if it fails with
-	 * -EINVAL we will use the setting for logging.  Then after this loop, one last recurrence of setup_func() w/res_setup
-	 * actually set.  Once all setup_funcs behave well even in res_setup we'll go back to just the loop on setup_func().
-	 */
-	while ((r = setup_func(settings, &setting, &desc, NULL)) > 0) {
+	while ((r = setup_func(settings, &setting, &desc, res_setup)) > 0) {
 		assert(desc);
 
 		additions++;
@@ -195,13 +190,13 @@ _next:
 	}
 
 	if (r < 0) {
-		if (r == -EINVAL)
+		if (r == -EINVAL) {
+			assert(setting);
 			return setup_ret_failed_desc_path(setting->desc, r, res_failed_desc_path);
+		}
 
 		return r;
 	}
 
-	r = setup_func(settings, &setting, &desc, res_setup);
-
 	return r < 0 ? r : additions;
 }