Prepare beta 1.49.0 #79132
Prepare beta 1.49.0 #79132
Conversation
If the LLVM was externally provided, then we don't currently copy artifacts into the sysroot. This is not necessarily the right choice (in particular, it will require the LLVM dylib to be in the linker's load path at runtime), but the common use case for external LLVMs is distribution provided LLVMs, and in that case they're usually in the standard search path (e.g., /usr/lib) and copying them here is going to cause problems as we may end up with the wrong files and isn't what distributions want. This behavior may be revisited in the future though.
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com> Co-authored-by: Jonas Schievink <jonasschievink@gmail.com> Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>
Co-authored-by: Camelid <camelidcamel@gmail.com> Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
…ackline in source rendering
|
@bors r+ p=10 rollup=never |
|
📌 Commit d2df222 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit d2df222 with merge b76bca10782295d1faacf308d34d9616667f17fa... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
Hmm, what. Running |
|
@bors r+ Cherry-picked a bump of the stderr file for that test. I suspect this is the same problem I saw last time, but I haven't had a chance to look into it much. My loose recollection is there's some channel dependency, but I don't recall why I concluded as such. |
bors
added
S-waiting-on-bors
jyn514
added
the
T-release
|
⌛ Testing commit 6142bf6 with merge b201852ebca131fc017548afea819082cc137d00... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
Ok, I think I have an understanding of why this is an error. #75914 merged in the 1.49 cycle (the beta this PR kicks off). RLS on aarch64 windows never compiled, because winapi 0.2 isn't compatible with aarch64 (it defines some types only on x86 and x86_64). We missed this earlier because toolstate is only looked at by default for x86_64 on the dashboard at https://rust-lang-nursery.github.io/rust-toolstate/. I'm not sure what the right step here is. I suspect the best bet is probably to just disable RLS on aarch64 Windows, though we may encounter the same problem with other tools (haven't checked). I will try to implement that later today or someone else can take a stab. |
|
RLS has an issue for aarch64 windows: rust-lang/rls#1693 |
|
@bors r+ Pushed a commit that should just permit the failure of RLS on aarch64 Windows, which should fix this. I think for now that's fine. |
|
📌 Commit 7477867 has been approved by |
bors
added
S-waiting-on-bors
|
I haven't noticed it earlier but you might want to include #79141 if this PR fails again. |
|
☀️ Test successful - checks-actions |
…k-Simulacrum" This was landed on master instead of beta!
Revert rust-lang#79132 The beta promotion release was mistakenly landed on master instead of beta. Ugh. r? `@ghost` cc `@rust-lang/release`
Actually prepare beta 1.49.0 This PR sets everything up for beta 1.49.0, and backports the following PRs to it: * rust-lang#79107 - build-manifest: strip newline from rustc version * rust-lang#78986 - Avoid installing external LLVM dylibs * rust-lang#79074 - Install CI llvm into the library directory * rust-lang#78364 - Update RELEASES.md for 1.48.0 * rust-lang#77939 - Ensure that the source code display is working with DOS backline This is the same as rust-lang#79132, but actually targeting the right branch. r? `@ghost` cc `@rust-lang/release`
This PR sets everything up for beta 1.49.0, and backports the following PRs to it:
r? @ghost
cc @rust-lang/release