| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Test: Ambigious bindings in same namespace with the same res
Add a test based on the discussion [here](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/near/542316157) and related to https://github.com/rust-lang/rust/issues/145575#issuecomment-3228868375.
This is the most reduced form I could create that passes on nightly but fails with rust-lang/rust#145108 (see [#gsoc > Project: Parallel Macro Expansion @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/near/542335131)).
Also not sure about the test names.
r? `@petrochenkov`
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#146281 (Support `#[rustc_align_static]` inside `thread_local!`)
- rust-lang/rust#146535 (mbe: Implement `unsafe` attribute rules)
- rust-lang/rust#146585 (indexing: reword help)
- rust-lang/rust#147004 (Tweak handling of "struct like start" where a struct isn't supported)
- rust-lang/rust#147221 (Forbid `//@ compile-flags: -Cincremental=` in tests)
- rust-lang/rust#147225 (Don't enable shared memory by default with Wasm atomics)
- rust-lang/rust#147227 (implement `Box::take`)
- rust-lang/rust#147233 (Initialize llvm submodule if not already the case to run citool)
- rust-lang/rust#147236 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Update books
## rust-lang/book
1 commits in 33f1af40cc44dde7e3e892f7a508e6f427d2cbc6..1d7c3e6abec2d5a9bfac798b29b7855b95025426
2025-09-28 21:24:16 UTC to 2025-09-28 21:24:16 UTC
- Chunk of chapters from copyedit (rust-lang/book#4506)
## rust-lang/edition-guide
1 commits in aa6ce337c0adf7a63e33960d184270f2a45ab9ef..e2ed891f00361efc26616d82590b1c85d7a8920e
2025-10-01 17:11:54 UTC to 2025-10-01 17:11:54 UTC
- link to never type fallback lint as deny by default (rust-lang/edition-guide#377)
## rust-lang/nomicon
1 commits in f17a018b9989430967d1c58e9a12c51169abc744..23fc2682f8fcb887f77d0eaabba708809f834c11
2025-09-24 10:10:31 UTC to 2025-09-24 10:10:31 UTC
- a typo in ffi.md (rust-lang/nomicon#502)
## rust-lang/reference
13 commits in cc7247d8dfaef4c39000bb12c55c32ba5b5ba976..e11adf6016a362766eea5a3f9832e193994dd0c8
2025-09-29 00:55:42 UTC to 2025-09-23 23:33:32 UTC
- const functions: separate rule about users and rule about what is allowed in such functions (rust-lang/reference#2013)
- use "tuple enum variant" more consistently (rust-lang/reference#2015)
- Remove caveats related to `format_args!` expansion (rust-lang/reference#2017)
- RISC-V: Extension Updates (including document references) (rust-lang/reference#2002)
- Move inferred sentence to an example block (rust-lang/reference#2019)
- Add triagebot range-diff feature (rust-lang/reference#2011)
- use AND when searching for multiple terms (rust-lang/reference#2016)
- enumerations.md: fix pluralisation (rust-lang/reference#2014)
- const_eval.md: use sentence case for section title, for consistency (rust-lang/reference#2012)
- destructors.md: improve readability by adding pauses (rust-lang/reference#2007)
- RISC-V: Add vector state registers (rust-lang/reference#2005)
- destructors.md: point to core:: instead of std:: (rust-lang/reference#2006)
- Create Whitespace grammar productions (rust-lang/reference#1991)
|
|
Initialize llvm submodule if not already the case to run citool
While working on https://github.com/rust-lang/rust/pull/146414, I ran the following command (to run CI docker locally):
```
cargo run --manifest-path src/ci/citool/Cargo.toml run-local --type pr x86_64-gnu-gcc
```
However, since I didn't have `src/llvm` submodule initialized, it failed. Apparently it's a common issue for people using this tool so this PR removes this small inconvenience.
r? ``@Kobzol``
|
|
implement `Box::take`
Tracking issue: https://github.com/rust-lang/rust/issues/147212
I'm not entirely sure about the wording of the doc comment, if anyone has any suggestions that'd be great :)
|
|
Don't enable shared memory by default with Wasm atomics
This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it.
### Context
Currently the atomics target features is unstable and can't be used without re-building Std with it (`-Zbuild-std`).
Enabling the atomics target feature automatically enables shared memory.
Shared memory is required to actually allow multi-threading.
However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs.
So it is very undesirable to enable shared memory by default for the majority of users.
While it is possible to use atomics without shared memory, the question remains what use-case this scenario has.
The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (rust-lang/rust#136382).
So alternatively, we might consider *not* enabling atomics by default even when LLVM does. In which case everything would remain the same.
---
This will break current Web multi-threading users. To address this they can add the following `RUSTFLAGS`:
```
-Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base
```
We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only `threads` target feature.
Addresses rust-lang/rust#77839.
r? ``@alexcrichton``
|
|
Forbid `//@ compile-flags: -Cincremental=` in tests
Tests should not try to manually enable incremental compilation with `-Cincremental`, because that typically results in stray directories being created in the repository root.
Also, if the incremental directory is not cleared, there is a risk of interference between successive runs of the same test.
Instead, use the `//@ incremental` directive, which instructs compiletest to handle the details of passing `-Cincremental` with a fresh directory.
|
|
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a `match` expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like `match a { b:` would confuse the parser and think everything after `match` *must* be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
|
|
indexing: reword help
After looking at https://github.com/rust-lang/rust/issues/40850, I thought I'd try to improve wording around error E0608 a bit. Hopefully I've succeeded.
|
|
mbe: Implement `unsafe` attribute rules
This implements `unsafe attr` rules for declarative `macro_rules!` attributes, as specified in [RFC 3697](https://github.com/rust-lang/rfcs/pull/3697).
An invocation of an attribute that uses an `unsafe attr` rule requires the `unsafe(attr(...))` syntax.
An invocation of an attribute that uses an ordinary `attr` rule must *not* use the `unsafe(attr(...))` syntax.
`unsafe` is only supported on an `attr` rule, not any other kind of `macro_rules!` rule.
Tracking issue for `macro_rules!` attributes: https://github.com/rust-lang/rust/issues/143547
|
|
r=Mark-Simulacrum
Support `#[rustc_align_static]` inside `thread_local!`
Tracking issue: rust-lang/rust#146177
```rust
thread_local! {
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = const { 0 };
}
```
This increases the amount of recursion the macro performs (once per attribute in addition to the previous once per item), making it easier to hit the recursion limit. I’ve added workarounds to limit the impact in the case of long doc comments, but this still needs a crater run just in case.
r? libs
``@rustbot`` label A-attributes A-macros A-thread-locals F-static_align T-libs
|
|
Split Bound index into Canonical and Bound
See [#t-types/trait-system-refactor > perf `async-closures/post-mono-higher-ranked-hang.rs`](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/perf.20.60async-closures.2Fpost-mono-higher-ranked-hang.2Ers.60/with/541535613) for context
Things compile and tests pass, but not sure if this actually solves the perf issue (edit: it does). Opening up this to do a perf (and maybe crater) run.
r? lcnr
|
|
Turn ProjectionElem::Subtype into CastKind::Subtype
I noticed that drop elaboration can't, in general, handle `ProjectionElem::SubType`. It creates a disjoint move path that overlaps with other move paths. (`Subslice` does too, and I'm working on a different PR to make that special case less fragile.) If its skipped and treated as the same move path as its parent then `MovePath.place` has multiple possible projections. (It would probably make sense to remove all `Subtype` projections for the canonical place but it doesn't make sense to have this special case for a problem that doesn't actually occur in real MIR.)
The only reason this doesn't break is that `Subtype` is always the sole projection of the local its applied to. For the same reason, it works fine as a `CastKind` so I figured that makes more sense than documenting and validating this hidden invariant.
cc rust-lang/rust#112651, rust-lang/rust#133258
r? Icnr (bc you've been the main person dealing with `Subtype` it looks like)
|
|
Tests should not try to manually enable incremental compilation with
`-Cincremental`, because that typically results in stray directories being
created in the repository root.
Instead, use the `//@ incremental` directive, which instructs compiletest to
handle the details of passing `-Cincremental` with a fresh directory.
|
|
`LegacyAttr` here
`LegacyAttr` is only used for builtin attributes, and builtin attributes
have their safety checked by `check_attribute_safety`, so we don't need
to check `unsafety` here.
|
|
|
|
|
|
|
|
This simplifies subsequent initialization of enum variants.
|
|
`rust-analyzer` subtree update
Subtree update of `rust-analyzer` to https://github.com/rust-lang/rust-analyzer/commit/a6bc4a4bbe6a65b71cbf76a0cf528c47a8d9f97f.
Created using https://github.com/rust-lang/josh-sync.
r? `@ghost`
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#146593 (Allow specifying multiple bounds for same associated item, except in trait objects)
- rust-lang/rust#147177 ([DebugInfo] Fix MSVC tuple child creation)
- rust-lang/rust#147195 (iter repeat: add tests for new count and last behavior)
- rust-lang/rust#147202 (Swap order of `resolve_coroutine_interiors` and `handle_opaque_type_uses`)
- rust-lang/rust#147204 (Refactor ArrayWindows to use a slice)
- rust-lang/rust#147219 (Add proper error handling for closure in impl)
- rust-lang/rust#147226 (include `outer_inclusive_binder` of pattern types)
- rust-lang/rust#147230 (Fix typo in 'unfulfilled_lint_expectation' to plural)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Fix typo in 'unfulfilled_lint_expectation' to plural
|
|
include `outer_inclusive_binder` of pattern types
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/237
r? ```@lcnr```
|
|
Add proper error handling for closure in impl
Fixes https://github.com/rust-lang/rust/issues/147146
Fixes https://github.com/rust-lang/rust/issues/146620
Not sure if it can cause any regressions or anything, as for test also have no idea where to store this one
cc ```@theemathas```
r? compiler
|
|
Refactor ArrayWindows to use a slice
[Tracking issue](https://github.com/rust-lang/rust/issues/75027)
|
|
Swap order of `resolve_coroutine_interiors` and `handle_opaque_type_uses`
r? ```@BoxyUwU```
if the comment says x should be last, it helps if it's actually last hehe :P
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/239
|
|
iter repeat: add tests for new count and last behavior
Tests for https://github.com/rust-lang/rust/pull/146410
|
|
[DebugInfo] Fix MSVC tuple child creation
This is a fix for the debugger visualizer scripts
For whatever reason, using `CreateChildAtOffset` on the child element sometimes caused issues with pointers (and maybe some other types). The resulting child's memory would be a block 4 bytes too far forward. Creating the child off of the parent `valobj` and using the type definition to get the correct offset seems to fix that.
Before:
<img width="489" height="136" alt="image" src="https://github.com/user-attachments/assets/fb4cb95c-f199-49a6-8eba-6d3ff486b69a" />
After:
<img width="518" height="145" alt="image" src="https://github.com/user-attachments/assets/3f50dbc3-19ca-4fd8-87c5-b4be295f6e7c" />
This shouldn't affect any tests as we don't run debuginfo tests for MSVC afaik
|
|
Allow specifying multiple bounds for same associated item, except in trait objects
Supersedes https://github.com/rust-lang/rust/pull/143146, fixes https://github.com/rust-lang/rust/issues/143143.
This PR proposes to stop enforcing E0719 in all contexts other than trait object types.
E0719 forbids constraining the same associated item twice within the same angle-bracket delimited associated item bound list (the `…` inside `T: Trait<…>`). For example, the following are forbidden:
| Forbidden | Working alternative |
|--------------------------------------------|--------------------------------------------------------------------|
| `T: Trait<Gat<u32> = u32, Gat<u64> = u64>` | `T: Trait<Gat<u32> = u32> + Trait<Gat<u64> = u64>` |
| `T: Iterator<Item = u32, Item = i32>` | `T: Iterator<Item = u32> + Iterator<Item = i32>` (trivially false) |
| `T: Iterator<Item = u32, Item = u32>` | `T: Iterator<Item = u32>` |
| `T: Iterator<Item: Send, Item: Sync>` | `T: Iterator<Item: Send + Sync>` |
| `T: Trait<ASSOC = 3, ASSOC = 4>` | `T: Trait<ASSOC = 3> + Trait<ASSOC = 4>` (trivially false) |
| `T: Trait<ASSOC = 3, ASSOC = 3>` | `T: Trait<ASSOC = 3>` |
With this PR, all those previously forbidden examples would start working, as well as their APIT and RPIT equivalents.
Types like `dyn Iterator<Item = u32, Item = u32>` will continue to be rejected, however. See https://github.com/rust-lang/rust/pull/143146#issuecomment-3274421752 for the reason why.
```@rustbot``` label T-lang T-types needs-fcp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#146918 (add regression test)
- rust-lang/rust#146980 (simplify setup_constraining_predicates, and note it is potentially cubic)
- rust-lang/rust#147170 (compiletest: Pass around `DirectiveLine` instead of bare strings)
- rust-lang/rust#147180 (add tests)
- rust-lang/rust#147188 (Remove usage of `compiletest-use-stage0-libtest` from CI)
- rust-lang/rust#147189 (Replace `rustc_span::Span` with a stripped down version for librustdoc's highlighter)
- rust-lang/rust#147199 (remove outdated comment in (inner) `InferCtxt`)
- rust-lang/rust#147200 (Fix autodiff empty ret regression)
- rust-lang/rust#147209 (Remove `no-remap-src-base` from tests)
- rust-lang/rust#147213 (Fix broken STD build for ESP-IDF)
- rust-lang/rust#147217 (Don't create a top-level `true` directory when running UI tests)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
Don't create a top-level `true` directory when running UI tests
The funny thing about writing `-Cincremental=true` is that it *does* enable incremental compilation ... using an incremental compilation dir of `./true`.
And for UI tests, that ends up creating a `true` directory in the repository root, which is annoying.
Fortunately, compiletest has an existing `//@ incremental` directive that takes care of creating an empty incremental directory, and passing it to `-Cincremental`.
---
I have manually checked that reverting rust-lang/rust#146649 still causes the updated test to fail.
|
|
Fix broken STD build for ESP-IDF
PRs rust-lang/rust#147162 and rust-lang/rust#146937 did [broke](https://github.com/esp-rs/esp-idf-sys/actions/runs/18151791720/job/51663969786) the STD build for `target_os = "espidf"` because that target [does not have neither a `gethostname`, not a `libc::_SC_HOST_NAME_MAX` by default](https://github.com/espressif/esp-idf/issues/14849).
While there is a [3rd party component for this syscall](https://components.espressif.com/components/espressif/sock_utils/versions/0.2.2/readme) in the ESP-IDF component registry, I don't think we should use it, because it does not come with ESP-IDF by default.
Therefore, the one-liner fix just re-routes ESP-IDF into the `unsupported` branch.
|
|
Remove `no-remap-src-base` from tests
Previously in the `//`-compiletest-directive times, `no-remap-src-base` was implemented as a special `no-*` directive parsing. In the migration from `//` -> `//`@`,` the `// no-remap-src-base` directive was lost, most likely because it had no effect -- the default is not remapping `src-base`.
So remove occurrences of `no-remap-src-base`, as these are not valid directives.
r? `@Zalathar` (since we discussed this on discord, or compiler)
|
|
Fix autodiff empty ret regression
closes https://github.com/rust-lang/rust/issues/147144
The two gsoc summer projects caused a bit of churn, which was to be expected, especially since we don't run autodiff in CI yet.
This adds a void return testcase that we should have had anyway, and fixes the regression.
r? `@Zalathar` (Just guessing since I've seen you in a few LLVM PRs and Oli is probably still busy. Feel free to reroll!)
|
|
remove outdated comment in (inner) `InferCtxt`
This comment seems to have stopped being relevant around 3 years ago after https://github.com/rust-lang/rust/commit/9f95c605f83bcf4c158ea4b3fd5a7abb825a4178. A map? what map? :P
r? `@lcnr`
|
|
r=GuillaumeGomez
Replace `rustc_span::Span` with a stripped down version for librustdoc's highlighter
While profiling rustdoc's syntax highlighter, I noticed a lot of time being spent in the `Span` interner, due to the highlighter creating a lot of (new) spans.
Since the only data from the `Span` that we use is the `hi` and `lo` byte positions - I replaced the regular `Span` with a simple one with two fields, and in my benchmarks it seemed to make a big dent in the highlighter's perf, so thought I would see what the perf runner says.
|
|
Remove usage of `compiletest-use-stage0-libtest` from CI
It shouldn't be needed anymore after https://github.com/rust-lang/rust/pull/146929.
r? `@Zalathar`
|
