Update Bugzilla URLs in docs

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295432 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst
index 9ec6fb84636f451900ea4ff731533c5ec09b5bec..97e0572343798a35191efd2fd3f1be4d72cbf74c 100644 (file)
--- a/docs/DeveloperPolicy.rst
+++ b/docs/DeveloperPolicy.rst
@@ -62,7 +62,7 @@ way to see what other people are interested in and watching the flow of the
 project as a whole.
 
 We recommend that active developers register an email account with `LLVM
-Bugzilla <http://llvm.org/bugs/>`_ and preferably subscribe to the `llvm-bugs
+Bugzilla <https://bugs.llvm.org/>`_ and preferably subscribe to the `llvm-bugs
 <http://lists.llvm.org/mailman/listinfo/llvm-bugs>`_ email list to keep track
 of bugs and enhancements occurring in LLVM.  We really appreciate people who are
 proactive at catching incoming bugs in their components and dealing with them
@@ -261,7 +261,7 @@ the future that the change is responsible for.  For example:
 * The changes should not cause performance or correctness regressions in code
   compiled by LLVM on all applicable targets.
 
-* You are expected to address any `Bugzilla bugs <http://llvm.org/bugs/>`_ that
+* You are expected to address any `Bugzilla bugs <https://bugs.llvm.org/>`_ that
   result from your change.
 
 We prefer for this to be handled before submission but understand that it isn't

diff --git a/docs/HowToSubmitABug.rst b/docs/HowToSubmitABug.rst
index 9f997d2757dd967854599329ca30c73935f62c7b..25cb2c8c80d3681495c6ae789d969dea81443d37 100644 (file)
--- a/docs/HowToSubmitABug.rst
+++ b/docs/HowToSubmitABug.rst
@@ -19,7 +19,7 @@ section to narrow down the bug so that the person who fixes it will be able
 to find the problem more easily.
 
 Once you have a reduced test-case, go to `the LLVM Bug Tracking System
-<http://llvm.org/bugs/enter_bug.cgi>`_ and fill out the form with the
+<https://bugs.llvm.org/enter_bug.cgi>`_ and fill out the form with the
 necessary details (note that you don't need to pick a category, just use
 the "new-bugs" category if you're not sure).  The bug description should
 contain the following information:

diff --git a/docs/Lexicon.rst b/docs/Lexicon.rst
index de929bec1b0e984b2ca2910e9875892b4ef3051e..5d16091e27e5ceed8c7f9c9b4a525b8ba09cc28a 100644 (file)
--- a/docs/Lexicon.rst
+++ b/docs/Lexicon.rst
@@ -182,7 +182,7 @@ P
 
 **PR**
     Problem report. A bug filed on `the LLVM Bug Tracking System
-    <http://llvm.org/bugs/enter_bug.cgi>`_.
+    <https://bugs.llvm.org/enter_bug.cgi>`_.
 
 **PRE**
     Partial Redundancy Elimination

diff --git a/docs/ProgrammersManual.rst b/docs/ProgrammersManual.rst
index 1c96046bf40a7b41c266626cd5abcbd4fcace7d5..1e2e8eb024811a9b327ae65c4d7127d43f6720eb 100644 (file)
--- a/docs/ProgrammersManual.rst
+++ b/docs/ProgrammersManual.rst
@@ -2903,7 +2903,7 @@ Another way is to only call ``getPointerToFunction()`` from the
 
 When the JIT is configured to compile lazily (using
 ``ExecutionEngine::DisableLazyCompilation(false)``), there is currently a `race
-condition <http://llvm.org/bugs/show_bug.cgi?id=5184>`_ in updating call sites
+condition <https://bugs.llvm.org/show_bug.cgi?id=5184>`_ in updating call sites
 after a function is lazily-jitted.  It's still possible to use the lazy JIT in a
 threaded program if you ensure that only one thread at a time can call any
 particular lazy stub and that the JIT lock guards any IR access, but we suggest

diff --git a/docs/Statepoints.rst b/docs/Statepoints.rst
index 29b1be37a893cce8934c52d1546d94f36e9100fd..7f2b20544812f6e3da79e11c2984097b9c7d93e5 100644 (file)
--- a/docs/Statepoints.rst
+++ b/docs/Statepoints.rst
@@ -831,7 +831,7 @@ Bugs and Enhancements
 
 Currently known bugs and enhancements under consideration can be
 tracked by performing a `bugzilla search
-<http://llvm.org/bugs/buglist.cgi?cmdtype=runnamed&namedcmd=Statepoint%20Bugs&list_id=64342>`_
+<https://bugs.llvm.org/buglist.cgi?cmdtype=runnamed&namedcmd=Statepoint%20Bugs&list_id=64342>`_
 for [Statepoint] in the summary field. When filing new bugs, please
 use this tag so that interested parties see the newly filed bug.  As
 with most LLVM features, design discussions take place on `llvm-dev