Can anyone test that a
master-built RA is still working? Mine just sits there saying "Rust Analyzer is still loading"
@Laurențiu Nicola vscode version?
Like.. it was working earlier and I don't have any local changes
mine is working in Emacs
working for me in vscode as well with 1.52.1
So it works after a reboot... :confused:
@Laurențiu Nicola no worries, I have your back, I broke it: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/VS.20Code.20requirement.20is.20too.20high/near/220592392 :D
Oof, I permanently broke CI :(. I merged that release PR manually and
xtask tidy complains about a non-bors commit in the history.
$ git pr Current branch master is up to date. $ git rev-list --merges --invert-grep --author 'bors\[bot\]' HEAD~19.. $
I don't get it
rust-analyzer on master [⇡$] via v1.48.0-nightly ❯ git rev-list --merges --invert-grep --author 'bors\[bot\]' HEAD~19.. 02d8cf82ca3ae8f78a642e5c5afc3ade02caa300
I do get a commit when invoking the command after pulling latest master
xtask also fails for me
master branch was tracking my fork. But I still don't know how to fix it.
The only way I see to fix this would be to remove the merge via force push, which sounds less than ideal
This also means CI will always break if bors isnt the one that merged doesn't it
Or to quickly merge 20 pull requests
But that would require bors to merge them all, and since CI fails bors won't merge them will it :sweat_smile:
If we force-push quickly it shouldn't cause issues
Filed another PR
So is there a way to
merge --ff-only it from the GitHub UI? Does "Rebase and merge" do that?
No, I don't think there is
Why doesn't bors work?
Wait, bors just started with https://github.com/rust-analyzer/rust-analyzer/pull/6989
Jonas Schievink said:
Why doesn't bors work?
It used to not work on PRs with workflow changes or that would merge over other workflow changes (e.g. you filed a PR, then the workflows changed on
master). It would time out or not run at all.
oh, weird. I'd expect that to work fine.
bors doesn't even look at workflow files
I think it was a permissions issue (integrations not being able to modify workflows)
But it might be working fine now, I remember seeing it merge (only) one PR
Regarding force pushes -- imo, they are totally OK and overly-demonized. It's like
usnafe -- ok, if you know what you are doing
So feel free to
push --force-with-lease if you need to (but you should understand the difference between
--force-with-lease ;) )
My university completely disabled force pushes even when you disable branch protection by using a push hook. I once had to switch the default branch, delete the original default branch and then recreate it without the commit I wanted to remove.
--force-with-lease is much better than
--force-with-lease should really have been called
To be fair, this used to be reasonable-ish: previously, git defaulted to pushing all branches, and not only the current one, and using
--force with that was problematic
--force-with-lease will become default in some future git version
Some editors like Microsoft's VSC have a feature to auto-fetch in the background, this bypasses the protections offered by
I have that disabled.