search for: 139207

I'm seeing these in my log: Jul 25 15:22:27 postamt dovecot: IMAP(hdaebrit): inotify_rm_watch() failed: Invalid argument Jul 25 15:22:27 postamt dovecot: IMAP(hdaebrit): inotify_rm_watch() failed: Invalid argument Jul 25 15:22:34 postamt dovecot: IMAP(hdaebrit): inotify_rm_watch() failed: Invalid argument Jul 25 15:22:34 postamt dovecot: IMAP(hdaebrit): inotify_rm_watch() failed: Invalid

...pdates for downstream codebases, we do so because there’s a real expected benefit to it. For the most part, we do make some effort to keep existing source interfaces stable. While I’m at a loss to find a documented policy, I recall this thread (http://lists.llvm.org/pipermail/llvm-dev/2020-February/139207.html) where this claim was made and not disputed. The expected real benefits to this change are: 1) The names now match the semantics 2) It is now statically impossible to accidentally get the fixed number of elements from a scalable vector and 3) It forces everybody to fix their broken code. If we...

...dates for downstream codebases, we do so because there’s a real expected benefit to it. For the most part, we do make some effort to keep existing source interfaces stable. While I’m at a loss to find a documented policy, I recall this thread (http://lists.llvm.org/pipermail/llvm-dev/2020-February/139207.html) where this claim was made and not disputed. The expected real benefits to this change are: 1) The names now match the semantics 2) It is now statically impossible to accidentally get the fixed number of elements from a scalable vector and 3) It forces everybody to fix their broken code. If we...

Hi John, I’d like to address some points in your message. > Practically speaking, this is going to break every out-of-tree frontend, backend, or optimization pass that supports SIMD types. My understanding is that the policy in LLVM development is that we do not let considerations for downstream and out-of-tree codebases affect the pace of development. The C++ API is explicitly unstable.