Commit graph

7 commits

Author SHA1 Message Date
Julia Ryan
01ec6e0f77
Add workspace-hack (#27277)
This adds a "workspace-hack" crate, see
[mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7)
for a concise explanation of why this is useful. For us in practice this
means that if I were to run all the tests (`cargo nextest r
--workspace`) and then `cargo r`, all the deps from the previous cargo
command will be reused. Before this PR it would rebuild many deps due to
resolving different sets of features for them. For me this frequently
caused long rebuilds when things "should" already be cached.

To avoid manually maintaining our workspace-hack crate, we will use
[cargo hakari](https://docs.rs/cargo-hakari) to update the build files
when there's a necessary change. I've added a step to CI that checks
whether the workspace-hack crate is up to date, and instructs you to
re-run `script/update-workspace-hack` when it fails.

Finally, to make sure that people can still depend on crates in our
workspace without pulling in all the workspace deps, we use a `[patch]`
section following [hakari's
instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html)

One possible followup task would be making guppy use our
`rust-toolchain.toml` instead of having to duplicate that list in its
config, I opened an issue for that upstream: guppy-rs/guppy#481.

TODO:
- [x] Fix the extension test failure
- [x] Ensure the dev dependencies aren't being unified by Hakari into
the main dependencies
- [x] Ensure that the remote-server binary continues to not depend on
LibSSL

Release Notes:

- N/A

---------

Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
2025-04-02 13:26:34 -07:00
Piotr Osiewicz
c9534e8025
chore: Use workspace fields for edition and publish (#23291)
This prepares us for an upcoming bump to Rust 2024 edition.

Release Notes:

- N/A
2025-01-17 17:39:22 +01:00
Bennet Bo Fenner
fb83cf2042
notification panel: rework time formatting (#8997)
Follow up of #7994 to rework the notification panel timestamps.
This PR also includes some of the changes @evrsen proposed in #8996 
Here is what it looks like now:


https://github.com/zed-industries/zed/assets/53836821/d85450e7-eab6-4fe7-bd11-1d76c0e87258

Release Notes:
- Reworked date time formatting in the chat and the notification panel
- Added hover style to notifications and hovering tooltip on timestamps

---------

Co-authored-by: Evren Sen <146845123+evrsen@users.noreply.github.com>
2024-03-12 21:02:04 -06:00
Marshall Bowers
22fe03913c
Move Clippy configuration to the workspace level (#8891)
This PR moves the Clippy configuration up to the workspace level.

We're using the [`lints`
table](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-lints-table)
to configure the Clippy ruleset in the workspace's `Cargo.toml`.

Each crate in the workspace now has the following in their own
`Cargo.toml` to inherit the lints from the workspace:

```toml
[lints]
workspace = true
```

This allows for configuring rust-analyzer to show Clippy lints in the
editor by using the following configuration in your Zed `settings.json`:

```json
{
  "lsp": {
    "rust-analyzer": {
      "initialization_options": {
        "check": {
          "command": "clippy"
        }
      }
    }
  }
```

Release Notes:

- N/A
2024-03-05 12:01:17 -05:00
Marshall Bowers
7f5aa1fca6
Replace lazy_static! with OnceLock in time_format crate (#8648)
This PR replaces a `lazy_static!` usage in the `time_format` crate with
`OnceLock` from the standard library.

This allows us to drop the `lazy_static` dependency from this crate.

Release Notes:

- N/A
2024-02-29 23:58:45 -05:00
Dzmitry Malyshau
cb75c57fc0
Cleanup dependencies (part 4) (#8468)
Follow-up to #8425 . Final part - adds the CI check.

Release Notes:
- N/A
2024-02-27 20:41:49 +02:00
Bennet Bo Fenner
dc7e14f888
Respect user preferences when formatting timestamp (#7994)
This is a follow up to #7945. The current behaviour reads the locale and
infers from that which type of time format should be used (12 hour/24
hour).
However, in macOS you can override this behaviour, e.g. you can use
en_US locale but still use the 24 hour clock format (Can be customized
under Settings > General > Date & Format > 24-hour time). You can even
customize the date format.

This PR uses the macOS specific `CFDateFormatter` API, which outputs
time format strings, that respect those settings.

Partially fixes #7956 (as its not implemented for linux)

Release Notes:

- Added localization support for all macOS specific date and time
configurations in chat
2024-02-23 19:18:06 -07:00