std docs should have version info and build date somewhere #17058
Comments
|
I don't think this is a problem with std itself, since the version is in the URL (or it's master, which was built in the past 24 hours). |
|
Not sure where you mean...the std docs URL http://doc.rust-lang.org/std/ doesn't list a version. I don't think it will be a problem for Rust long-term. Once stable, the address will probably be something like |
|
Partly a dupe of #14466. |
|
Yes, this is basically a dup of #14466/ |
lnicola
pushed a commit
to lnicola/rust
that referenced
this issue
Jun 23, 2024
feat: TOML based config for rust-analyzer > Important > > We don't promise _**any**_ stability with this feature yet, any configs exposed may be removed again, the grouping may change etc. # TOML Based Config for RA This PR ( addresses rust-lang#13529 and this is a follow-up PR on rust-lang#16639 ) makes rust-analyzer configurable by configuration files called `rust-analyzer.toml`. Files **must** be named `rust-analyzer.toml`. There is not a strict rule regarding where the files should be placed, but it is recommended to put them near a file that triggers server to start (i.e., `Cargo.{toml,lock}`, `rust-project.json`). ## Configuration Types Previous configuration keys are now split into three different classes. 1. Client keys: These keys only make sense when set by the client (e.g., by setting them in `settings.json` in VSCode). They are but a small portion of this list. One such example is `rust_analyzer.files_watcher`, based on which either the client or the server will be responsible for watching for changes made to project files. 2. Global keys: These keys apply to the entire workspace and can only be set on the very top layers of the hierarchy. The next section gives instructions on which layers these are. 3. Local keys: Keys that can be changed for each crate if desired. ### How Am I Supposed To Know If A Config Is Gl/Loc/Cl ? rust-lang#17101 ## Configuration Hierarchy There are 5 levels in the configuration hierarchy. When a key is searched for, it is searched in a bottom-up depth-first fashion. ### Default Configuration **Scope**: Global, Local, and Client This is a hard-coded set of configurations. When a configuration key could not be found, then its default value applies. ### User configuration **Scope**: Global, Local If you want your configurations to apply to **every** project you have, you can do so by setting them in your `$CONFIG_DIR/rust-analyzer/rust-analyzer.toml` file, where `$CONFIG_DIR` is : | Platform | Value | Example | | ------- | ------------------------------------- | ---------------------------------------- | | Linux | `$XDG_CONFIG_HOME` or `$HOME`/.config | /home/alice/.config | | macOS | `$HOME`/Library/Application Support | /Users/Alice/Library/Application Support | | Windows | `{FOLDERID_RoamingAppData}` | C:\Users\Alice\AppData\Roaming | ### Client configuration **Scope**: Global, Local, and Client Previously, the only way to configure rust-analyzer was to configure it from the settings of the Client you are using. This level corresponds to that. > With this PR, you don't need to port anything to benefit from new features. You can continue to use your old settings as they are. ### Workspace Root Configuration **Scope**: Global, Local Rust-analyzer already used the path of the workspace you opened in your Client. We used this information to create a configuration file that won't affect your other projects and define global level configurations at the same time. ### Local Configuration **Scope**: Local You can also configure rust-analyzer on a crate level. Although it is not an error to define global ( or client ) level keys in such files, they won't be taken into consideration by the server. Defined local keys will affect the crate in which they are defined and crate's descendants. Internally, a Rust project is split into what we call `SourceRoot`s. This, although with exceptions, is equal to splitting a project into crates. > You may choose to have more than one `rust-analyzer.toml` files within a `SourceRoot`, but among them, the one closer to the project root will be
lnicola
pushed a commit
to lnicola/rust
that referenced
this issue
Jul 28, 2024
minor : fixes for ratoml module This is a follow-up PR to rust-lang#17058. - Parse errors are reflected as such by defining a new variant called `ConfigError::ParseError` - New error collection has been added to store config level agnostic errors. EDIT : Some things that this PR promised to solve are removed and will be addressed by other PRs
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this issue
Aug 1, 2024
minor : fixes for ratoml module This is a follow-up PR to rust-lang#17058. - Parse errors are reflected as such by defining a new variant called `ConfigError::ParseError` - New error collection has been added to store config level agnostic errors. EDIT : Some things that this PR promised to solve are removed and will be addressed by other PRs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The std docs should list:
They could be at the top or bottom of every page, or on a stand-alone page like About or Help.
This may not be important on rust-ci.org where I think they are rebuilt with every push but it seems like a good idea. It might be more useful on other sites where it isn't rebuilt for every push.
The text was updated successfully, but these errors were encountered: