Il compilatore C# non segnala tutti gli errori contemporaneamente a ciascuna compilazione?

Question

Quando sto compilando questo progetto, mostra come 400+ errori nella finestra Elenco errori, poi vado in siti di errore, ne aggiusto alcuni e il numero dice 120+ errori, e poi dopo aver sistemato un po 'di più, il prossimo compilare report come 400+ di nuovo. Vedo che file diversi arrivano nella finestra Elenco errori, quindi penso che il compilatore si interrompa dopo un certo numero di errori?

Se sì, qual è la ragione di questo? Non si suppone che raccolga tutti gli errori presenti nel progetto anche se superano i 10K +?

Answer 1

Ho intenzione di scrivere un articolo di questo blog.

È possibile che si stia eseguendo semplicemente un limite hardcoded per il numero di errori segnalati. È anche possibile che ti trovi in ​​uno scenario più sottile e interessante.

Ci sono molte euristiche nel compilatore della riga di comando e nel compilatore IDE che tentano di gestire la segnalazione degli errori. Sia per mantenerlo gestibile per l'utente, sia per rendere il compilatore più robusto.

In breve, il modo in cui il compilatore funziona è si cerca di ottenere il programma attraverso una serie di fasi, che potete leggere qui:

http://blogs.msdn.com/b/ericlippert/archive/2010/02/04/how-many-passes.aspx

L'idea è che se una fase iniziale ottiene un errore, potremmo non essere in grado di completare con successo uno stadio successivo senza (1) entrare in un ciclo infinito, (2) in modo anomalo, o (3) riportare errori "a cascata" pazzi. Quindi, ciò che accade è che si ottiene un errore, lo si aggiusta e quindi all'improvviso può essere eseguita la fase successiva della compilazione e viene rilevato un numero maggiore di errori.

Fondamentalmente, se il programma è così incasinato che non possiamo nemmeno verificare fatti di base sulle sue classi e metodi, allora non possiamo dare errori in modo attendibile per i corpi dei metodi. Se non siamo in grado di analizzare un corpo lambda, allora non possiamo fornire errori affidabili per la sua conversione in un albero di espressioni. E così via; ci sono molte situazioni in cui le fasi successive devono sapere che le fasi precedenti sono state completate senza errori.

Il lato positivo di questo disegno è che (1) si ottengono gli errori che sono i più "fondamentali" per primi, senza un sacco di errori di sovrapposizione rumorosi e folli, e (2) il compilatore è più robusto perché non lo fa Devo provare a fare analisi sui programmi in cui sono infranti gli invarianti di base della lingua. Il lato negativo è ovviamente il tuo scenario: che hai cinquanta errori, li risolvi tutti e all'improvviso ne compaiono altri cinquanta.

Answer 2

E 'configurabile in base alle MSDN

Per impostazione predefinita, il numero massimo è di 200 errori e avvisi.

Answer 3

Ovviamente si fermerà a un certo punto.

Anche dopo 1 errore, tutto il resto è dubbio al meglio. Un compilatore proverà a recuperare, ma non è garantito il successo.

Quindi in qualsiasi progetto non banale, è una decisione pratica tra fermarsi al primo errore (teoricamente la cosa migliore da fare) e arare in uno stato inaffidabile.

L'azione più corretta sarebbe quella di fermarsi dopo 1 errore, ma ciò porterebbe a una noiosa situazione di "correzione 1 alla volta". Quindi un compilatore tenta di risincronizzare uno stato conosciuto e segnalare quello successivo. Ma un errore potrebbe causare falsi errori nel codice corretto che lo segue, quindi a un certo punto smette di essere ragionevole.

Fare riferimento al proprio caso: 400+ passa a 120 dopo alcune correzioni.