| Age | Commit message (Collapse) | Author | Lines |
|
This reverts commit 8643a858dbaf12b37e90b603cdee64434576c229.
|
|
|
|
|
|
fix: Closure capturing for let exprs
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 31 packages to latest compatible versions
Updating adler2 v2.0.0 -> v2.0.1
Updating cfg-if v1.0.0 -> v1.0.1
Updating clap v4.5.39 -> v4.5.40
Updating clap_builder v4.5.39 -> v4.5.40
Updating clap_derive v4.5.32 -> v4.5.40
Updating clap_lex v0.7.4 -> v0.7.5
Updating getopts v0.2.21 -> v0.2.23
Updating hermit-abi v0.5.1 -> v0.5.2
Updating jiff v0.2.14 -> v0.2.15
Updating jiff-static v0.2.14 -> v0.2.15
Updating libc v0.2.172 -> v0.2.173
Updating memchr v2.7.4 -> v2.7.5
Updating minifier v0.3.5 -> v0.3.6
Updating miniz_oxide v0.8.8 -> v0.8.9
Updating object v0.37.0 -> v0.37.1
Updating redox_syscall v0.5.12 -> v0.5.13
Updating rustc-demangle v0.1.24 -> v0.1.25
Updating syn v2.0.101 -> v2.0.103
Updating thread_local v1.1.8 -> v1.1.9
Updating unicode-width v0.2.0 -> v0.2.1
Updating wasi v0.11.0+wasi-snapshot-preview1 -> v0.11.1+wasi-snapshot-preview1
Updating wasm-encoder v0.233.0 -> v0.235.0
Removing wasmparser v0.232.0
Removing wasmparser v0.233.0
Adding wasmparser v0.234.0
Adding wasmparser v0.235.0
Updating wast v233.0.0 -> v235.0.0
Updating wat v1.233.0 -> v1.235.0
Updating windows v0.61.1 -> v0.61.3
Updating windows-link v0.1.1 -> v0.1.3
Adding windows-sys v0.60.2
Updating windows-targets v0.53.0 -> v0.53.2
Updating winnow v0.7.10 -> v0.7.11
note: pass `--verbose` to see 39 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating libc v0.2.172 -> v0.2.173
note: pass `--verbose` to see 4 unchanged dependencies behind latest
rustbook dependencies:
Locking 19 packages to latest compatible versions
Updating adler2 v2.0.0 -> v2.0.1
Updating cc v1.2.26 -> v1.2.27
Updating cfg-if v1.0.0 -> v1.0.1
Updating clap v4.5.39 -> v4.5.40
Updating clap_builder v4.5.39 -> v4.5.40
Updating clap_complete v4.5.52 -> v4.5.54
Updating clap_derive v4.5.32 -> v4.5.40
Updating clap_lex v0.7.4 -> v0.7.5
Updating getopts v0.2.21 -> v0.2.23
Updating jiff v0.2.14 -> v0.2.15
Updating jiff-static v0.2.14 -> v0.2.15
Updating libc v0.2.172 -> v0.2.173
Updating memchr v2.7.4 -> v2.7.5
Updating miniz_oxide v0.8.8 -> v0.8.9
Updating redox_syscall v0.5.12 -> v0.5.13
Updating syn v2.0.101 -> v2.0.103
Removing unicode-width v0.1.14
Removing unicode-width v0.2.0
Adding unicode-width v0.2.1
Updating windows-link v0.1.1 -> v0.1.3
Updating winnow v0.7.10 -> v0.7.11
```
|
|
use `#[align]` attribute for `fn_align`
Tracking issue: https://github.com/rust-lang/rust/issues/82232
https://github.com/rust-lang/rfcs/pull/3806 decides to add the `#[align]` attribute for alignment of various items. Right now it's used for functions with `fn_align`, in the future it will get more uses (statics, struct fields, etc.)
(the RFC finishes FCP today)
r? `@ghost`
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#135656 (Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused)
- rust-lang/rust#138237 (Get rid of `EscapeDebugInner`.)
- rust-lang/rust#141614 (lint direct use of rustc_type_ir )
- rust-lang/rust#142123 (Implement initial support for timing sections (`--json=timings`))
- rust-lang/rust#142377 (Try unremapping compiler sources)
- rust-lang/rust#142674 (remove duplicate crash test)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Try unremapping compiler sources
See [#t-compiler/help > Span pointing to wrong file location (`rustc-dev` component)](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Span.20pointing.20to.20wrong.20file.20location.20.28.60rustc-dev.60.20component.29/with/521087083).
This PR is a follow-up to rust-lang/rust#141751 regarding the compiler side.
Specifically we now take into account the `CFG_VIRTUAL_RUSTC_DEV_SOURCE_BASE_DIR` env from rust-lang/rust#141751 when trying to unremap sources from `$sysroot/lib/rustlib/rustc-src/rust` (the `rustc-dev` component install directory).
Best reviewed commit by commit.
cc ``@samueltardieu``
r? ``@jieyouxu``
|
|
|
|
Clarify bootstrap tools description
The existence of `stage0-bootstrap-tools` suggests the possiblity of `stage1/N-bootstrap-tools`, but that's not really a thing. Also it doesn't fit the new bootstrap model, where `stageN` essentially means that it was built with a `stageN-1` compiler (except for std).
r? ``@jieyouxu``
|
|
Skip tidy triagebot linkcheck if `triagebot.toml` doesn't exist
Since distribution tarballs won't include `triagebot.toml`.
I think it's sufficiently obvious if `triagebot.toml` gets deleted entirely in PRs.
r? Kobzol
|
|
apply clippy::or_fun_call
Applies https://rust-lang.github.io/rust-clippy/master/index.html?groups=nursery#or_fun_call to reduce needless allocs.
|
|
r=lcnr,traviscross
Stabilize `feature(generic_arg_infer)`
Fixes rust-lang/rust#85077
r? lcnr
cc ````@rust-lang/project-const-generics````
|
|
|
|
Fixes https://github.com/rust-lang/rust-analyzer/issues/20030
|
|
|
|
|
|
|
|
Right now it's used for functions with `fn_align`, in the future it will
get more uses (statics, struct fields, etc.)
|
|
Apply suggestions from code review
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
review comments
fix possible hang
|
|
Change __rust_no_alloc_shim_is_unstable to be a function
This fixes a long sequence of issues:
1. A customer reported that building for Arm64EC was broken: #138541
2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well.
3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data.
4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not).
5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning.
6. A customer then reported a similar warning when using `lld-link` (<https://github.com/rust-lang/rust/pull/140176#issuecomment-2872448443>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: #140954.
7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <https://github.com/rust-lang/rust/pull/140176#issuecomment-2881867433>. At that point, my original change was reverted (#141024) leaving Arm64EC broken yet again.
Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported.
Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not.
There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above.
There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics).
Build with this change applied BEFORE #140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205>
Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for #128602)
r? `@bjorn3`
cc `@jieyouxu`
|
|
|
|
We no longer error in this case!
|
|
Rewrite `inline` attribute parser to use new infrastructure and improve diagnostics for all parsed attributes
r? `@oli-obk`
This PR:
- creates a new parser for inline attributes
- creates consistent error messages and error codes between attribute parsers; inline and others
- as such changes a few error messages for other attributes to be (in my eyes) much more consistent
- tests ast-lowering lints introduced by rust-lang/rust#138164 since this is now useful for the first time
- Coalesce some useless error codes
Builds on top of rust-lang/rust#138164
Closes rust-lang/rust#137950
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 14 pull requests
Successful merges:
- rust-lang/rust#141574 (impl `Default` for `array::IntoIter`)
- rust-lang/rust#141608 (Add support for repetition to `proc_macro::quote`)
- rust-lang/rust#142100 (rustdoc: make srcIndex no longer a global variable)
- rust-lang/rust#142371 (avoid `&mut P<T>` in `visit_expr` etc methods)
- rust-lang/rust#142517 (Windows: Use anonymous pipes in Command)
- rust-lang/rust#142520 (alloc: less static mut + some cleanup)
- rust-lang/rust#142588 (Generic ctx imprv)
- rust-lang/rust#142605 (Don't unwrap in enzyme builds in case of missing llvm-config)
- rust-lang/rust#142608 (Refresh module-level docs for `rustc_target::spec`)
- rust-lang/rust#142618 (Lint about `console` calls in rustdoc JS)
- rust-lang/rust#142620 (Remove a panicking branch in `BorrowedCursor::advance`)
- rust-lang/rust#142631 (Dont suggest remove semi inside macro expansion for redundant semi lint)
- rust-lang/rust#142632 (Update cargo)
- rust-lang/rust#142635 (Temporarily add back -Zwasm-c-abi=spec)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Update cargo
6 commits in fc1518ef02b77327d70d4026b95ea719dd9b8c51..2251525ae503fa196f6d7f9ce6d32eccb2d5f044
2025-06-06 04:49:44 +0000 to 2025-06-16 22:01:27 +0000
- feat: Add custom completer for `cargo remove <TAB>` (rust-lang/cargo#15662)
- chore(deps): update msrv (3 versions) to v1.85 (rust-lang/cargo#15668)
- refactor: replace InternedString with Cow in IndexPackage (rust-lang/cargo#15559)
- highlight the correct words (rust-lang/cargo#15659)
- CHANGELOG.md: typo (rust-lang/cargo#15660)
- Use `Not::not` rather than a custom `is_false` function (rust-lang/cargo#15645)
|
|
avoid `&mut P<T>` in `visit_expr` etc methods
trying a different way than rust-lang/rust#141636
r? ghost
|
|
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
This includes a fix for building on gnux32.
[1]: https://github.com/rust-lang/libc/releases/tag/0.2.174
|
|
|
|
|
|
Hide imported privates if private editable is disabled
|
|
Sized Hierarchy: Part I
This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.
These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.
RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:
- `?Sized` is rewritten as `MetaSized`
- `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.
There are no edition migrations implemented in this, as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled.
Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).
It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.
**Notes:**
- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
- Each commit has a short description describing its purpose.
- This patch is large but it's primarily in the test suite.
- I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)
- FCP in https://github.com/rust-lang/rust/pull/137944#issuecomment-2912207485
Fixes rust-lang/rust#79409.
r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
|
|
|
|
Improve completions in if / while expression conditions
|
|
|
|
|
|
|
|
We show fixes now even for experimental diagnostics anyway, and it has false positives.
|
|
fix: Reload workspaces when cargo configs change
|
|
|