On Sat, 18 Jul 2009, Alex Rozenman wrote: > 1. More than one valid variant present. Here, an "Ambiguous reference" error > should be issued, we may even consider not to print invalid variants as > sub-messages.
I think they should stay because one of them might be what the user really means. It will be helpful if the valid variants are printed first. > 2. There is exactly one valid variant. No resolution problem exists, but > more detailed analysis gives the following: > 2.1. When an invalid variant of type "A" (mid-rule visibility) presents - a > classic warning situation holds. > 2.2. When an invalid variant of type "B" (invalid bracketing) presents - > looks like an error, for example a reference "$abc.xxx" has a "valid" > resolution to a symbol "abc" and "invalid" resolution to "abc.xxx". Too > ambiguous to be a warning. > 2.3. For invalid references of type "C" (hidden). Here I have strong feeling > we must not to complain at all. This will resolve issues from my previous > mail. > The final decision (error or warning) may be found as a "worst case" on all > existing invalid variants. I think the main confusion for the user will be understanding why a reference he wrote is rejected when it is perfectly valid and unambiguous. That's why I had suggested that Bison always report "misleading reference" in these cases. Based on your previous email, that's why I'm also now suggesting that a misleading reference always be just a warning. Bison is just telling the user that something *may* be wrong. I think it's confusing and not helpful to the user if Bison makes it an error only in some subcases. I also do not think we should drop the "hidden" warnings. Maybe Akim can give his opinions on both of these issues too. > Akim, when do you plan to release the 2.5 ? I'm currently very busy with my > main job :), so it will take some time to update the code. 2.4.2 is still waiting for release. I still have some cleanup to do with IELR(1) before 2.5.
