mirror of
https://github.com/astral-sh/ruff.git
synced 2025-09-29 21:34:57 +00:00

## Summary
This PR implements support for providing LSP client settings.
The complementary PR in the ty VS Code extension:
astral-sh/ty-vscode#106.
Notes for the previous iteration of this PR is in
https://github.com/astral-sh/ruff/pull/19614#issuecomment-3136477864
(click on "Details").
Specifically, this PR splits the client settings into 3 distinct groups.
Keep in mind that these groups are not visible to the user, they're
merely an implementation detail. The groups are:
1. `GlobalOptions` - these are the options that are global to the
language server and will be the same for all the workspaces that are
handled by the server
2. `WorkspaceOptions` - these are the options that are specific to a
workspace and will be applied only when running any logic for that
workspace
3. `InitializationOptions` - these are the options that can be specified
during initialization
The initialization options are a superset that contains both the global
and workspace options flattened into a 1-dimensional structure. This
means that the user can specify any and all fields present in
`GlobalOptions` and `WorkspaceOptions` in the initialization options in
addition to the fields that are _specific_ to initialization options.
From the current set of available settings, following are only available
during initialization because they are required at that time, are static
during the runtime of the server and changing their values require a
restart to take effect:
- `logLevel`
- `logFile`
And, following are available under `GlobalOptions`:
- `diagnosticMode`
And, following under `WorkspaceOptions`:
- `disableLanguageServices`
- `pythonExtension` (Python environment information that is populated by
the ty VS Code extension)
### `workspace/configuration`
This request allows server to ask the client for configuration to a
specific workspace. But, this is only supported by the client that has
the `workspace.configuration` client capability set to `true`. What to
do for clients that don't support pulling configurations?
In that case, the settings needs to be provided in the initialization
options and updating the values of those settings can only be done by
restarting the server. With the way this is implemented, this means that
if the client does not support pulling workspace configuration then
there's no way to specify settings specific to a workspace. Earlier,
this would've been possible by providing an array of client options with
an additional field which specifies which workspace the options belong
to but that adds complexity and clients that actually do not support
`workspace/configuration` would usually not support multiple workspaces
either.
Now, for the clients that do support this, the server will initiate the
request to get the configuration for all the workspaces at the start of
the server. Once the server receives these options, it will resolve them
for each workspace as follows:
1. Combine the client options sent during initialization with the
options specific to the workspace creating the final client options
that's specific to this workspace
2. Create a global options by combining the global options from (1) for
all workspaces which in turn will also combine the global options sent
during initialization
The global options are resolved into the global settings and are
available on the `Session` which is initialized with the default global
settings. The workspace options are resolved into the workspace settings
and are available on the respective `Workspace`.
The `SessionSnapshot` contains the global settings while the document
snapshot contains the workspace settings. We could add the global
settings to the document snapshot but that's currently not needed.
### Document diagnostic dynamic registration
Currently, the document diagnostic server capability is created based on
the `diagnosticMode` sent during initialization. But, that wouldn't
provide us with the complete picture. This means the server needs to
defer registering the document diagnostic capability at a later point
once the settings have been resolved.
This is done using dynamic registration for clients that support it. For
clients that do not support dynamic registration for document diagnostic
capability, the server advertises itself as always supporting workspace
diagnostics and work done progress token.
This dynamic registration now allows us to change the server capability
for workspace diagnostics based on the resolved `diagnosticMode` value.
In the future, once `workspace/didChangeConfiguration` is supported, we
can avoid the server restart when users have changed any client
settings.
## Test Plan
Add integration tests and recorded videos on the user experience in
various editors:
### VS Code
For VS Code users, the settings experience is unchanged because the
extension defines it's own interface on how the user can specify the
server setting. This means everything is under the `ty.*` namespace as
usual.
https://github.com/user-attachments/assets/c2e5ba5c-7617-406e-a09d-e397ce9c3b93
### Zed
For Zed, the settings experience has changed. Users can specify settings
during initialization:
```json
{
"lsp": {
"ty": {
"initialization_options": {
"logLevel": "debug",
"logFile": "~/.cache/ty.log",
"diagnosticMode": "workspace",
"disableLanguageServices": true
}
},
}
}
```
Or, can specify the options under the `settings` key:
```json
{
"lsp": {
"ty": {
"settings": {
"ty": {
"diagnosticMode": "openFilesOnly",
"disableLanguageServices": true
}
},
"initialization_options": {
"logLevel": "debug",
"logFile": "~/.cache/ty.log"
}
},
}
}
```
The `logLevel` and `logFile` setting still needs to go under the
initialization options because they're required by the server during
initialization.
We can remove the nesting of the settings under the "ty" namespace by
updating the return type of
db9ea0cdfd/src/tychecker.rs (L45-L49)
to be wrapped inside `ty` directly so that users can avoid doing the
double nesting.
There's one issue here which is that if the `diagnosticMode` is
specified in both the initialization option and settings key, then the
resolution is a bit different - if either of them is set to be
`workspace`, then it wins which means that in the following
configuration, the diagnostic mode is `workspace`:
```json
{
"lsp": {
"ty": {
"settings": {
"ty": {
"diagnosticMode": "openFilesOnly"
}
},
"initialization_options": {
"diagnosticMode": "workspace"
}
},
}
}
```
This behavior is mainly a result of combining global options from
various workspace configuration results. Users should not be able to
provide global options in multiple workspaces but that restriction
cannot be done on the server side. The ty VS Code extension restricts
these global settings to only be set in the user settings and not in
workspace settings but we do not control extensions in other editors.
https://github.com/user-attachments/assets/8e2d6c09-18e6-49e5-ab78-6cf942fe1255
### Neovim
Same as in Zed.
### Other
Other editors that do not support `workspace/configuration`, the users
would need to provide the server settings during initialization.
159 lines
4.9 KiB
Rust
159 lines
4.9 KiB
Rust
//! This crate implements internal macros for the `ruff` and `ty` libraries.
|
|
|
|
use crate::cache_key::derive_cache_key;
|
|
use crate::newtype_index::generate_newtype_index;
|
|
use crate::violation_metadata::violation_metadata;
|
|
use proc_macro::TokenStream;
|
|
use syn::{DeriveInput, Error, ItemFn, ItemStruct, parse_macro_input};
|
|
|
|
mod cache_key;
|
|
mod combine;
|
|
mod combine_options;
|
|
mod config;
|
|
mod derive_message_formats;
|
|
mod env_vars;
|
|
mod kebab_case;
|
|
mod map_codes;
|
|
mod newtype_index;
|
|
mod rule_code_prefix;
|
|
mod rule_namespace;
|
|
mod rust_doc;
|
|
mod violation_metadata;
|
|
|
|
#[proc_macro_derive(OptionsMetadata, attributes(option, doc, option_group))]
|
|
pub fn derive_options_metadata(input: TokenStream) -> TokenStream {
|
|
let input = parse_macro_input!(input as DeriveInput);
|
|
|
|
config::derive_impl(input)
|
|
.unwrap_or_else(syn::Error::into_compile_error)
|
|
.into()
|
|
}
|
|
|
|
#[proc_macro_derive(RustDoc)]
|
|
pub fn derive_rust_doc(input: TokenStream) -> TokenStream {
|
|
let input = parse_macro_input!(input as DeriveInput);
|
|
|
|
rust_doc::derive_impl(input)
|
|
.unwrap_or_else(syn::Error::into_compile_error)
|
|
.into()
|
|
}
|
|
|
|
#[proc_macro_derive(CombineOptions)]
|
|
pub fn derive_combine_options(input: TokenStream) -> TokenStream {
|
|
let input = parse_macro_input!(input as DeriveInput);
|
|
|
|
combine_options::derive_impl(input)
|
|
.unwrap_or_else(syn::Error::into_compile_error)
|
|
.into()
|
|
}
|
|
|
|
/// Automatically derives a `ty_combine::Combine` implementation for the attributed type
|
|
/// that calls `ty_combine::Combine::combine` for each field.
|
|
///
|
|
/// The derive macro can only be used on structs. Enums aren't yet supported.
|
|
#[proc_macro_derive(Combine)]
|
|
pub fn derive_combine(input: TokenStream) -> TokenStream {
|
|
let input = parse_macro_input!(input as DeriveInput);
|
|
|
|
combine::derive_impl(input)
|
|
.unwrap_or_else(syn::Error::into_compile_error)
|
|
.into()
|
|
}
|
|
|
|
/// Converts an identifier to a kebab case string.
|
|
#[proc_macro]
|
|
pub fn kebab_case(input: TokenStream) -> TokenStream {
|
|
let input = parse_macro_input!(input as syn::Ident);
|
|
|
|
kebab_case::kebab_case(&input).into()
|
|
}
|
|
|
|
/// Generates a [`CacheKey`] implementation for the attributed type.
|
|
///
|
|
/// Struct fields can be attributed with the `cache_key` field-attribute that supports:
|
|
/// * `ignore`: Ignore the attributed field in the cache key
|
|
#[proc_macro_derive(CacheKey, attributes(cache_key))]
|
|
pub fn cache_key(input: TokenStream) -> TokenStream {
|
|
let item = parse_macro_input!(input as DeriveInput);
|
|
|
|
let result = derive_cache_key(&item);
|
|
let stream = result.unwrap_or_else(|err| err.to_compile_error());
|
|
|
|
TokenStream::from(stream)
|
|
}
|
|
|
|
#[proc_macro_derive(ViolationMetadata)]
|
|
pub fn derive_violation_metadata(item: TokenStream) -> TokenStream {
|
|
let input: DeriveInput = parse_macro_input!(item);
|
|
|
|
violation_metadata(input)
|
|
.unwrap_or_else(Error::into_compile_error)
|
|
.into()
|
|
}
|
|
|
|
#[proc_macro_derive(RuleNamespace, attributes(prefix))]
|
|
pub fn derive_rule_namespace(input: TokenStream) -> TokenStream {
|
|
let input = parse_macro_input!(input as DeriveInput);
|
|
|
|
rule_namespace::derive_impl(input)
|
|
.unwrap_or_else(syn::Error::into_compile_error)
|
|
.into()
|
|
}
|
|
|
|
#[proc_macro_attribute]
|
|
pub fn map_codes(_attr: TokenStream, item: TokenStream) -> TokenStream {
|
|
let func = parse_macro_input!(item as ItemFn);
|
|
map_codes::map_codes(&func)
|
|
.unwrap_or_else(syn::Error::into_compile_error)
|
|
.into()
|
|
}
|
|
|
|
#[proc_macro_attribute]
|
|
pub fn derive_message_formats(_attr: TokenStream, item: TokenStream) -> TokenStream {
|
|
let func = parse_macro_input!(item as ItemFn);
|
|
derive_message_formats::derive_message_formats(&func).into()
|
|
}
|
|
|
|
/// Derives a newtype wrapper that can be used as an index.
|
|
/// The wrapper can represent indices up to `u32::MAX - 1`.
|
|
///
|
|
/// The `u32::MAX - 1` is an optimization so that `Option<Index>` has the same size as `Index`.
|
|
///
|
|
/// Can store at most `u32::MAX - 1` values
|
|
///
|
|
/// ## Warning
|
|
///
|
|
/// Additional `derive` attributes must come AFTER this attribute:
|
|
///
|
|
/// Good:
|
|
///
|
|
/// ```ignore
|
|
/// use ruff_macros::newtype_index;
|
|
///
|
|
/// #[newtype_index]
|
|
/// #[derive(Ord, PartialOrd)]
|
|
/// struct MyIndex;
|
|
/// ```
|
|
#[proc_macro_attribute]
|
|
pub fn newtype_index(_metadata: TokenStream, input: TokenStream) -> TokenStream {
|
|
let item = parse_macro_input!(input as ItemStruct);
|
|
|
|
let output = match generate_newtype_index(item) {
|
|
Ok(output) => output,
|
|
Err(err) => err.to_compile_error(),
|
|
};
|
|
|
|
TokenStream::from(output)
|
|
}
|
|
|
|
/// Generates metadata for environment variables declared in the impl block.
|
|
///
|
|
/// This attribute macro should be applied to an `impl EnvVars` block.
|
|
/// It will generate a `metadata()` method that returns all non-hidden
|
|
/// environment variables with their documentation.
|
|
#[proc_macro_attribute]
|
|
pub fn attribute_env_vars_metadata(_attr: TokenStream, item: TokenStream) -> TokenStream {
|
|
let input = parse_macro_input!(item as syn::ItemImpl);
|
|
|
|
env_vars::attribute_env_vars_metadata(input).into()
|
|
}
|