@kevingranade @emjonaitis Part of the problem is I do not know for a fact whether any one mitigation will be accepted by a "code assistant" without installing and activating a "code assistant", a thing I will not do. So like if it turns out it checks in .claude but not in .claude_poison, then maybe creating the .claude_poison directory creates the inconvenience of directory junk without having the effect I want.

@mcc @emjonaitis yea, in this specific case it's built into github so you can't *not* have it "installed", but that is a problem.

When we were adding it some people were proposing we add a bunch of different agent files, but when asked weren't actually testing them so what's the point.

Best answer I can come up with is someone takes it on as a infosec-style project and publishes a repo of agent poison pills you can simply incorporate.

@lanodan @nick @mcc gdb will most likely also adopting the same wording as binutils due to the overlap usage of bfd.

As far as mesa and other gui runtimes stuff, that needs to be redone. Gcc or something more. Right now from what I remember Mesa depends on older versions of llvm due to api instability too.

With respect to clang-format, there is some work going on dealing with gcc a68 which might be reused with c/c++ frontends too

@pinskia @lanodan @nick @mcc i should probably switch from clangd to ccls too then, or, i actuaydo the thingies that makes me not need an lsp at all anymore, which would be even better

@lanodan @nick @mcc anyone can ask copilot for review in the GitHub UI and as I understand they still don’t offer a way to turn that off(?) so you can’t blame the project just for the presence in issues. You can blame the project for their policy and the things they choose to merge though.

@porglezomp @lanodan @nick a nice thing about the block warning is assuming microsoft did not code it in an absurd way, the block warning surely applies only to commits in the past of the current branch.

this would be improved if github had not exempted the copilot bot from blocks. they did exempt it from blocks, and if you look in the github feedback forum there's a feature request from me for the day they did it asking them to not-exempt it. oh well…

@nick @mcc thankfully the swift project's fork of LLVM is clean for now:

(or at least, it hasn't been touched by claude yet)
https://github.com/swiftlang/llvm-project

@JamesWidman @nick apple's absurd litigousness pays off possibly for possibly the first time I can think of

@mcc As the old meme goes.. oh no.

@mcc @nick i thought that fork was mainly about extending clang with support for bridging between Objective-C and Swift...? but yeah

@lanodan @nick @mcc that's not true.. they can and historically have used GCC, just preferred to migrate when they could.

freebsd changed from gcc to clang as default for main architectures in 2012 but didn't stop shopping gcc until 2020.

openbsd moved to clang in 2018-2020

nerbsd still uses gcc as default

@lanodan @nick @mcc I hate modern UIs so much...

"Open (85)"
"Closed (384)"
19 pages!
"No results found"

@mcc @bmartin427
Can one block Copilot in the same manner?

@bloognoo @bmartin427 No, I'm not sure if it leaves the co-authored-by tags or not but significantly GitHub special case made the "copilot" account unblockable

@mcc @bmartin427
Bah. Thank you

@JamesWidman @mcc @nick yea its only a matter of rebasing the fork with upstream

@nick @mcc LLVM? Seriously? What is it doing? Trying to put in pull requests for shit? For something like LLVM that seems like a massive security issue.

@nick @mcc RIP