| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=jieyouxu
forward the bootstrap `runner` to `run-make`
The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions.
The configuration can look like this
```toml
# in bootstrap.toml
[target.s390x-unknown-linux-gnu]
runner = "qemu-s390x -L /usr/s390x-linux-gnu"
```
Any C compilation automatically sets the correct target. Calls to rustc must use `.target(target())`. Then, a command like below will work by cross-compiling to the given target, and using the given runner for that target to execute the binary:
```
./x test tests/run-make/c-link-to-rust-va-list-fn --target s390x-unknown-linux-gnu
```
The runner can also be used for e.g. running with `valgrind`.
This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure?
r? `@jieyouxu`
try-job: test-various
try-job: armhf-gnu
|
|
The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions.
|
|
Only traverse reachable blocks in JumpThreading.
Fixes https://github.com/rust-lang/rust/issues/131451
We only compute loop headers for reachable blocks. We shouldn't try to perform an opt on unreachable blocks anyway.
|
|
Improve diagnostics for `concat_bytes!` with C string literals
Use the same error as other invalid types for `concat_bytes!`, rather
than using `ConcatCStrLit` from `concat!`. Also add more information
with a note about why this doesn't work, and a suggestion to use a
null-terminated byte string instead.
|
|
add doc(alias("AsciiChar")) to core::ascii::Char
Added it to the reexported, which is intended rustdoc behavior, but is apparently untested, so I also added a test for it.
|
|
r=Manishearth,Urgau
Add diagnostic items for Clippy
Clippy still uses some paths to access items from the standard library. Adding the missing diagnostic items allows removing the last remaining paths.
Closes rust-lang/rust-clippy#5393
|
|
error on calls to ABIs that cannot be called
We recently added `extern "custom"`, which cannot be called using a rust call expression. But there are more ABIs that can't be called in that way, because the call does not semantically make sense.
More details are in https://github.com/rust-lang/rust/issues/140566#issuecomment-2846205457
r? `@workingjubilee`
try-job: x86_64-gnu-llvm-19-3
|
|
rustdoc_json: improve handling of generic args
This PR fixes some inconsistencies and inefficiencies in how generic args are handled by rustdoc-json-types.
r? `@aDotInTheVoid`
|
|
They show up in three places: once as `Option<Box<GenericArgs>>`, once
as `Box<GenericArgs>`, and once as `GenericArgs`. The first option is
best. It is more compact because generic args are often missing. This
commit changes the latter two to the former.
Example output, before and after, for the `AssocItemConstraint` change:
```
{"name":"Offset","args":{"angle_bracketed":{"args":[],"constraints":[]}},"binding":{...}}
{"name":"Offset","args":null,"binding":{...}}
```
Example output, before and after, for the `Type::QualifiedPath` change:
```
{"qualified_path":{"name":"Offset","args":{"angle_bracketed":{"args":[],"constraints":[]}}, ...}}
{"qualified_path":{"name":"Offset","args":null, ...}}
```
This reduces JSON output size, but not by much (e.g. 0.5%), because
`AssocItemConstraint` and `Type::QualifiedPath` are uncommon.
|
|
A path without generic args, like `Reader`, currently has JSON produced
like this:
```
{"path":"Reader","id":286,"args":{"angle_bracketed":{"args":[],"constraints":[]}}}
```
Even though `types::Path::args` is `Option` and allows for "no args",
instead it gets represented as "empty args". (More like `Reader<>` than
`Reader`.)
This is due to a problem in `clean::Path::from_clean`. It only produces
`None` if the path is an empty string. This commit changes it to also
produce `None` if there are no generic args. The example above becomes:
```
{"path":"Reader","id":286,"args":null}
```
I looked at a few examples and saw this reduce the size of the JSON
output by 3-9%.
The commit also adds an assertion that non-final segments don't have any
generics; something the old code was implicitly relying on.
Note: the original sin here is that `clean::PathSegment::args` is not an
`Option`, unlike `{ast,hir}::PathSegment::args`. I want to fix that, but
it can be done separately.
|
|
|
|
Reason about borrowed classes in CopyProp.
Fixes https://github.com/rust-lang/rust/issues/141122
The current implementation of `CopyProp` avoids unifying two borrowed locals, as this would change the result of address comparison.
However, the implementation was inconsistent with the general algorithm, which identifies equivalence classes of locals and then replaces all locals by a single representative of their equivalence class.
This PR fixes it by forbidding the unification of two *classes* if any of those contain a borrowed local.
|
|
Marks ADT live if it appears in pattern
Marks ADT live if it appears in pattern, it implies the construction of the ADT.
1. Then we can detect unused private ADTs impl `Default`, without special logics for `Default` and other std traits.
2. We can also remove `rustc_trivial_field_reads` on `Default`, and the logic in `should_ignore_item` (introduced by rust-lang/rust#126302).
Fixes rust-lang/rust#120770
Extracted from rust-lang/rust#128637.
r? `@petrochenkov`
|
|
Insert parentheses around binary operation with attribute
Fixes the bug found by `@fmease` in https://github.com/rust-lang/rust/pull/134661#pullrequestreview-2538983253.
Previously, `-Zunpretty=expanded` would expand this program as follows:
```rust
#![feature(stmt_expr_attributes)]
#![allow(unused_attributes)]
macro_rules! group {
($e:expr) => {
$e
};
}
macro_rules! extra {
($e:expr) => {
#[allow()] $e
};
}
fn main() {
let _ = #[allow()] 1 + 1;
let _ = group!(#[allow()] 1) + 1;
let _ = 1 + group!(#[allow()] 1);
let _ = extra!({ 0 }) + 1;
let _ = extra!({ 0 } + 1);
}
```
```console
let _ = #[allow()] 1 + 1;
let _ = #[allow()] 1 + 1;
let _ = 1 + #[allow()] 1;
let _ = #[allow()] { 0 } + 1;
let _ = #[allow()] { 0 } + 1;
```
The first 4 statements are the correct expansion, but the last one is not. The attribute is supposed to apply to the entire binary operation, not only to the left operand.
After this PR, the 5th statement will expand to:
```console
let _ = #[allow()] ({ 0 } + 1);
```
In the future, as some subset of `stmt_expr_attributes` approaches stabilization, it is possible that we will need to do parenthesization for a number of additional cases depending on the outcome of https://github.com/rust-lang/rust/issues/127436. But for now, at least this PR makes the pretty-printer align with the current behavior of the parser.
r? fmease
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#142331 (Add `trim_prefix` and `trim_suffix` methods for both `slice` and `str` types.)
- rust-lang/rust#142491 (Rework #[cold] attribute parser)
- rust-lang/rust#142494 (Fix missing docs in `rustc_attr_parsing`)
- rust-lang/rust#142495 (Better template for `#[repr]` attributes)
- rust-lang/rust#142497 (Fix random failure when JS code is executed when the whole file was not read yet)
- rust-lang/rust#142575 (Ensure copy* intrinsics also perform the static self-init checks)
- rust-lang/rust#142650 (Refactor Translator)
- rust-lang/rust#142713 (mbe: Refactor transcription)
- rust-lang/rust#142755 (rustdoc: Remove `FormatRenderer::cache`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
This test currently fails (as expected).
--- stderr -------------------------------
Pretty-printer lost necessary parentheses
BEFORE: #[attr] (1 + 1)
AFTER: #[attr] 1 + 1
Pretty-printer lost necessary parentheses
BEFORE: #[attr] (1 as T)
AFTER: #[attr] 1 as T
Pretty-printer lost necessary parentheses
BEFORE: #[attr] (x = 1)
AFTER: #[attr] x = 1
Pretty-printer lost necessary parentheses
BEFORE: #[attr] (x += 1)
AFTER: #[attr] x += 1
------------------------------------------
|
|
Some symbol and PathRoot cleanups
I'm looking into unifying how we join and print paths. Here are some preliminary cleanups.
r? ``@petrochenkov``
|
|
correct template for `#[align]` attribute
Tracking issue: https://github.com/rust-lang/rust/issues/82232
related: https://github.com/rust-lang/rust/pull/142507
I didn't fully understand what `template!` did, clearly. An empty `#[align]` attribute was still rejected later, but without this change it does get suggested in certain cases.
I've also updated some outdated references to `#[repr(align)]` on functions.
r? ``@jdonszelmann``
|
|
Ensure copy* intrinsics also perform the static self-init checks
fixes rust-lang/rust#142532
r? `@RalfJung`
|
|
Better template for `#[repr]` attributes
|
|
Alternative candidates for a trait implementation are not printed when
the trait has a diagnostic name, to avoid printing alternatives for
common stdlib traits such as `Copy` or `Debug`. However, this affects
all traits for which a diagnostic item is added.
Here, the list of alternatives candidates for `Step` does not seem
useful, and `Step` is unstable, so this will not be missed.
|
|
|
|
Added it to the reexported, which is intended
rustdoc behavior, but is apparently untested,
so I also added a test for it.
|
|
|
|
|
|
|
|
r=nnethercote,WaffleLapkin
Extract some shared code from codegen backend target feature handling
There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`.
The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. ``@GuillaumeGomez`` ``@antoyo`` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features` does not? The second commit also cleans up a bunch of unneeded complexity added in https://github.com/rust-lang/rust/pull/135927.
The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes:
- Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixes rust-lang/rust#134792.
- The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that...
- Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway.
The fourth commit increases consistency of the GCC backend with the LLVM backend.
The last commit does some further cleanup:
- Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes https://github.com/rust-lang/rust/issues/142412.
- Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this).
- Move fixed_x18 handling together with retpoline handling.
- Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag.
``@bjorn3`` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :)
Cc ``@workingjubilee``
|
|
rewrite `optimize` attribute to use new attribute parsing infrastructure
r? ```@oli-obk```
I'm afraid we'll get quite a few of these PRs in the future. If we get a lot of trivial changes I'll start merging multiple into one PR. They should be easy to review :)
Waiting on #138165 first
|
|
|
|
`{{root}}` is supposed to be an internal-only name but it shows up in
the output.
(I'm working towards a more general fix -- a universal "joiner" function
that can be used all over the place -- but I'm not there yet, so let's
fix this one in-place for now.)
|
|
Allow storing `format_args!()` in variable
Fixes https://github.com/rust-lang/rust/issues/92698
Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076
Tracking issue for format_args: https://github.com/rust-lang/rust/issues/99012
This change allows:
```rust
let name = "world";
let f = format_args!("hello {name}!"); // New: Store format_args!() for later!
println!("{f}");
```
This will need an FCP.
This implementation makes use of `super let`, which is unstable and might not exist in the future in its current form. However, it is entirely reasonable to assume future Rust will always have _a_ way of expressing temporary lifetimes like this, since the (stable) `pin!()` macro needs this too. (This was also the motivation for merging https://github.com/rust-lang/rust/pull/139114.)
(This is a second version of https://github.com/rust-lang/rust/pull/139135)
|
|
|
|
Use the same error as other invalid types for `concat_bytes!`, rather
than using `ConcatCStrLit` from `concat!`. Also add more information
with a note about why this doesn't work, and a suggestion to use a
null-terminated byte string instead.
|
|
it should not suggest just `#[align]`
|
|
Enable automatic cross-compilation in run-make tests
Supersedes rust-lang/rust#138066.
Blocker for rust-lang/rust#141856.
Based on rust-lang/rust#138066 plus `rustdoc()` cross-compile changes.
### Summary
This PR automatically specifies `--target` to `rustc()` and `rustdoc()` to have `rustc`/`rustdoc` produce cross-compiled artifacts in run-make tests by default, unless:
- `//@ ignore-cross-compile` is used, or
- `bare_{rustc,rustdoc}` are used, or
- Explicit `.target()` is specified, which overrides the default cross-compile target.
Some tests are necessarily modified:
- Tests that have `.target(target())` have that incantation removed (since this is now automatically the default).
- Some tests have `//@ needs-target-std`, but are a necessary-but-insufficient condition, and are changed to `//@ ignore-cross-compile` instead as host-only tests.
- A few tests received `//@ ignore-musl` that fail against `x86_64-unknown-linux-musl` because of inability to find `-lunwind`. AFAICT, they don't *need* to test cross-compiled artifacts.
- Some tests are constrained to host-only for now, because the effort to make them pass on cross-compile does not seem worth the complexity, and it's not really *meaningfully* improving test coverage.
try-job: dist-various-1
|
|
|
|
Also ensure the suggestions are checked, since this will be updated.
|
|
This does change the logic a bit: previously, we didn't forward reverse
implications of negated features to the backend, instead relying on the backend
to handle the implication itself.
|
|
|
|
Add a missing colon at the end of the panic location details in location-detail-unwrap-multiline.rs
The `location-detail-unwrap-multiline` test was failing when trying to enable `aarch64-pc-windows-msvc` CI Runners: https://github.com/rust-lang/rust/pull/140136#issuecomment-2978175728
When debugging, the normalized stderr was:
```
thread 'main' panicked at $DIR/location-detail-unwrap-multiline.rs:11:10:
called `Option::unwrap()` on a `None` value
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```
Note the trailing colon at the end of the location details in the panic message. This was missing in the error pattern regex. No idea why it has been passing for all other targets and failed for `aarch64-pc-windows-msvc`, but with the trailing colon it is now passing for all.
|
|
azhogin:azhogin/async-drop-without-sync-drop-error, r=oli-obk
AsyncDrop trait without sync Drop generates an error
When type implements `AsyncDrop` trait, it must also implement sync `Drop` trait to be used in sync context and unwinds.
This PR adds error generation in such a case.
Fixes: rust-lang/rust#140696
|
|
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`
|
|
Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs
Fixes rust-lang/rust#108491
Fixes rust-lang/rust#125879
This was due to updating inhabited predicate stuff which I had to do to make constructing ADTs with IATs in fields not ICE
Fixes rust-lang/rust#136678 (but no test added, I don't rly care about weird IAT edge cases under GCE)
Fixes rust-lang/rust#138131
Avoids doing "fully correct" candidate selection for IATs during hir ty lowering when in item signatures as it almost always leads to a query cycle from trying to build a `ParamEnv`. I replaced it with a use `DeepRejectCtxt` which should be able to handle this kind of conservative "could these types unify" while in a context where we don't want to do type equality.
This is a relatively simple scheme and should be forwards compatible with doing something more complex/powerful.
I'm not really sure how this interacts with rust-lang/rust#126651, though I'm also not really sure its super important to support projecting IATs from IAT self types given we don't even support `T::Assoc::Other` for trait-associated types so didn't give much thought to how this might fit in with that.
r? `@compiler-errors`
cc `@fmease`
|
|
|
|
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``
|
|
|
|
r=lcnr,traviscross
Stabilize `feature(generic_arg_infer)`
Fixes rust-lang/rust#85077
r? lcnr
cc ````@rust-lang/project-const-generics````
|
