When a macro expands to a call whose callee is a block (or other
"complete" expression like `match`, `if`, `loop`), the AST pretty
printer emits the callee without parentheses. In statement position
the closing brace ends the expression and the argument list is parsed
as a separate tuple expression, producing a parse error.
The AST pretty printer produces invalid Rust when a block expression is
the base of an index operation inside a macro expansion. This is a gap
in the existing `FixupContext` parenthesization machinery — the approach
handles statement position but not the case where a block-index is
nested inside another expression.
The following is a correct program:
```rust
macro_rules! block_arr {
() => {{ [0u8; 4] }};
}
macro_rules! as_slice {
() => {{ &block_arr!()[..] }};
}
fn main() { let _: &[u8] = as_slice!(); }
```
But `rustc -Zunpretty=expanded` produces output that is not valid Rust,
because the closing brace of `{ [0u8; 4] }` creates a statement
boundary, causing the parser to treat `[..]` as a separate expression:
```rust
fn main() { let _: &[u8] = { &{ [0u8; 4] }[..] }; }
```
```
error: expected one of `.`, `;`, `?`, `}`, or an operator, found `[`
```
Fixed output after this change:
```rust
fn main() { let _: &[u8] = { &({ [0u8; 4] })[..] }; }
```
Since `{ ... }[...]` never parses as indexing a block regardless of
context, the fix unconditionally parenthesizes "complete" expressions
(block, match, if, loop, etc.) when they appear as the base of an index
operation.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#154460 (Deduplication: Pulled common logic out from lower_const_arg_struct)
- rust-lang/rust#154609 (Enable `#[diagnostic::on_const]` for local impls)
- rust-lang/rust#154678 (Introduce #[diagnostic::on_move] on `Rc`)
- rust-lang/rust#154902 (rustdoc: Inherit inline attributes for declarative macros)
rustdoc: Inherit inline attributes for declarative macros
When explicitly re-exporting a declarative macro by name, rustdoc previously bypassed intermediate re-exports and dropped `#[doc(inline)]` attributes, causing the macro to be incorrectly stripped if the original definition was `#[doc(hidden)]`.
This updates `generate_item_with_correct_attrs` to walk the `reexport_chain` specifically for declarative macros, allowing them to inherit inline attributes exactly as glob imports do, while preserving strict visibility rules for standard items.
Fixesrust-lang/rust#154694
Deduplication: Pulled common logic out from lower_const_arg_struct
This PR aims to deduplicate the logic in the function `lower_const_arg_struct` by creating a helper function `lower_path_for_struct_expr` which is shared between `rustc_hir_ty_lowering `and `rustc_hir_typeck`.
Related: https://github.com/rust-lang/rust/issues/150621
Helper function code:
```
pub struct ResolvedStructPath<'tcx> {
pub res: Result<Res, ErrorGuaranteed>,
pub ty: Ty<'tcx>,
}
pub fn lower_path_for_struct_expr(
&self,
qpath: hir::QPath<'tcx>,
path_span: Span,
hir_id: HirId,
) -> ResolvedStructPath<'tcx> {
match qpath {
hir::QPath::Resolved(ref maybe_qself, path) => {
let self_ty = maybe_qself.as_ref().map(|qself| self.lower_ty(qself));
let ty = self.lower_resolved_ty_path(self_ty, path, hir_id, PermitVariants::Yes);
ResolvedStructPath { res: Ok(path.res), ty }
}
hir::QPath::TypeRelative(hir_self_ty, segment) => {
let self_ty = self.lower_ty(hir_self_ty);
let result = self.lower_type_relative_ty_path(
self_ty,
hir_self_ty,
segment,
hir_id,
path_span,
PermitVariants::Yes,
);
let ty = result
.map(|(ty, _, _)| ty)
.unwrap_or_else(|guar| Ty::new_error(self.tcx(), guar));
ResolvedStructPath {
res: result.map(|(_, kind, def_id)| Res::Def(kind, def_id)),
ty,
}
}
}
}
```
Thanks to @BoxyUwU for the guidance on this issue.
Explicitly forget the zero remaining elements in `vec::IntoIter::fold()`.
[Original description:] ~~This seems to help LLVM notice that dropping the elements in the destructor of `IntoIter` is not necessary. In cases it doesn’t help, it should be cheap since it is just one assignment.~~
This PR adds a function to `vec::IntoIter()` which is used used by `fold()` and `spec_extend()`, when those operations complete, to forget the zero remaining elements and only deallocate the allocation, ensuring that there will never be a useless loop to drop zero remaining elements when the iterator is dropped.
This is my first ever attempt at this kind of codegen micro-optimization in the standard library, so please let me know what should go into the PR or what sort of additional systematic testing might indicate this is a good or bad idea.
Store `chunk_domain_size` explicitly in `Chunk`.
Currently we compute it on demand, but it's a little simpler and slightly faster to store it.
r? @ghost
library: no `cfg(target_arch)` on scalable intrinsics
These intrinsics don't technically need to be limited to a specific architecture, they'll probably only make sense to use on AArch64, but this just makes it harder to use them in stdarch where it is appropriate (such as on `arm64ec`): requiring a rustc patch to land and be on nightly before stdarch work can proceed. So let's just not `cfg` them at all, they're perma-unstable anyway.
Fixes CI failure in rust-lang/stdarch#2071
c-b: Export inverse hyperbolic trigonometric functions
Since a1feab1638 ("Use libm for acosh and asinh"), the standard library may link these functions to get a more accurate approximation; however, some targets do not have the needed symbols available. Add them to the compiler-builtins export list to make sure the fallback is usable.
Closes: https://github.com/rust-lang/rust/issues/154919
library: std: motor: use OS' process::exit in abort_internal
abort_internal() is used in panics; if it calls core::intrinsics::abort(), the process triggers an invalid op code (on x86_64), which is a much harder "abort" than a user-controlled exit via a panic.
Most other OSes don't use core::intrinsics::abort() here, but either libc::abort(), or a native OS abort/exit API.
Post-attribute ports cleanup pt. 1
r? @jdonszelmann
This cleans up some checks I could find were for non-parsed attributes, and works towards removing BUILTIN_ATTRIBUTES
All commits do one thing and every commit passes tests, so best reviewed commit by commit
Add more info about where autodiff can be applied
It's taken quite a few years, but we finally have a PR open to distribute Enzyme: https://github.com/rust-lang/rust/pull/154754
I therefore went over the docs once more and noticed we don't explain a lot of the most basic features, which we added over the years and have since taken for granted.
@Sa4dUs, do you think there are more interesting cases that we are missing?
Generally, there's still a lot of complexity in it, especially for people who haven't used Enzyme before.
To some extent, that's just a result of my general design goal to expose all performance-relevant features of Enzyme, and let users explore nice abstractions on top if it, via crates. Since we don't have those nightly users yet, users haven't had time to build nicer abstractions on top of it.
I also feel like a more guided book would be a better first introduction to Enzyme, but for now I just focused on the list of features.
r? @oli-obk
coretests: add argument order regression tests for min_by/max_by/minmax_by
PR rust-lang/rust#136307 introduced a regression in min_by, max_by, and minmax_by:
the compare closure received arguments as (v2, v1) instead of (v1, v2),
contrary to the documented contract.
Although this was fixed in rust-lang/rust#139357, no regression tests were added.
This PR adds regression tests for all three functions, verifying that compare
always receives arguments in the documented order (v1, v2).
As a bonus: first coretests coverage for minmax_by.
Migrate some tests from `tests/ui/issues` to appropriate directories
The following changes have been made in the pull request:
- `tests/ui/issues/issue-25746-bool-transmute.rs` ➝ `tests/ui/transmute/transmute-bool-u8.rs`
- `tests/ui/issues/issue-32377.{rs,stderr}` ➝ `tests/ui/intrinsics/transmute-phantomdata-generic-unequal-size.{rs,stderr}`
The issue links have also been added at the top of each `.rs` file.
r? Kivooeo
GCI: During reachability analysis don't try to evaluate the initializer of overly generic free const items
We generally don't want the initializer of free const items to get evaluated if they have any non-lifetime generic parameters. However, while I did account for that in HIR analysis & mono item collection (rust-lang/rust#136168 & rust-lang/rust#136429), I didn't account for reachability analysis so far which means that on main we still evaluate such items if they are *public* for example.
The closed PR rust-lang/rust#142293 from a year ago did address that as a byproduct but of course it wasn't merged since its primary goal was misguided. This PR extracts & improves upon the relevant parts of that PR which are necessary to fix said issue.
Follow up to rust-lang/rust#136168 & rust-lang/rust#136429.
Partially supersedes rust-lang/rust#142293.
Part of rust-lang/rust#113521.
r? @BoxyUwU
delegation: generate more verbose error delegation
After this PR we generate more verbose error delegation including path lowering, as there can be other code in generic args as in rust-lang/rust#154820. Now we access information for delegation lowering through ty-level queries and they require that the code should be lowered, even if it is in unresolved delegation.
Fixesrust-lang/rust#154820, part of rust-lang/rust#118212.
r? @petrochenkov
Fix pin docs
Split a long sentence to improve readability.
The original sentence required multiple readings for me to understand as a non-native speaker. The revised version is clearer and more readable, and likely easier for others as well.
Update Fira Mono License Information
Update license information for Fira Mono font.
The license itself seems to be identical as `FiraSans` license, but didn't reuse it's file as it was explicitly named `FiraSans-LICENSE`.
Added a new LICENSE from https://github.com/mozilla/Fira/blob/master/LICENSE and updated `build` and `static` files setup.
`./x doc library` worked fine locally and was able to see the mono license being minified and served as well.
Split out the creation of `Cycle` to a new `process_cycle` function
This splits out the creation of `CycleError` to a new `process_cycle` function. This makes it a bit clearer which operations are done for diagnostic purposes vs. what's needed to break cycles.
Anything that can change there can also be changed in bootstrap.toml.
We have a separate check to make sure that the local config is
compatable with CI's config.
Example output:
```
$ x b compiler
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.02s
NOTE: detected 3 modifications that could affect a build of rustc
- src/bootstrap/src/core/config/config.rs
- src/bootstrap/src/core/download.rs
- src/build_helper/src/git.rs
skipping rustc download due to `download-rustc = 'if-unchanged'`
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.72s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Build completed successfully in 0:00:05
```
`ty::Alias` refactor
This PR changes the following alias-related types from this:
```rust
pub enum AliasTyKind {
Projection,
Inherent,
Opaque,
Free,
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub def_id: I::DefId,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTyKind, AliasTy<I>),
}
```
Into this:
```rust
pub enum AliasTyKind<I: Interner> {
Projection { def_id: I::DefId },
Inherent { def_id: I::DefId },
Opaque { def_id: I::DefId },
Free { def_id: I::DefId },
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub kind: AliasTyKind<I>,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTy<I>),
}
```
... and then does a thousand other changes to accommodate for this change everywhere.
This brings us closer to being able to have `AliasTyKind`s which don't require a `DefId` (and thus can be more easily created, etc). Although notably we depend on both `AliasTyKind -> DefId` and `DefId -> AliasTyKind` conversions in a bunch of places still.
r? lcnr
----
A lot of these changes were done either by search & replace (via `ast-grep`) or on auto pilot, so I'm not quite sure I didn't mess up somewhere, but at least tests pass...
These intrinsics don't technically need to be limited to a specific
architecture, they'll probably only make sense to use on AArch64,
but this just makes it harder to use them in stdarch where it is
appropriate (such as on `arm64ec`), requiring a rustc patch to land and
be on nightly before stdarch work can proceed - so just don't `cfg` them
at all.
Add `#[track_caller]` to some functions which can panic b/c of the
caller's wrong index (this helped me debug some mistakes I did while
refactoring `ty::Alias`)
Andrew V. Teylu