similar to: Clang format wrapping bug

Am Mi., 1. Juli 2020 um 05:46 Uhr schrieb MyDeveloper Day via llvm-dev <llvm-dev at lists.llvm.org>: > I always knew "polly" was mostly clean too, and actually one of the areas I already test against, (along with lib/Format obviously). You have no other choice. Polly verifies its source formatting as part of check-polly, so every commit that violates formatting will get an

(Copying from Discourse) All A couple of months ago I added the following page documentation Clang-Formatted-Status <http://clang.llvm.org/docs/ClangFormattedStatus.html> to track the status of “How Much” clang-formatted the LLVM/Clang project is. I’m a contributor to clang-format and would like to see LLVM 100% clang formatted so we can use LLVM as a massive test-suite for clang-format

Sorry, I didn't notice this change of default last night. Thanks for fixing this! -- Mehdi On Tue, Jul 28, 2020 at 5:50 AM MyDeveloper Day via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I've made the change > > https://reviews.llvm.org/harbormaster/plan/5/ > > MyDeveloperDay <https://reviews.llvm.org/p/MyDeveloperDay/> changed the Hold > Drafts

This is configured in the "pre-merge checks" build plan, the "Hold Drafts" needs to be set to "Never" I should be able to change this in the build plan if you want but I don't want to step on anyone's toes MyDeveloperDay On Tue, Jul 28, 2020 at 1:35 PM MyDeveloper Day <mydeveloperday at gmail.com> wrote: > See the "Draft Mode" changes,

I 100% get that we might not like the decisions clang-format is making, but how does one overcome this when adding new code? The pre-merge checks enforce clang-formatting before commit and that's a common review comment anyway for those who didn't join the pre-merge checking group. I'm just wondering are we not all following the same guidelines? Concerns of clang-format not being good

The flang sub-project is supposed to be fully formatted so it wouldn’t be hard to get to 100% for a test like this and we would be happy to participate. We were at 100% at one point but there are about 10 files that need formatting now, in part because of changes to clang-format. It would be good to get early warning of clang-format changes like that. Let me know if there is anything I can do to

Could we ever consider adding https://github.com/r4nt/phabricator/tree/llvm-production as a new read/only observe Diffusion repository in reviews.llvm.org? I'd be happy to do code reviews? MyDeveloperDay On Tue, Jul 28, 2020 at 8:46 PM MyDeveloper Day <mydeveloperday at gmail.com> wrote: > Awesome, thanks for sharing > > Here is a patch (based off yours) but this adds the

On Tue, Jul 28, 2020 at 3:29 PM James Y Knight <jyknight at google.com> wrote: > > Please assume good faith -- I'm pretty sure this is simply a configuration mistake, since Mehdi just upgraded Phabricator to a new upstream revision last night. > Probably the default behavior changed in the new upstream version, and it just needs to be turned off. Yep, that's why i'm

Hi MyDeveloperDay, We are using the released version of clang-format / clang-tidy (not necessarily the latest release). I think it makes sense to use most recent versions of the tools: https://github.com/google/llvm-premerge-checks/issues/196 Kind regards, Mikhail On Wed, Jun 3, 2020 at 3:40 PM MyDeveloper Day <mydeveloperday at gmail.com> wrote: > Mikhail > > Firstly let me

On Tue, Jul 28, 2020 at 11:04 AM MyDeveloper Day <mydeveloperday at gmail.com> wrote: > Out of interest are you keeping the local modifications in a fork of the > Phabricator source (llvm-phabricator)? Firstly we should be keeping any > changes we make in source control but also it's good to review those > changes. > I didn't innovate, Manuel set it up originally and

PaulR (sorry again if this is known knowledge) > There's no reason for Herald to be adding project LLVM/subscriber llvm-commits at the last second here. Its possible the rL (LLVM) had be added as the repository in the review on creation rather than rCFE, if thats the case then the herald rule "H270" is going to fire because it see the repository in the review, so add LLVM

I'm not sure if this is well known, but it helped me so I thought I'd share it with you. When committing to gitmonorepo, (with git llvm push) you need to have committed to your local repo first and so you need to have crafted your commit message from your the Phabricator revision. (e.g. D12345) Phabricator has the ability to give you this commit message it would have used, even if you do

Hello friends, We are switching the pre-merge test build system from Jenkins to Buildkite. That will give authors and reviewers more transparency on what's going on during the build process. For now only members of "pre-merge beta testing" [0] group are affected. As usual, please tell us if something is off. [0] https://reviews.llvm.org/project/view/78/ Kind regards, Mikhail

Hello, Is there a way for Phabricator to retain the patches as originally uploaded? When using the "Download Raw Diff" button, it seems Phabricator reformats the patch, loosing the parent commit along the way, so often patches don't apply. The following works, because I've got the latest checkout on master, and the patch was rebased recently: F:\llvm-project>curl

I actually run a in-house Phabricator instance with 400+ users and multiple git repo including custom extension developments I also follow the Phabricator development quite closely because we upgrade every couple of weeks I’d be more than happy to help maintain the phab instance for LLVM MyDeveloperDay On Fri, 31 May 2019 at 09:19, Manuel Klimek via llvm-dev < llvm-dev at lists.llvm.org>

I tweaked the notifications yesterday, hopefully we don't see more spam storms. For filtering git refs: this is something that has changed substantially in Phabricator over the past couple of months, but I think I've managed to restrict notifications to only "master." (Although, again, this has changed a lot... getting this right depends on my own archaeological skills for

On Sat, Jun 1, 2019 at 5:29 AM <paul.robinson at sony.com> wrote: > One particular change: I've disabled notifications for the duplicate > Subversion meta-repos... so, for example, a commit to Clang will still get > 2 notifications (rL and rG). Before yesterday, this should have sent 3: one > each for rL, rG, and rC. Projects not in the monorepo will get > notifications

On Tue, Jul 28, 2020 at 4:25 AM James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > Thanks for the work too! > > Not specifically a regression, but since the upgrade, I find it annoying > now that when I want to do something in relation to an inline comment > (collapse it, reply to it etc), I now have to click on a drop-down menu in > the comment header bar to

Hi Tanya, Last time I noticed a problem with clang-tools-extra docs you could help solving them. If someone else is taking care of this part of the infrastructure now, please redirect appropriately. It looks like docs generated from rst (for LLVM, Clang and clang-tools-extra) don't get updated at the moment. They stopped updating somewhere between r353327

I''ve configured puppet to use storedconfigs and puppetDB, If I start the puppet master using the init script puppetmaster I get a permission denied error when a node connects: Master: [root@puppet ~]# service puppetmaster start Starting puppetmaster: [ OK ] Node: [root@puppet-slave ~]# puppet agent --test err: Could not retrieve catalog from remote