similar to: [RFC] Semi-Automatic clang-format of files with low frequency

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

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

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 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

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

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

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,

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

On Mon, Nov 18, 2019 at 11:55 AM David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 18/11/2019 16:39, Stefan Teleman via llvm-dev wrote: > > I can't recall an instance when I had difficulty using, or was > > intimidated by, email, for saying something on a mailing list. > > Subscribing to a mailing list, particularly one as high-traffic as >

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

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

> > | mailing lists for longer-form discussions are unfamiliar, difficult, > and often intimidating for newcomers > > Um… what? While I know (via my own children) that folks nowadays use > multiple avenues of communication, it’s **really** hard to imagine email > as a **mechanism** being unfamiliar/difficult/intimidating. Moving to a > new mechanism wouldn’t alter the

On Wed, Mar 4, 2020 at 9:42 AM Louis Dionne <ldionne at apple.com> wrote: > > > On Mar 4, 2020, at 12:13, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com> wrote: > >> Mehdi, Chris & others, >> >> I guess I did not express the main reasons for wanting to switch over

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, Oct 25, 2016 at 1:48 PM, Rafael Espíndola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > So, for the declaration, do you expect to know the value? If not just > a declaration to a GlobalVariable should be sufficient. > No, the value will be discovered at link time, but we want instruction selection to treat the symbol as an immediate, not a GlobalAddress that will

I filed a bug a long time ago here: https://bugs.llvm.org/show_bug.cgi?id=41559 It's an issue with how clang format isn't breaking function arguments as expected. I haven't seen a response. How can I go about getting the attention of the developers?

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

On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com> wrote: > Mehdi, Chris & others, > > I guess I did not express the main reasons for wanting to switch over very > well in my original message. > You original message was about “ commit attribution”, but now it is all about testing? Instead of jumping to a solution (pull-request) why not expressing the