1樓：shingtaklam1324
目前使用nightly rust，bug基本上是每週一兩個，不過可能跟我在做的東西有關吧，使用了更多unsafe和unstable。反正在Github上反映了，一兩天就修好了
2樓：
VC編譯器在編譯用openmp並行化的迴圈時，如果迴圈內部有return，會直接報編譯器內部錯誤，不知道這算不算乙個bug
void f()
3樓：
怎麼說呢…沒發現過編譯器的bug，但撞到過標準庫的bug。
現在能記得的就是gcc 4.6的future實現，在某種情況下會崩潰。
調了很久，感覺沒天理的時候google搜了下發現的，幸好已經有前人報過了並且確認了bug，不然我可能會在公司加班加到死………
體驗就是：
1、我就覺得不是我的錯！！
2、可是現在我得推翻我整個基於future的設計了…………
4樓：
發現過Rust編譯器的乙個ICE（編譯器內部錯誤，已提交issuse並經官方確認），問題出在定義const fn的時候加不加return。
這是在const fn特性還未穩定的情況下發現的，如果換了是發展了幾十年的其他編譯器是沒有那麼容易的。
要說什麼體驗？能參與到一門現代化語言的成長過程中，感覺還是挺不錯的。
要解決這個Bug並不簡單，需要const fn功能的完善，最近幾天由miri支援的const fn功能可能快要上線了，也許這個Bug就會被自動修復。
---- 更新
隨著Replace all const evaluation with miri by oli-obk · Pull Request #46882 · rust-lang/rust 這個PR的合併，果然ICE被自動解決了。
5樓：
想辦法要求開發方盡快發補丁
但是這玩意不靠譜
所以還是自己先想辦法繞過去吧
比如當年曾經發現的某個gcc的istream讀0xff的問題……最後加了一行if繞開……
6樓：
遇到過MSVC141的乙個Bug是，我在x86模式下編譯，然後告訴我編譯器記憶體空間不足，自動轉換為x64編譯器，編譯完事，鏈結的時候告訴我，各模組的目標平台不同，鏈結失敗。
我：？？？.jpg
然後我去翻了一下MSVC的bin目錄，有HostX86_X86, HostX86_X64, HostX64_X86, HostX64_X64，X86編譯預設用HostX86_X86，然後記憶體不足就給我換成HostX64_X64了。。。丫你就不會用HostX64_X86麼？
再說個應該不算是bug的吧。
最近做的某專案裡需要把乙個提前用MATLAB算好的一堆數學表示式硬編碼到C++專案裡，然而那堆表示式非常長，最長的大概有2 3萬字元，然後編譯器就炸了。。。
可是問題是，之前編譯過更大的表示式，長度大概有十幾萬字元，都沒炸。。。
最後沒辦法，寫了個指令碼把超長的表示式截斷成好幾個ans+= expression;的形式。。。
7樓：
……除了知名編譯器，還有各種非知名編譯器好吧……
我們公司就自己搞了一套查詢語言的編譯器，你說找到編譯器bug什麼感覺……？
「咱們組有個不成文的慣例，誰找到的bug誰去修……」
8樓：
使用者能不能準確描述BUG與開源無關。開源軟體同樣有一大半BUG匯報是無效的。
9樓：藥罐子千里冰封
日常生活的一部分 ，早就習慣了。一般通過全部重新編譯或者修改成等價的寫法來解決。
補圖，已開issue
編譯器是如何編譯自己的？
何源 比如你是馬雲，沒身份證 編譯器 之前怎麼證明自己是馬雲。那你得弄來一張名為馬雲的身份證 編譯器 問題來了，這張身份證怎麼來呢？你去找你爸要了戶口本 其他語言的編譯器 去派出所填寫了自己的資料 自己編譯器原始碼 辦理身份證，因為戶口本上你的名字是馬雲，派出所給了一張名為馬雲的身份證。從此，你不用...
編譯器是如何工作的？
就事論事的話,推薦你讀Neil Jones 等著的Automatic Partial Evaluation and Program Generation,這本書的開頭應該解決了你想的問題.至於你想知道編譯器中間過程的原理,可是本來編譯器就是把乙個語言變成另乙個語言的程式.建議你先讀讀EoPL3的1 ...
這是不是乙個C 編譯器的bug
Ubp.a 這是空基類問題。為什麼要寫成這種基類 Vec 的形式？想必題主也清楚，就是 復用函式實現 而不僅僅是 concept。這裡題主復用了乙個函式實現，是 operator 很好現在想復用另一種函式實現，加法得寫成怎樣呢？如下 template Impl typenameT,size t N ...