| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rust_analyzer_helix.toml: add library/ manifest
|
|
|
|
Also, sort list
|
|
|
|
|
|
Fix missing rustfmt in msi installer #101993
# Context
- Fixed missing `rustfmt`, `clippy`, `miri` and `rust-analyzer` in msi installer
- Fixed missing `rustfmt` for apple darwin installer
- Closes #101993
r? `@jyn514`
- Please let me know if I should request from someone else instead. I divided the changes into 3 separate commits for the ease of review. The refactoring commit `fbdfd5c03c3c979bcf105ccdd05ff4ab9f37a763` is a bit more involved, but I think it helps in the long term for readability and to avoid bugs.
- I changed `build-manifest` to `build_manifest` in order to invoke it as a library. Not sure if this is gonna break any upstream processes. I checked `generate-manifest-list` and `generate-release` but didn't find any obvious reference
- Will push fixes for linting later
|
|
|
|
|
|
Consolidate LSP setup for different editors into one `./x setup editor`.
|
|
|
|
|
|
Add support for automatically setting up the recommended
LSP config for Emacs.
Additionally, refactor setup.rs to make it easier to add support
for more editors in the future.
|
|
etc: Add sample rust-analyzer configs for eglot & helix
LSP configuration in editors like Emacs (eglot) and helix does not
use the same JSON format as vscode and vim do. It is not obvious
how to set up LSP for rustc in those editors and the dev guide currently
does not cover them. Adding sample configuration files for those editors
alongside the currently existing JSON one would be helpful.
I figured having those included in the repo like the JSON one might save
someone some time and frustration otherwise spent on trying to get the
more niche editors' LSP to work properly. I'll add a section in the dev
guide too.
|
|
LSP configuration in editors like Emacs (eglot) and helix does not
use the same JSON format as vscode and vim do. It is not obvious
how to set up LSP for rustc in those editors and the dev guide currently
does not cover them. Adding sample configuration files for those editors
alongside the currently existing JSON one would be helpful.
|
|
Add the library workspace to the suggested rust-analyzer config
|
|
|
|
|
|
|
|
Running `cargo update` changed completion output. Regenerate them here.
|
|
to pick up changes to `./x miri` and `./x test` commands
|
|
|
|
|
|
|
|
The existing implementation uses Python to launch a set of Rust-written
binaries. Unfortunately, this is currently broken; it seems that some
updates meant it no longer compiles.
There is also a problem that support for more float types (`f16`,
`f128`) would be difficult to add since this is very specialized to
`f32` and `f64`.
Because of these sortcomings, migrate to a version written in Rust. This
version should be significantly faster; test generators can execute in
parallel, and test cases are chunked and parallelized. This should also
resolve the preexisting "... the worker processes are leaked and stick
around forever" comment.
This change also introduces genericism over float types and properties,
meaning it will be much easier to extend support to newly added types.
`num::BigRational` is used in place of Python's fractions for
infinite-precision calculations.
|
|
|
|
Add Natvis visualiser and debuginfo tests for `f16`
To render `f16`s in debuggers on MSVC targets, this PR changes the compiler to output `f16`s as `struct f16 { bits: u16 }`, and includes a Natvis visualiser that manually converts the `f16`'s bits to a `float` which is can then be displayed by debuggers. `gdb`, `lldb` and `cdb` tests are also included for `f16` .
`f16`/`f128` MSVC debug info issue: #121837
Tracking issue: #116909
|
|
|
|
|
|
|
|
|
|
|
|
remove `GIT_DIR` handling in pre-push hook
This is already handled from bootstrap: https://github.com/rust-lang/rust/blob/a1ca449981e3b8442e358026437b7bedb9a1458e/src/bootstrap/src/utils/helpers.rs#L504-L506
|
|
This is already handled from bootstrap at
https://github.com/rust-lang/rust/blob/a1ca449981e3b8442e358026437b7bedb9a1458e/src/bootstrap/src/utils/helpers.rs#L504-L506.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
By default, `x fmt` formats/checks modified files. But it also lets you
choose one or more paths instead.
This adds significant complexity to `x fmt`. Explicit paths are
specified via `WalkBuilder::add` rather than `OverrideBuilder::add`. The
`ignore` library is not simple, and predicting the interactions between
the two mechanisms is difficult.
Here's a particularly interesting case.
- You can request a path P that is excluded by the `ignore` list in the
`rustfmt.toml`. E.g. `x fmt tests/ui/` or `x fmt tests/ui/bitwise.rs`.
- `x fmt` will add P to the walker (via `WalkBuilder::add`), traverse it
(paying no attention to the `ignore` list from the `rustfmt.toml`
file, due to the different mechanism), and call `rustfmt` on every
`.rs` file within it.
- `rustfmt` will do nothing to those `.rs` files, because it *also*
reads `rustfmt.toml` and sees that they match the `ignore` list!
It took me *ages* to debug and understand this behaviour. Not good!
`x fmt` even lets you name a path below the current directory. This was
intended to let you do things like `x fmt std` that mirror things like
`x test std`. This works by looking for `std` and finding `library/std`,
and then formatting that. Unfortuantely, this motivating case now gives
an error. When support was added in #107944, `library/std` was the only
directory named `std`. Since then, `tests/ui/std` was added, and so `x
fmt std` now gives an error.
In general, explicit paths don't seem particularly useful. The only two
cases `x fmt` really needs are:
- format/check the files I have modified (99% of uses)
- format/check all files
(While respecting the `ignore` list in `rustfmt.toml`, of course.)
So this commit moves to that model. `x fmt` will now give an error if
given an explicit path. `x fmt` now also supports a `--all` option. (And
running with `GITHUB_ACTIONS=true` also causes everything to be
formatted/checked, as before.) Much simpler!
|
|
|
|
Summary:
I landed a fix last year to enable `DW_TAG_variant_part` encoding in LLDBs (https://reviews.llvm.org/D149213). This PR is a corresponding fix in synthetic formatters to decode that information.
This is in no way perfect implementation but at least it improves the status quo. But most types of enums will be visible and debuggable in some way.
I've also updated most of the existing tests that touch enums and re-enabled test cases based on LLDB for enums.
Test Plan:
ran tests `./x test tests/debuginfo/`. Also tested manually in LLDB CLI and LLDB VSCode
Other Thoughs
A better approach would probably be adopting [formatters from codelldb](https://github.com/vadimcn/codelldb/blob/master/formatters/rust.py). There is some neat hack that hooks up summary provider via synthetic provider which can ultimately fix more display issues for Rust types and enums too. But getting it to work well might take more time that I have right now.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Support running library tests in Miri
This adds a new bootstrap subcommand `./x.py miri` which can test libraries in Miri. This is in preparation for eventually doing that as part of bors CI, but this PR only adds the infrastructure, and doesn't enable it yet.
`@rust-lang/bootstrap` should this be `x.py test --miri library/core` or `x.py miri library/core`? The flag has the advantage that we don't have to copy all the arguments from `Subcommand::Test`. It has the disadvantage that most test steps just ignore `--miri` and still run tests the regular way. For clippy you went the route of making it a separate subcommand. ~~I went with a flag now as that seemed easier, but I can change this.~~ I made it a new subcommand. Note however that the regular cargo invocation would be `cargo miri test ...`, so `x.py` is still going to be different in that the `test` is omitted. That said, we could also make it `./x.py miri-test` to make that difference smaller -- that's in fact more consistent with the internal name of the command when bootstrap invokes cargo.
`@rust-lang/libs` ~~unfortunately this PR does some unholy things to the `lib.rs` files of our library crates.~~
`@m-ou-se` found a way that entirely avoids library-level hacks, except for some new small `lib.miri.rs` files that hopefully you will never have to touch. There's a new hack in cargo-miri but there it is in good company...
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/120553
Fixes https://github.com/rust-lang/rust/issues/48462
|
|
r=oli-obk,wesleywiser
Move generic `NonZero` `rustc_layout_scalar_valid_range_start` attribute to inner type.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
r? `@dtolnay`
|
|
|
|
|
|
|
|
|
|
This commit removes the `wasm32-shim.js` file, for example, and deletes
old support for Emscripten which hasn't been exercised in some time.
|
|
|
|
Rename `pointer` field on `Pin`
A few days ago, I was helping another user create a self-referential type using `PhantomPinned`. However, I noticed an odd behavior when I tried to access one of the type's fields via `Pin`'s `Deref` impl:
```rust
use std::{marker::PhantomPinned, ptr};
struct Pinned {
data: i32,
pointer: *const i32,
_pin: PhantomPinned,
}
fn main() {
let mut b = Box::pin(Pinned {
data: 42,
pointer: ptr::null(),
_pin: PhantomPinned,
});
{
let pinned = unsafe { b.as_mut().get_unchecked_mut() };
pinned.pointer = &pinned.data;
}
println!("{}", unsafe { *b.pointer });
}
```
```rust
error[E0658]: use of unstable library feature 'unsafe_pin_internals'
--> <source>:19:30
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^
error[E0277]: `Pinned` doesn't implement `std::fmt::Display`
--> <source>:19:20
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^^^^^^^^^^^^^ `Pinned` cannot be formatted with the default formatter
|
= help: the trait `std::fmt::Display` is not implemented for `Pinned`
= note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Since the user named their field `pointer`, it conflicts with the `pointer` field on `Pin`, which is public but unstable since Rust 1.60.0 with #93176. On versions from 1.33.0 to 1.59.0, where the field on `Pin` is private, this program compiles and prints `42` as expected.
To avoid this confusing behavior, this PR renames `pointer` to `__pointer`, so that it's less likely to conflict with a `pointer` field on the underlying type, as accessed through the `Deref` impl. This is technically a breaking change for anyone who names their field `__pointer` on the inner type; if this is undesirable, it could be renamed to something more longwinded. It's also a nightly breaking change for any external users of `unsafe_pin_internals`.
|
