[Swift-devel] [Bug 315] better diagnostics to identify unmapped paths

[bugzilla-daemon at mcs.anl.gov]

https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=315


Michael Wilde <wilde at mcs.anl.gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |wilde at mcs.anl.gov




--- Comment #1 from Michael Wilde <wilde at mcs.anl.gov>  2011-04-02 18:18:25 ---
First, to note: this test fails in 0.92 and works in 0.91.  Even stranger, in
0.92 the test *succeeds* in about 1 out of 20 tries, which suggests there is
some kind of race condition here.

I think we can also simplify the test case further, and retry.  Doing that now.
...

Further experimentation suggests this has something to do with the way
conditionals and local array variables nested inside a foreach loop are
handled.  Depending on how much of the statements inside the loop are commented
out, the code either works or fails in 0.92.

So we should wait until we have a 0.92 point release with twiceEach fixed, and
then re-test.

If it still fails, I (or Allan or Mihael) should try a few variations and make
sure all logically correct ones work, and that incorrect ones get reasonable
error messages.

Lastly, the original intent for this bug was to also generate  a better error
message stating which object Swift is having trouble mapping.


Also note: you need the following tc entry in addition to Allan's test script
below:

localhost split          /usr/bin/split                          INSTALLED
INTEL32::LINUX null

---

>From a larger perspective:

This bug and the test cases for it raise a very confusing aspect of Swift
semantics: how mapping of output arrays affects Swift's notion of the array
size.  We need to document the rules that govern Swift's behavior in these
cases and cleanly define how this relates to both size and array closing.

We need to decide if Swift *should* be giving a runtime error in the case Allan
shows, and what that error should be.

My understanding of this example is the following:

- we have an output array of files out[]
- we map that array to N file names
- we call a function f() to create the array
- the app function uses filenames(out) to place the filenames on the command
line

Now, when will @filenames() be runnable? (wrt futures and array closing)?

Can this array grow later?

Does the app() need to create all filenames mapped in the out() array?

These seem to be subtle issues that need to be documented, with clarifying,
runnable test examples.

We can split this doc test out to a separate enh bg after the primary problem
is fixed. I realized when trying to simplify the test case that the
documentation points above are not so closely related to the actual problem
here as I initially thought.

-- 
Configure bugmail: https://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.