It is not a compiler error. It is never a compiler error (2017)

1. Roslyn

   1 169 19,787 10.0 C#

   The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.

   

   >> It is not a compiler error. It is never a compiler error (2017)

   No, not always true. Even in modern compilers -- as matured and as modern as VS 2022-- you would still get bug.

   I found one[0]. In my case it's easy to tell it's a compiler bug because the program just can't compile properly. But it's also not easy to reproduce, which just proves how well tested compilers usually are.

   0: https://github.com/dotnet/roslyn/issues/74872

2. InfluxDB

   www.influxdata.com featured

   InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.

   

3. llvm-project

   2 429 34,200 10.0 LLVM

   The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.

   

   The article is right: it is almost never a compiler bug. I have had that experience of reporting and being wrong. It sucks.

   On the other hand, I have a confirmed bug in Cland [1] and a non-rejected bug in GCC [2], so it does happen.

   [1]: https://github.com/llvm/llvm-project/issues/61133

   [2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448

4. NumPy

   3 304 30,263 10.0 Python

   The fundamental package for scientific computing with Python.

   

   I hit a similar issue in 2017 which is still the case today: Python's builtin `random.shuffle` destroys numpy arrays passed into it [0]. This is apparently a design limitation within numpy and cannot be detected or fixed, so it still stands today.

   [0] https://github.com/numpy/numpy/issues/10215

5. omr

   4 5 967 9.8 C++

   Eclipse OMR™ Cross platform components for building reliable, high performance language runtimes

   

Suggest a related project