| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Improve if/else pretty printing
AST/HIR pretty printing of if/else is currently pretty bad. This PR improves it a lot.
r? `@Nadrieril`
|
|
Fix never pattern printing
It's currently broken, but there's an easy fix.
r? `@Nadrieril`
|
|
Correctly display stdout and stderr in case a doctest is failing
Fixes https://github.com/rust-lang/rust/issues/140289.
Since the doctest is actually running itself, we need to handle the output directly inside it.
cc `@fmease`
r? `@notriddle`
|
|
check types of const param defaults
fixes #139643 by checking that the type of a const parameter default matches the type of the parameter as long as both types are fully concrete
r? `@BoxyUwU`
|
|
r=fee1-dead
Simply try to unpeel AsyncFnKindHelper goal in `emit_specialized_closure_kind_error`
Tweak the handling of `AsyncFnKindHelper` goals in `emit_specialized_closure_kind_error` to not be so special-casey, and just try to unpeel one or two layers of obligation causes to get to their underlying `AsyncFn*` goal.
Fixes https://github.com/rust-lang/rust/issues/140292
|
|
transmutability: Support char, NonZeroXxx
Note that `NonZero` support is not wired up, as the author encountered
bugs while attempting this. A future commit will wire up `NonZero`
support.
r? ````@jswrenn````
|
|
stall generator witness obligations: add regression test
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/180
r? ```@compiler-errors```
|
|
handle specialization in the new trait solver
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/187
also fixes the regression in `plonky2_field` from https://github.com/rust-lang/trait-system-refactor-initiative/issues/188
cc https://github.com/rust-lang/rust/pull/111994
r? ```@compiler-errors```
|
|
Track per-obligation recursion depth only if there is inference in the new solver
Track how many times an obligation has been processed in the fulfillment context by reusing its recursion depth, and only overflow if a singular (root) goal hits the limit.
This also fixes a (probably theoretical at this point) problem where we don't detect pseudo-hangs across `select_where_possible` calls.
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/186
r? lcnr
|
|
Improve error message for `||` (or) in let chains
**Description**
This PR improves the error message when using `||` in an if let chain expression, addressing #140263.
**Changes**
1. Creates a dedicated error message specifically for `||` usage in let chains
2. Points the primary span directly at the `||` operator
3. Removes confusing secondary notes about "let statements" and unsupported contexts
5. Adds UI tests verifying the new error message and valid cases
**Before**
```rust
error: expected expression, found let statement
--> src/main.rs:2:8
|
2 | if let true = true || false {}
| ^^^^^^^^^^^^^^^
|
= note: only supported directly in conditions of if and while expressions
note: || operators are not supported in let chain expressions
--> src/main.rs:2:24
|
2 | if let true = true || false {}
|
```
**After**
```rust
error: `||` operators are not supported in let chain conditions
--> src/main.rs:2:24
|
2 | if let true = true || false {}
| ^^
```
**Implementation details**
1. Added new `OrInLetChain` diagnostic in errors.rs
2. Modified `CondChecker` in expr.rs to prioritize the `||` error
3. Updated fluent message definitions to use clearer wording
**Related issue**
Fixes #140263
cc ```@ehuss``` (issue author)
|
|
emit_specialized_closure_kind_error
|
|
In the AST the "then" block is represented as a `Block`. In HIR the
"then" block is represented as an `Expr` that happens to always be.
`ExprKind::Block`. By deconstructing the `ExprKind::Block` to extract
the block within, things print properly.
For `issue-82392.rs`, note that we no longer print a type after the
"then" block. This is good, it now matches how we don't print a type for
the "else" block. (Well, we do print a type after the "else" block, but
it's for the whole if/else.)
Also tighten up some of the pattern matching -- these block expressions
within if/else will never have labels.
|
|
Note that `NonZero` support is not wired up, as the author encountered
bugs while attempting this. A future commit will wire up `NonZero`
support.
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #137683 (Add a tidy check for GCC submodule version)
- #138968 (Update the index of Result to make the summary more comprehensive)
- #139572 (docs(std): mention const blocks in const keyword doc page)
- #140152 (Unify the format of rustc cli flags)
- #140193 (fix ICE in `#[naked]` attribute validation)
- #140205 (Tidying up UI tests [2/N])
- #140284 (remove expect() in `unnecessary_transmutes`)
- #140290 (rustdoc: fix typo change from equivelent to equivalent)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
uwu :3
|
|
remove expect() in `unnecessary_transmutes`
removes expect() from #136083 and fixes #140277
includes regression test
r? lcnr
|
|
Tidying up UI tests [2/N]
Part of #133895
Moved the location of the tests that were in `tests/ui` and added descriptions!
I'll squash before merge!
r? jieyouxu
|
|
fix ICE in `#[naked]` attribute validation
fixes https://github.com/rust-lang/rust/issues/140082
The comment here https://github.com/rust-lang/rust/pull/139615/files#r2040684192 is relevant, a better way to print the full path would be nice. If there's an issue I should `FIXME` this with let me know.
r? `@jdonszelmann`
cc `@nnethercote` https://github.com/rust-lang/rust/pull/139615
|
|
Unify the format of rustc cli flags
As mentioned in #140102, I unified the format of rustc CLI flags.
I use the following rules:
1. `<param>`: Indicates a required parameter
2. `[param]`: Indicates an optional parameter
3. `|`: Indicates a mutually exclusive option
4. `*`: a list element with description
Current output:
```bash
Usage: rustc [OPTIONS] INPUT
Options:
-h, --help Display this message
--cfg <SPEC> Configure the compilation environment.
SPEC supports the syntax `<NAME>[="<VALUE>"]`.
--check-cfg <SPEC>
Provide list of expected cfgs for checking
-L [<KIND>=]<PATH> Add a directory to the library search path. The
optional KIND can be one of
<dependency|crate|native|framework|all> (default:
all).
-l [<KIND>[:<MODIFIERS>]=]<NAME>[:<RENAME>]
Link the generated crate(s) to the specified native
library NAME. The optional KIND can be one of
<static|framework|dylib> (default: dylib).
Optional comma separated MODIFIERS
<bundle|verbatim|whole-archive|as-needed>
may be specified each with a prefix of either '+' to
enable or '-' to disable.
--crate-type <bin|lib|rlib|dylib|cdylib|staticlib|proc-macro>
Comma separated list of types of crates
for the compiler to emit
--crate-name <NAME>
Specify the name of the crate being built
--edition <2015|2018|2021|2024|future>
Specify which edition of the compiler to use when
compiling code. The default is 2015 and the latest
stable edition is 2024.
--emit <TYPE>[=<FILE>]
Comma separated list of types of output for the
compiler to emit.
Each TYPE has the default FILE name:
* asm - CRATE_NAME.s
* llvm-bc - CRATE_NAME.bc
* dep-info - CRATE_NAME.d
* link - (platform and crate-type dependent)
* llvm-ir - CRATE_NAME.ll
* metadata - libCRATE_NAME.rmeta
* mir - CRATE_NAME.mir
* obj - CRATE_NAME.o
* thin-link-bitcode - CRATE_NAME.indexing.o
--print <INFO>[=<FILE>]
Compiler information to print on stdout (or to a file)
INFO may be one of
<all-target-specs-json|calling-conventions|cfg|check-cfg|code-models|crate-name|crate-root-lint-levels|deployment-target|file-names|host-tuple|link-args|native-static-libs|relocation-models|split-debuginfo|stack-protector-strategies|supported-crate-types|sysroot|target-cpus|target-features|target-libdir|target-list|target-spec-json|tls-models>.
-g Equivalent to -C debuginfo=2
-O Equivalent to -C opt-level=3
-o <FILENAME> Write output to FILENAME
--out-dir <DIR> Write output to compiler-chosen filename in DIR
--explain <OPT> Provide a detailed explanation of an error message
--test Build a test harness
--target <TARGET>
Target triple for which the code is compiled
-A, --allow <LINT> Set lint allowed
-W, --warn <LINT> Set lint warnings
--force-warn <LINT>
Set lint force-warn
-D, --deny <LINT> Set lint denied
-F, --forbid <LINT> Set lint forbidden
--cap-lints <LEVEL>
Set the most restrictive lint level. More restrictive
lints are capped at this level
-C, --codegen <OPT>[=<VALUE>]
Set a codegen option
-V, --version Print version info and exit
-v, --verbose Use verbose output
Additional help:
-C help Print codegen options
-W help Print 'lint' options and default settings
-Z help Print unstable compiler options
--help -v Print the full set of options rustc accepts
```
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #137653 (Deprecate the unstable `concat_idents!`)
- #138957 (Update the index of Option to make the summary more comprehensive)
- #140006 (ensure compiler existance of tools on the dist step)
- #140143 (Move `sys::pal::os::Env` into `sys::env`)
- #140202 (Make #![feature(let_chains)] bootstrap conditional in compiler/)
- #140236 (norm nested aliases before evaluating the parent goal)
- #140257 (Some drive-by housecleaning in `rustc_borrowck`)
- #140278 (Don't use item name to look up associated item from trait item)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #137096 (Stabilize flags for doctest cross compilation)
- #140148 (CI: use aws codebuild for job dist-arm-linux)
- #140187 ([AIX] Handle AIX dynamic library extensions within c-link-to-rust-dylib run-make test)
- #140196 (Improved diagnostics for non-primitive cast on non-primitive types (`Arc`, `Option`))
- #140210 (Work around cygwin issue on condvar timeout)
- #140213 (mention about `x.py setup` in `INSTALL.md`)
- #140229 (`DelimArgs` tweaks)
- #140248 (Fix impl block items indent)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't use item name to look up associated item from trait item
This fix should be self-justifying b/c the fact that we were using identifiers here was kinda sus anyways, esp b/c we have a failproof way of doing the comparison :) I'll leave some info about why this repro needs a macro.
Fixes https://github.com/rust-lang/rust/issues/140259
r? `@nnethercote`
|
|
norm nested aliases before evaluating the parent goal
see the explanation of the underlying issue in tests/ui/traits/next-solver/normalize/eager-norm-pre-normalizes-to.rs.
This is also the cause of https://github.com/rust-lang/trait-system-refactor-initiative/issues/184, fixing the overflow errors with the new solver. I did not add any tests based on it directly as relying on that behavior to cause recursion limit shenanigans feels fragile. Thanks `@Nadrieril` for minimizing the issue [on zulip](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/typenum.20.602.20.2F.201.60.20overflow.20error/with/513993621).
r? `@compiler-errors`
|
|
Deprecate the unstable `concat_idents!`
`concat_idents` has been around unstably for a long time, but there is now a better (but still unstable) way to join identifiers using `${concat(...)}` syntax with `macro_metavar_expr_concat`. This resolves a lot of the problems with `concat_idents` and is on a better track toward stabilization, so there is no need to keep both versions around. `concat_idents!` still has a lot of use in the ecosystem so deprecate it before removing, as discussed in [1].
Link: https://github.com/rust-lang/rust/issues/124225
[1]: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Removing.20.60concat_idents.60
|
|
By removing some of the over-indenting. AST pretty printing now looks
correct. HIR pretty printing is better, but still over-indents some.
|
|
Indents for `cbox` and `ibox` are 0 or `INDENT_UNIT` (4) except for a
couple of places which are `INDENT_UNIT - 1` for no clear reason.
This commit changes the three space indents to four spaces.
|
|
The AST pretty printing is a bit wonky. The HIR pretty printing is
extremely wonky.
|
|
|
|
set subsections_via_symbols for ld64 helper sections
closes https://github.com/rust-lang/rust/issues/139744
cc `@madsmtm`
|
|
r=notriddle
Fix impl block items indent
Fixes #139771.
Now, all impl block "before impl block items" indent are the same (ie, item info and documentation).
With this fix, it looks like this:
You can test it [here](https://rustdoc.crud.net/imperio/fix-impl-block-items-indent/foo/struct.Context.html).
r? `@notriddle`
|
|
Improved diagnostics for non-primitive cast on non-primitive types (`Arc`, `Option`)
here is a small fix that improving error messaging when user is trying to do something like this
```rust
let _ = "x" as Arc<str>;
let _ = 2 as Option<i32>;
```
before it looks like this
```rust
error[E0605]: non-primitive cast: `&'static str` as `Arc<str>`
--> src\main.rs:3:13
|
3 | let _ = "x" as Arc<str>;
| ^^^^^^^^^^^^^^^ help: consider using the `From` trait instead: `Arc<str>::from("x")`
error[E0605]: non-primitive cast: `i32` as `Option<i32>`
--> src\main.rs:4:13
|
4 | let _ = 2 as Option<i32>;
```
which looks horrible to be honest
so i made a small fix that make errors looks like this
```rust
error[E0605]: non-primitive cast: `&'static str` as `Arc<str>`
|
3 | let _ = "x" as Arc<str>;
| ^^^^^^^^^^^^^^^
|
= note: an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object
help: consider using the `From` trait instead
|
3 - let _ = "x" as Arc<str>;
3 + let _ = Arc::<str>::from("x");
|
error[E0605]: non-primitive cast: `i32` as `Option<i32>`
|
4 | let _ = 2 as Option<i32>;
| ^^^^^^^^^^^^^^^^
|
= note: an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object
help: consider using the `From` trait instead
|
4 - let _ = 2 as Option<i32>;
4 + let _ = Option::<i32>::from(2);
```
**What improves?**
1) `Arc<str>::from("x")` which makes no sense because of missing `::`
2) readability
**Related Issue**
fixes #135412
|
|
[AIX] Handle AIX dynamic library extensions within c-link-to-rust-dylib run-make test
Dynamic libraries on AIX have the ".a" extension. The c-link-to-rust-dylib run-make test checks for the extension explicitly, so the extension for AIX is also added to accommodate the test case on AIX.
|
|
Stabilize flags for doctest cross compilation
This makes the following changes in preparation for supporting doctest cross-compiling in cargo:
- Renames `--runtool` and `--runtool-arg` to `--test-runtool` and `--test-runtool-arg` to maintain consistency with other `--test-*` arguments.
- Stabilizes the `--test-runtool` and `--test-runtool-arg`. These are needed in order to support cargo's `target.runner` option which specifies a runner to execute a cross-compiled doctest (for example, qemu).
- Stabilizes the `--enable-per-target-ignores` flag by removing it and making it unconditionally enabled. This makes it possible to disable a doctest on a per-target basis, which I think will be helpful for rolling out this feature.
These changes were suggested in https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/stabilizing.20doctest.20xcompile/near/409281127
The intent is to stabilize the doctest-xcompile feature in cargo. This will help ensure that for projects that do cross-compile testing that their doctests are also covered. Currently there is a somewhat surprising behavior that they are ignored.
Closes https://github.com/rust-lang/rust/issues/64245
try-job: x86_64-msvc-1
|
|
`concat_idents` has been around unstably for a long time, but there is
now a better (but still unstable) way to join identifiers using
`${concat(...)}` syntax with `macro_metavar_expr_concat`. This resolves
a lot of the problems with `concat_idents` and is on a better track
toward stabilization, so there is no need to keep both versions around.
`concat_idents!` still has a lot of use in the ecosystem so deprecate it
before removing, as discussed in [1].
Link: https://github.com/rust-lang/rust/issues/124225
[1]: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Removing.20.60concat_idents.60
|
|
|
|
|
|
Autodiff flags
Interestingly, it seems that some other projects have conflicts with exactly the same LLVM optimization passes as autodiff.
At least `LLVMRustOptimize` has exactly the flags that we need to disable problematic opt passes.
This PR enables us to compile code where users differentiate two identical functions in the same module. This has been especially common in test cases, but it's not impossible to encounter in the wild.
It also enables two new flags for testing/debugging. I consider writing an MCP to upgrade PrintPasses to be a standalone -Z flag, since it is *not* the same as `-Z print-llvm-passes`, which IMHO gives less useful output. A discussion can be found here: [#t-compiler/llvm > Print llvm passes. @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fllvm/topic/Print.20llvm.20passes.2E/near/511533038)
Finally, it improves `PrintModBefore` and `PrintModAfter`. They used to work reliable, but now we just schedule enzyme as part of an existing ModulePassManager (MPM). Since Enzyme is last in the MPM scheduling, PrintModBefore became very inaccurate. It used to print the input module, which we gave to the Enzyme and was great to create llvm-ir reproducer. However, lately the MPM would run the whole `default<O3>` pipeline, which heavily modifies the llvm module, before we pass it to Enzyme. That made it impossible to use the flag to create llvm-ir reproducers for Enzyme bugs. We now schedule a PrintModule pass just before Enzyme, solving this problem.
Based on the PrintPass output, it also _seems_ like changing `registerEnzymeAndPassPipeline(PB, true);` to `registerEnzymeAndPassPipeline(PB, false);` has no effect. In theory, the bool should tell Enzyme to schedule some helpful passes in the PassBuilder. However, since it doesn't do anything and I'm not 100% sure anymore on whether we really need it, I'll just disable it for now and postpone investigations.
r? ``@oli-obk``
closes #139471
Tracking:
- https://github.com/rust-lang/rust/issues/124509
|
|
Add `#[repr(u128)]`/`#[repr(i128)]` enums to `improper_ctypes_definitions`
This makes them warn whenever a plain `u128`/`i128` would. If the lang team decides to merge #137306 then this can be reverted.
Tracking issue: #56071
|
|
Suggest {to,from}_ne_bytes for transmutations between arrays and integers, etc
implements #136067
Rust has helper methods for many kinds of safe transmutes, for example integer<->bytes. This is a lint against using transmute for these cases.
```rs
fn bytes_at_home(x: [u8; 4]) -> u32 {
transmute(x)
}
// other examples
transmute::<[u8; 2], u16>();
transmute::<[u8; 8], f64>();
transmute::<u32, [u8; 4]>();
transmute::<char, u32>();
transmute::<u32, char>();
```
It would be handy to suggest `u32::from_ne_bytes(x)`.
This is implemented for `[u8; _]` -> `{float int}`
This also implements the cases:
`fXX` <-> `uXX` = `{from_bits, to_bits}`
`uXX` -> `iXX` via `cast_unsigned` and `cast_signed`
{`char` -> `u32`, `bool` -> `n8`} via `from`
`u32` -> `char` via `from_u32_unchecked` (note: notes `from_u32().unwrap()`) (contested)
`u8` -> `bool` via `==` (debatable)
---
try-job: aarch64-gnu
try-job: test-various
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #139261 (mitigate MSVC alignment issue on x86-32)
- #140075 (Mention average in midpoint documentations)
- #140184 (Update doc of cygwin target)
- #140186 (Rename `compute_x` methods)
- #140194 (minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`)
- #140195 (triagebot: label minicore changes w/ `A-test-infra-minicore` and ping jieyouxu on changes)
- #140214 (Remove comment about handling non-global where bounds with corresponding projection)
- #140228 (Revert overzealous parse recovery for single colons in paths)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Revert overzealous parse recovery for single colons in paths
Basically manually reverts #136808, cc ``@chenyukang`` ``@estebank.``
Reopens #129273.
Fixes [after beta backport] #140227.
|
