• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Errors & Warnings Smartgroup
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Errors & Warnings Smartgroup


  • Subject: Errors & Warnings Smartgroup
  • From: Chris Espinosa <email@hidden>
  • Date: Tue, 17 Aug 2004 22:39:47 -0700

On Aug 17, 2004, at 4:54 PM, Chris wrote:

On August 17, email@hidden wrote:
I filed a bug report for this (3755521), but it was closed saying it
was the expected behavior. I appended information, but its state stayed
closed. So I created a new bug report for this (3763249).

If Apple do this, they mean that it IS expected behaviour. I have experience of this from other bug reporting [not Xcode].

To be fair to all involved, the two bugs reported (3755521, closed as Behaves Correctly and 3763249, still pending) are not very detailed, especially when it comes to steps for reproduction. The engineer who commented on them made some assumptions about the phenomenon that was observed in the bug; those assumptions fit an intended behavior, but they may not reflect accurately what the bug reporter observed.


This is how the Errors and Warnings smartgroup is designed to work:

- Start with a clean build.
- Introduce errors into file A and file B.
- Build.
You'll see file A and file B in the smartgroup, with the errors in each.
- Fix both sets of errors.
- Build again.
As each file builds successfully, its errors (and itself) are removed from the smartgroup.


When you have a successful complete build with no errors, the Errors and Warnings smartgroup should be empty.

Now contrast that with this:

- Start with a clean build
- Introduce a warning into file A and an error into file B.
- Build.
You'll see file A and its warning and file B and its error in the smartgroup.
- Fix the error.
- Build again.
File B is rebuilt and it and its error should disappear. But since File A built with just a warning, and you haven't touched it, it's not rebuilt, and its warning persists in the smartgroup.


This is probably the most common confusion about the Errors and Warnings smartgroup. As a smartgroup, it persists the known status of all project files, while the Build Results window gives you the this-build-only errors and warnings, which may differ.

Raphael augmented his first bug report with the detail that he was talking about errors, not warnings. What the engineer specifically mentions is the possibility that because of dependencies, etc. in a build that has errors, a given build command may not actually instigate the rebuilding of all files that have been touched:

- Start with a clean build
- Introduce errors into files A and B
- Build; see A and B in the smartgroup with their errors
- Fix A and B, but introduce an additional error into A
- Build
File A builds, adding its new error to the smartgroup. Because of dependency checking, B may not be rebuilt, so its errors persist even though you fixed the code.


This is the scenario we've seen before and that the engineer thought you were talking about.

If you have fixed all bugs and get "Build succeeded" with no errors or warnings in the Build Results window, and there are still items in the smartgroup, that's a bug.

If you rebuild a file and it shows up in the Build Results window with no errors or warnings, but its errors aren't removed from the smartgroup, that's a bug.

If you have a situation like this, here are the things that we would like, in order of helpfulness:

1) A project that demonstrates the bug. If you can send us an entire project bundled on a .dmg that's terriffic. But we know you may not want to disclose your source to Apple; we get entire projects very rarely.
2) A sample project cooked up to demonstrate the bug. Safer for you (no real code of yours) and faster for us. We understand this is more work for you but it really helps.
3) A complete build log of the project with the error, and a screen shot of what you get. This may disclose some details of your project but no source. But in terms of helpfulness this is the next best thing to a case that we can reproduce.
4) Detailed, step-by-step instructions of how to reproduce the bug (more detailed than I give above; for example, the specific errors you introduced would be helpful).


A general description of what you tried to do and what your experience was gives us only a rough guide. If we try to reproduce it, we'll probably tend to do things we know work and not do the things the way you did them, which makes it more likely we'll fail to reproduce it. So the more detailed you can be, the better.

And again, to be fair to all involved, there is a separate, independent report of a very similar bug (with the added twist that building the same file twice adds the error twice to the smartgroup), which we are investigating. This has clearer and more detailed reproduction steps so we may make more progress on it.

I understand your frustration with both the product and the bug reporting process, and hope we can work together to get this resolved.

Chris Espinosa
Apple
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.


  • Follow-Ups:
    • Re: Errors & Warnings Smartgroup
      • From: Markus Hitter <email@hidden>
    • Re: Errors & Warnings Smartgroup
      • From: Raphael Sebbe <email@hidden>
References: 
 >Re: xcode-users digest, Vol 1 #590 (From: Chris <email@hidden>)

  • Prev by Date: easy street
  • Next by Date: gdb won't break at malloc_printf() though I followed MallocDebug directions
  • Previous by thread: Re: xcode-users digest, Vol 1 #590
  • Next by thread: Re: Errors & Warnings Smartgroup
  • Index(es):
    • Date
    • Thread