Skip to content
Snippets Groups Projects
  1. May 03, 2024
  2. Mar 22, 2024
  3. Feb 22, 2024
  4. Feb 06, 2024
  5. Jan 29, 2024
  6. Dec 08, 2023
  7. Oct 23, 2023
  8. Nov 07, 2023
  9. Oct 28, 2023
  10. Sep 25, 2023
  11. Aug 03, 2023
  12. Jul 17, 2023
    • Mike Hommey's avatar
      Bug 1831467 - Avoid more UB from transmuting a ref to a ref with interior... · d4175c7e
      Mike Hommey authored
      Bug 1831467 - Avoid more UB from transmuting a ref to a ref with interior mutability. r=emilio, a=dsmith
      
      aka one specific change in LLVM 16 introducing UB in Rust, take 3? 4?
      
      This time, we have multiple types like:
        #[xpcom(implement(nsISomething))]
        struct Foo {
            foo: RefCell<Something>,
        }
      
        impl Foo {
            fn from_interface(obj: &nsISomething) -> &Self {
                unsafe { ::std::mem::transmute(obj) }
            }
        }
      
      At first glance, this looks innocuous. But the problem is that
      nsISomething, as far as LLVM is informed by Rust, is readonly,
      but Foo, via the RefCell, has interious mutability.
      
      LLVM ends up assuming that any mutability that happens to that returned
      &Foo can't happen, and removes it.
      
      This is yet another case where https://github.com/rust-lang/rust/issues/111229
      would save our feet from this footgun LLVM 16 added and that the rust
      compiler doesn't help us prevent the least.
      
      Differential Revision: https://phabricator.services.mozilla.com/D183569
      ***
      Bug 1831467 fix comment a=dsmith
      d4175c7e
  13. Jul 11, 2023
  14. Jun 20, 2023
  15. May 31, 2023
    • Emilio Cobos Álvarez's avatar
      Bug 1835119 - Remove nsCOMPtr_base. r=xpcom-reviewers,kmag · c2f5a4ac
      Emilio Cobos Álvarez authored
      It's not clear to me why specializing nsCOMPtr<nsISupports> is
      particularly useful, and this removes a lot of code, bringing us closer
      to unifying nsCOMPtr and RefPtr.
      
      The changes in other places are needed because we used to allow
      nsCOMPtr<nsISupports> to implicitly coerce to nsISupports even for
      rvalue references.
      
           0:47.88 /home/emilio/src/moz/gecko-4/netwerk/protocol/http/nsHttpActivityDistributor.cpp:121:11: error: conversion function from 'nsCOMPtr<nsISupports>' to 'nsISupports *' invokes a deleted function
           0:47.88           nsCOMPtr<nsISupports>(do_QueryObject(channel)), aActivityType,
           0:47.88           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           0:47.88 /home/emilio/src/moz/gecko-4/obj-debug/dist/include/nsCOMPtr.h:764:3: note: 'operator nsISupports *' has been explicitly marked deleted here
           0:47.88   operator T*() const&& = delete;
           0:47.88   ^
           0:47.88 /home/emilio/src/moz/gecko-4/netwerk/protocol/http/nsHttpActivityDistributor.cpp:29:57: note: passing argument to parameter 'aHttpChannel' here
           0:47.88 nsHttpActivityDistributor::ObserveActivity(nsISupports* aHttpChannel,
           0:47.88                                                         ^
      
      Which is not allowed for a good reason, generally.
      
      Differential Revision: https://phabricator.services.mozilla.com/D179124
      c2f5a4ac
    • Emilio Cobos Álvarez's avatar
      Bug 1835119 - Remove NSCAP_FEATURE_USE_BASE. r=xpcom-reviewers,kmag · 373447e2
      Emilio Cobos Álvarez authored
      This is not needed since bug 1363754. I left this as a follow-up
      clean-up to mitigate a bit the risk of that change.
      
      Differential Revision: https://phabricator.services.mozilla.com/D179123
      373447e2
  16. May 30, 2023
  17. May 29, 2023
  18. May 26, 2023
    • Jan Horak's avatar
      Bug 1814897 Add org.mozilla.firefox.systemconfig extension to load system-wide settings; r=mkaply · f0d13e82
      Jan Horak authored
      The settings must be put into (path depends on architecture and branch):
      /var/lib/flatpak/extension/org.mozilla.firefox.systemconfig/x86_64/stable/defaults/pref
      
      Currently policies.json to be placed into:
      /var/lib/flatpak/extension/org.mozilla.firefox.systemconfig/x86_64/stable/policies/policies.json
      
      Differential Revision: https://phabricator.services.mozilla.com/D168803
      f0d13e82
    • Chris Peterson's avatar
      Bug 1791961 - xpcom: Fix C++20 -Wambiguous-reversed-operator warnings. r=emilio · c5f254d1
      Chris Peterson authored
      clang is warning that C++20 expects comparison operators to be commutative: `a == b` and `b == a` should resolve to the same comparison operator function. Warnings about the comparison of const and non-const objects can be fixed by making the comparison operator function const.
      
      xpcom/base/AvailableMemoryWatcherMac.cpp:404:14 [-Wambiguous-reversed-operator] ISO C++20 considers use of overloaded operator '==' (with operand types 'mozilla::MacMemoryPressureLevel' and 'mozilla::MacMemoryPressureLevel') to be ambiguous despite there being a unique best viable function
      xpcom/base/AvailableMemoryWatcherMac.cpp:568:24 [-Wambiguous-reversed-operator] ISO C++20 considers use of overloaded operator '==' (with operand types 'mozilla::MacMemoryPressureLevel' and 'mozilla::MacMemoryPressureLevel') to be ambiguous despite there being a unique best viable function
      
      Depends on D179024
      
      Differential Revision: https://phabricator.services.mozilla.com/D179025
      c5f254d1
  19. May 25, 2023
  20. May 24, 2023
  21. May 23, 2023
  22. May 22, 2023
Loading