Zulip streams were renamed over a year ago

src/about-this-guide.md

@@ -73,7 +73,7 @@ You might also find the following sites useful:
 - [compiler-team] -- the home-base for the Rust compiler team, with description
   of the team procedures, active working groups, and the team calendar.
 - [std-dev-guide] -- a similar guide for developing the standard library.
-- [The t-compiler zulip][z]
+- [The t-compiler Zulip][z]
 - The [Rust Internals forum][rif], a place to ask questions and
   discuss Rust's internals
 - The [Rust reference][rr], even though it doesn't specifically talk about

src/backend/debugging.md

@@ -183,7 +183,7 @@ The quick summary is:
 ### Getting help and asking questions
 
 If you have some questions, head over to the [rust-lang Zulip] and
-specifically the `#t-compiler/wg-llvm` stream.
+specifically the `#t-compiler/wg-llvm` channel.
 
 [rust-lang Zulip]: https://rust-lang.zulipchat.com/
 

src/compiler-team.md

@@ -12,7 +12,7 @@ contributions to rustc and its design.
 Currently the compiler team chats in Zulip:
 
 - Team chat occurs in the [`t-compiler`][zulip-t-compiler] stream on the Zulip instance
-- There are also a number of other associated Zulip streams,
+- There are also a number of other associated Zulip channels,
   such as [`t-compiler/help`][zulip-help], where people can ask for help
   with rustc development, or [`t-compiler/meetings`][zulip-meetings],
   where the team holds their weekly triage and steering meetings.

src/contributing.md

@@ -74,7 +74,7 @@ Example of things that might require MCPs include major refactorings, changes
 to important types, or important changes to how the compiler does something, or
 smaller user-facing changes.
 
-**When in doubt, ask on [zulip]. It would be a shame to put a lot of work
+**When in doubt, ask on [Zulip]. It would be a shame to put a lot of work
 into a PR that ends up not getting merged!** [See this document][mcpinfo] for
 more info on MCPs.
 
@@ -126,7 +126,7 @@ when contributing to Rust under [the git section](./git.md).
 > from), and work with the compiler team to see if we can help you **break down a large potentially
 > unreviewable PR into a series of smaller more individually reviewable PRs**.
 >
-> You can communicate with the compiler team by creating a [#t-compiler thread on zulip][t-compiler]
+> You can communicate with the compiler team by creating a [#t-compiler thread on Zulip][t-compiler]
 > to discuss your proposed changes.
 >
 > Communicating with the compiler team beforehand helps in several ways:

src/notification-groups/arm.md

@@ -9,7 +9,7 @@ This list will be used to ask for help both in diagnosing and testing
 ARM-related issues as well as suggestions on how to resolve
 interesting questions regarding our ARM support.
 
-The group also has an associated Zulip stream ([`#t-compiler/arm`])
+The group also has an associated Zulip channel ([`#t-compiler/arm`])
 where people can go to pose questions and discuss ARM-specific
 topics.
 

src/notification-groups/emscripten.md

@@ -9,7 +9,7 @@ This list will be used to ask for help both in diagnosing and testing
 Emscripten-related issues as well as suggestions on how to resolve
 interesting questions regarding our Emscripten support.
 
-The group also has an associated Zulip stream ([`#t-compiler/wasm`])
+The group also has an associated Zulip channel ([`#t-compiler/wasm`])
 where people can go to pose questions and discuss Emscripten-specific
 topics.
 

src/notification-groups/risc-v.md

@@ -9,7 +9,7 @@ This list will be used to ask for help both in diagnosing and testing
 RISC-V-related issues as well as suggestions on how to resolve
 interesting questions regarding our RISC-V support.
 
-The group also has an associated Zulip stream ([`#t-compiler/risc-v`])
+The group also has an associated Zulip channel ([`#t-compiler/risc-v`])
 where people can go to pose questions and discuss RISC-V-specific
 topics.
 

src/notification-groups/rust-for-linux.md

@@ -12,7 +12,7 @@ and features. The RfL maintainers should then ideally provide support
 for resolving the breakage or decide to temporarily accept the breakage
 and unblock CI by temporarily removing the RfL CI jobs.
 
-The group also has an associated Zulip stream ([`#rust-for-linux`])
+The group also has an associated Zulip channel ([`#rust-for-linux`])
 where people can go to ask questions and discuss topics related to Rust
 for Linux.
 

src/notification-groups/wasi.md

@@ -9,7 +9,7 @@ This list will be used to ask for help both in diagnosing and testing
 WASI-related issues as well as suggestions on how to resolve
 interesting questions regarding our WASI support.
 
-The group also has an associated Zulip stream ([`#t-compiler/wasm`])
+The group also has an associated Zulip channel ([`#t-compiler/wasm`])
 where people can go to pose questions and discuss WASI-specific
 topics.
 

src/notification-groups/wasm.md

@@ -9,7 +9,7 @@ This list will be used to ask for help both in diagnosing and testing
 WebAssembly-related issues as well as suggestions on how to resolve
 interesting questions regarding our WASM support.
 
-The group also has an associated Zulip stream ([`#t-compiler/wasm`])
+The group also has an associated Zulip channel ([`#t-compiler/wasm`])
 where people can go to pose questions and discuss WASM-specific
 topics.
 

src/notification-groups/windows.md

@@ -9,7 +9,7 @@ This list will be used to ask for help both in diagnosing and testing
 Windows-related issues as well as suggestions on how to resolve
 interesting questions regarding our Windows support.
 
-The group also has an associated Zulip stream ([`#t-compiler/windows`])
+The group also has an associated Zulip channel ([`#t-compiler/windows`])
 where people can go to pose questions and discuss Windows-specific
 topics.
 

src/rustdoc.md

@@ -107,7 +107,7 @@ This comes with several caveats: in particular, rustdoc *cannot* run any parts o
 require type-checking bodies; for example it cannot generate `.rlib` files or run most lints.
 We want to move away from this model eventually, but we need some alternative for
 [the people using it][async-std]; see [various][zulip stop accepting broken code]
-[previous][rustdoc meeting 2024-07-08] [zulip][compiler meeting 2023-01-26] [discussion][notriddle rfc].
+[previous][rustdoc meeting 2024-07-08] [Zulip][compiler meeting 2023-01-26] [discussion][notriddle rfc].
 For examples of code that breaks if this hack is removed, see
 [`tests/rustdoc-ui/error-in-impl-trait`].
 

src/solve/caching.md

@@ -106,7 +106,7 @@ We can implement this optimization in the future.
 [`provisional_result`]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_trait_selection/src/solve/search_graph.rs#L57
 [initial-prov-result]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_trait_selection/src/solve/search_graph.rs#L366-L370
 [fixpoint]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_trait_selection/src/solve/search_graph.rs#L425-L446
-[^2]: summarizing the relevant [zulip thread]
+[^2]: summarizing the relevant [Zulip thread]
 
 [zulip thread]: https://rust-lang.zulipchat.com/#narrow/stream/364551-t-types.2Ftrait-system-refactor/topic/global.20cache
 [unstable-result-ex]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/tests/ui/traits/next-solver/cycles/coinduction/incompleteness-unstable-result.rs#L4-L16

src/solve/the-solver.md

@@ -71,6 +71,6 @@ fails.
 ## Learning more
 
 The solver should be fairly self-contained. I hope that the above information provides a
-good foundation when looking at the code itself. Please reach out on zulip if you get stuck
+good foundation when looking at the code itself. Please reach out on Zulip if you get stuck
 while doing so or there are some quirks and design decisions which were unclear and deserve
 better comments or should be mentioned here.

src/traits/chalk.md

@@ -5,7 +5,7 @@
 Its goal is to enable a lot of trait system features and bug fixes
 that are hard to implement (e.g. GATs or specialization). If you would like to
 help in hacking on the new solver, drop by on the rust-lang Zulip in the [`#t-types`]
-stream and say hello!
+channel and say hello!
 
 [Types team]: https://github.com/rust-lang/types-team
 [`#t-types`]: https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types

src/typing_parameter_envs.md

@@ -82,7 +82,7 @@ In the large majority of cases, when a `ParamEnv` is required it either already
 - In the next-gen trait solver all `Goal`s have a [`param_env` field][goal_param_env] specifying what environment to prove the goal in
 - When editing an existing [`TypeRelation`][typerelation] if it implements [`PredicateEmittingRelation`][predicate_emitting_relation] then a [`param_env` method][typerelation_param_env] will be available.
 
-If you aren't sure if there's a `ParamEnv` in scope somewhere that can be used it can be worth opening a thread in the [`#t-compiler/help`][compiler_help] zulip stream where someone may be able to point out where a `ParamEnv` can be acquired from.
+If you aren't sure if there's a `ParamEnv` in scope somewhere that can be used it can be worth opening a thread in the [`#t-compiler/help`][compiler_help] Zulip channel where someone may be able to point out where a `ParamEnv` can be acquired from.
 
 Manually constructing a `ParamEnv` is typically only needed at the start of some kind of top level analysis (e.g. hir typeck or borrow checking). In such cases there are three ways it can be done:
 - Calling the [`tcx.param_env(def_id)` query][param_env_query] which returns the environment associated with a given definition.