| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Make replacement suggestion `_` in type verbose
```
error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types
--> $DIR/in-signature.rs:6:21
|
LL | fn arr_fn() -> [u8; _] {
| ^ not allowed in type signatures
|
help: replace with the correct return type
|
LL - fn arr_fn() -> [u8; _] {
LL + fn arr_fn() -> [u8; 3] {
|
```
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#145883 (Make macOS dist build configuration match where reasonable)
- rust-lang/rust#146457 (Skip cleanups on unsupported targets)
- rust-lang/rust#147152 (builtin `Fn`-trait impls: instantiate binder before the return type `Sized` check)
- rust-lang/rust#147153 ([rustdoc] Move doc cfg propagation pass before items stripping passes)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
GuillaumeGomez:doc-propagation-before-stripping-items, r=lolbinarycat
[rustdoc] Move doc cfg propagation pass before items stripping passes
Follow-up of https://github.com/rust-lang/rust/pull/138907.
r? lolbinarycat
|
|
builtin `Fn`-trait impls: instantiate binder before the return type `Sized` check
fixes
- https://github.com/rust-lang/trait-system-refactor-initiative/issues/220
- https://github.com/rust-lang/trait-system-refactor-initiative/issues/204
r? `@BoxyUwU`
|
|
Skip cleanups on unsupported targets
This commit is an update to the `AbortUnwindingCalls` MIR pass in the compiler. Specifically a new boolean is added for "can this target possibly unwind" and if that's `false` then terminators are all adjusted to be unreachable/not present. The end result is that this fixes rust-lang/rust#140293 for wasm targets.
The motivation for this PR is that currently on WebAssembly targets the usage of the `C-unwind` ABI can lead LLVM to either (a) emit exception-handling instructions or (b) hit a LLVM-ICE-style codegen error. WebAssembly as a base instruction set does not support unwinding at all, and a later proposal to WebAssembly, the exception-handling proposal, was what enabled this. This means that the current intent of WebAssembly targets is that they maintain the baseline of "don't emit exception-handling instructions unless enabled". The commit here is intended to restore this behavior by skipping these instructions even when `C-unwind` is present.
Exception-handling is a relatively tricky and also murky topic in WebAssembly, however. There are two sets of instructions LLVM can emit for WebAssembly exceptions, Rust's Emscripten target supports exceptions, WASI targets do not, the LLVM flags to enable this are not always obvious, and additionally this all touches on "changing exception-handling behavior should be a target-level concern, not a feature". Effectively WebAssembly's exception-handling integration into Rust is not finalized at this time. The best idea at this time is that a parallel set of targets will eventually be added which support exceptions, but it's not clear if/when to do this. In the meantime the goal is to keep existing targets working while still enabling experimentation with exception-handling with `-Zbuild-std` and various permutations of LLVM flags.
To that extent this commit does not blanket disable these landing pads and cleanup routines for WebAssembly but instead checks to see if panic=unwind is enabled or if `+exception-handling` is enabled. Tests are updated here as well to account for this where, by default, using a `C-unwind` ABI won't affect Rust codegen at all. If `+exception-handling` is enabled, however, then Rust codegen will look like native platforms where exceptions are caught and the program aborts. More-or-less I've done my best to keep exceptions working on wasm where it's possible to have them work, but turned them off where they're not supposed to be emitted.
Closes rust-lang/rust#140293
|
|
Make macOS dist build configuration match where reasonable
r? `@madsmtm`
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146937 (std: implement `hostname`)
- rust-lang/rust#147040 (mbe: macro_check: Fix function comments referencing non-existent parameters)
- rust-lang/rust#147131 (Use MirPatch in simplify_branches.)
- rust-lang/rust#147133 (Remove one loop in `extract_cfg_from_attrs`)
- rust-lang/rust#147150 (Emit allocator attributes for allocator shim)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Emit allocator attributes for allocator shim
This emits the same attributes we place on allocator declarations on the definitions in the allocator shim as well. This complements https://github.com/rust-lang/rust/pull/146766, which added the attribute for `#[global_allocator]` definitions. Emitting the attributes on the definitions ensures that they cannot be lost of the allocator shim participates in LTO.
See https://github.com/rust-lang/rust/issues/145995 for context, though that one was about `#[global_allocator]`. I'm not sure whether this can occur with the allocator shim as well or not, but better safe than sorry.
I'm not sure whether there is any good way to test this, as the allocator shim is not part of `--emit=llvm-ir`. I've verified this locally by inspecting the bitcode produced by `-C save-temps`.
r? ``@bjorn3``
|
|
r=lolbinarycat
Remove one loop in `extract_cfg_from_attrs`
Follow-up of https://github.com/rust-lang/rust/pull/138907.
r? lolbinarycat
|
|
Use MirPatch in simplify_branches.
This allows to avoid clearing the CFG cache if we don't perform any change.
r? ``@ghost`` for perf
|
|
mbe: macro_check: Fix function comments referencing non-existent parameters
Several functions had comments referencing a non-existent `valid`
parameter. Remove those. The `guar` parameter that handles errors is
already documented.
In the process, remove another duplicate reference to an
already-documented parameter (`binders`).
|
|
std: implement `hostname`
Resolves https://github.com/rust-lang/libs-team/issues/330
Tracking issue: https://github.com/rust-lang/rust/issues/135142
This is based on rust-lang/rust#135141, but I've reimplemented the UNIX version, which now:
* uses `sysconf(_SC_HOST_NAME_MAX)` as an initial buffer length
* returns `OutOfMemory` if the `Vec` allocation fails
* retries the operation if it detects that the name returned by `gethostname` was truncated
Additionally, as part of the rebase, I had to move some WinSock abstractions (initialisation and error access) to `sys::pal` so that they can be accessed from `sys::net::hostname`.
CC ``@orowith2os`` (and thank you for your work!)
|
|
|
|
|
|
debuginfo: add an unstable flag to write split DWARF to an explicit directory
Bazel requires knowledge of outputs from actions at analysis time, including file or directory name. In order to work around the lack of predictable output name for dwo files, we group the dwo files in a subdirectory of --out-dir as a post-processing step before returning control to bazel. Unfortunately some debugging workflows rely on directly opening the dwo file rather than loading the merged dwp file, and our trick of moving the files breaks those users. We can't just hardlink the file or copy it, because with remote build execution we wouldn't end up with the un-moved file copied back to the developer's workstation. As a fix, we add this unstable flag that causes dwo files to be written to a build-system-controllable location, which then lets bazel hoover up the dwo files, but the objects also have the correct path for the dwo files.
r? `@davidtwco`
|
|
|
|
|
|
to avoid overflow from proving `for<'a> opaque<'a>: Sized`
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146653 (improve diagnostics for empty attributes)
- rust-lang/rust#146987 (impl Ord for params and use unstable sort)
- rust-lang/rust#147101 (Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library )
- rust-lang/rust#147123 (Fix removed version numbers of `doc_auto_cfg` and `doc_cfg_hide`)
- rust-lang/rust#147149 (add joboet to library review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
add joboet to library review rotation
Reviewing feels like fun again...
|
|
Fix removed version numbers of `doc_auto_cfg` and `doc_cfg_hide`
Tracking issue: https://github.com/rust-lang/rust/issues/43781
The `doc_auto_cfg` and `doc_cfg_hide` features were removed in a recent nightly (by https://github.com/rust-lang/rust/pull/138907).
I believe that the rustc version numbers at which the features were declared to be removed were incorrect, however, and should both be "1.92" (±1). As evidence in favour of this, the error we get from using this was:
```text
error[E0557]: feature has been removed
--> src/lib.rs:22:29
|
22 | #![cfg_attr(docsrs, feature(doc_auto_cfg))]
| ^^^^^^^^^^^^ feature has been removed
|
= note: removed in 1.58.0; see <https://github.com/rust-lang/rust/pull/138907> for more information
= note: merged into `doc_cfg`
```
Note especially the "removed in 1.58" claim. Further evidence is found in the comment further up this file: https://github.com/rust-lang/rust/blob/4ffeda10e10d4fa0c8edbd0dd9642d8ae7d3e66e/compiler/rustc_feature/src/removed.rs#L49-L53
I've chosen 1.92 as that was the milestone which https://github.com/rust-lang/rust/pull/138907 was added to.
cc `@GuillaumeGomez`
|
|
Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library
Now that rust-lang/rust#137122 has landed, we can replace stuff that looks like:
```rust
let a: &[T];
let b: &[T];
let eq = a.len() == b.len() && a.iter().zip(b).all(|(a,b)| a == b)
```
with the much simpler `a.iter().eq(b)`, without losing the perf benefit of the different-length-fast-path.
Also dogfooded `Iterator::eq_by` (cc rust-lang/rust#64295 ) while I'm at it.
First commit (4d1b6fad230f8a5ccceccc7562eadc4ea50059da) should be very straightforward to review, second one (049a4606cb3906787aedf508ee8eea09c2bb3b9a) is slightly more creative, but IMHO a nice cleanup.
|
|
impl Ord for params and use unstable sort
AFAICT we are only sorting to find duplicates, so unstable sort should work fine, and maybe is a tiny bit faster?
|
|
improve diagnostics for empty attributes
Adds a note about them not having any effect. This was previously done for `feature` attributes but no other attributes. In [converting the `feature` parser](https://github.com/rust-lang/rust/pull/146652) I removed that note. This PR adds it back in and makes it so all attributes benefit from it.
Not blocked on rust-lang/rust#146652, either can merge first
|
|
This emits the same attributes we place on allocator declarations
(and allocator definitions using `#[global_allocator]`) on the
definitions in the allocator shim as well, making sure that the
attributes are not lost if the allocator shim participates in LTO.
|
|
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#147100 (tests: Remove ignore-android directive for fixed issue)
- rust-lang/rust#147116 (compiler: remove AbiAlign inside TargetDataLayout)
- rust-lang/rust#147134 (remove explicit deref of AbiAlign for most methods)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
r=Zalathar
remove explicit deref of AbiAlign for most methods
Much of the compiler calls functions on Align projected from AbiAlign. AbiAlign impls Deref to its inner Align, so we can simplify these away. Also, it will minimize disruption when AbiAlign is removed.
For now, preserve usages that might resolve to PartialOrd or PartialEq, as those have odd inference.
|
|
compiler: remove AbiAlign inside TargetDataLayout
AbiAlign is a thin wrapper around Align, extant mostly because we used to track a separate quasi-notion of alignment that was never a real notion of alignment and removing all of it at once was too churny. This PR maintains AbiAlign usage in public API and most of the compiler, but direct access of these fields for TargetDataLayout is now in terms of Align only.
|
|
tests: Remove ignore-android directive for fixed issue
rust-lang/rust#120567 is marked as fixed, so let's see if we can remove the ignore directives tied to that issue.
<!-- Note to self: wait for https://github.com/rust-lang/team/pull/2002 -->
try-job: arm-android
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#133477 (Detect tuple structs that are unconstructable due to re-export)
- rust-lang/rust#146929 (compiletest: Remove old-output-capture and become a stage0 bootstrap tool)
- rust-lang/rust#146979 (constify Default on Nanoseconds)
- rust-lang/rust#147092 (Do not compute optimized MIR if code does not type-check.)
- rust-lang/rust#147112 (all 48 keywords in just 300 characters)
- rust-lang/rust#147122 (Fix some crash-test directives)
- rust-lang/rust#147127 (Add a leading dash to linker plugin arguments in the gcc codegen)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
```
error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types
--> $DIR/in-signature.rs:6:21
|
LL | fn arr_fn() -> [u8; _] {
| ^ not allowed in type signatures
|
help: replace with the correct return type
|
LL - fn arr_fn() -> [u8; _] {
LL + fn arr_fn() -> [u8; 3] {
|
```
|
|
Add a leading dash to linker plugin arguments in the gcc codegen
Fix rust-lang/rust#130583
r? ``@bjorn3``
|
|
Fix some crash-test directives
- 120175 fails to crash for non-ELF targets; presumably this wasn't noticed because the CI jobs don't enable rustc assertions for non-ELF hosts.
- 34127, 125722, and 131292 have `only-x86_64`, which is overly specific.
- Unnecessary x86 directives cause friction for contributors using aarch64, especially now that many PR CI jobs also use aarch64.
r? ghost
|
|
all 48 keywords in just 300 characters
new test case in, all 48 keywords in just 300 characters
https://doc.rust-lang.org/reference/keywords.html
|
|
Do not compute optimized MIR if code does not type-check.
Since https://github.com/rust-lang/rust/pull/128612, we compute optimized MIR when `-Zvalidate-mir` is present.
This is done as part of required analyses, even if type-checking fails. This causes ICEs, as most of the mir-opt pipeline expects well-formed code.
Fixes rust-lang/rust#129095
Fixes rust-lang/rust#134174
Fixes rust-lang/rust#134654
Fixes rust-lang/rust#135570
Fixes rust-lang/rust#136381
Fixes rust-lang/rust#137468
Fixes rust-lang/rust#144491
Fixes rust-lang/rust#147011
This does not fix issue rust-lang/rust#137190, as it ICEs without `-Zvalidate-mir`.
r? ``@compiler-errors``
|
|
constify Default on Nanoseconds
|
|
compiletest: Remove old-output-capture and become a stage0 bootstrap tool
The new compiletest output-capture system became the default in rust-lang/rust#146574, and no problems have been reported since.
This PR therefore removes the old output-capture implementation from compiletest, and adjusts bootstrap to always build and test compiletest as a stage0 bootstrap tool.
In other words, compiletest no longer relies on any unstable features (such as `libtest` or `internal_output_capture`), and is now written entirely in stable Rust!
The compiletest self-tests still need access to an in-tree rustc, in order to obtain information via `rustc --print`, so we interpret `--stage` as indicating the stage of that secondary compiler, but always use the stage0 compiler to build compiletest itself.
r? Kobzol
|
|
Detect tuple structs that are unconstructable due to re-export
When a tuple-struct is re-exported that has inaccessible fields at the `use` scope, the type's constructor cannot be accessed through that re-export. We now account for this case and extend the resulting resolution error. We also check if the constructor would be accessible directly, not through the re-export, and if so, we suggest using the full path instead.
```
error[E0423]: cannot initialize a tuple struct which contains private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:12:33
|
LL | let crate::Foo(x) = crate::Foo(42);
| ^^^^^^^^^^
|
note: the type is accessed through this re-export, but the type's constructor is not visible in this import's scope due to private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:3:9
|
LL | pub use my_mod::Foo;
| ^^^^^^^^^^^
help: the type can be constructed directly, because its fields are available from the current scope
|
LL | let crate::Foo(x) = crate::my_mod::Foo(42);
| ~~~~~~~~~~~~~~~~~~
```
Fix #133343.
|
|
Skip stack overflow handler for panic=immediate-abort
std installs guard pages and a signal handler to ensure that stackoverflows 1) terminate abruptly and 2) print an nice message. Even for panic=immediate-abort, 1) is desirable, we don't want silent data corruption there. But 2) is completely unnecessary, as users deliberately *don't* want nice messages, they want minimum binary size.
Therefore, skip the entire guard signal handler setup, which saves a lot of bytes.
I tested this with a hello world binary using fat LTO, build-std, panic=immediate-abort, opt-level=s, strip=debuginfo.
`size` reports significant savings:
```
text data bss dec hex filename
15252 1032 104 16388 4004 tiny-before
6881 964 48 7893 1ed5 tiny-after2
```
`nm -U` goes from 71 to 56, getting rid of a bunch of stack overflow related symbols. The disk size goes from `31k` to `24k`.
The impact on the error message is minimal, as the message was already
missing.
before:
```
fish: Job 1, './tiny-so-before' terminated by signal SIGABRT (Abort)
```
after:
```
fish: Job 1, './tiny-so-after' terminated by signal SIGSEGV (Address boundary error)
```
I didn't test the Windows part, but it likely also has savings.
|
|
|
|
Much of the compiler calls functions on Align projected from AbiAlign.
AbiAlign impls Deref to its inner Align, so we can simplify these away.
Also, it will minimize disruption when AbiAlign is removed.
For now, preserve usages that might resolve to PartialOrd or PartialEq,
as those have odd inference.
|
|
Re-enable assertions on macOS alt builds
These were previously disabled, in part for performance reasons, in part due to needing availability symbols `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` that `compiler-builtins` did not provide, see https://github.com/rust-lang/rust/pull/62592#issuecomment-510670657 and https://github.com/rust-lang/rust/pull/134275#issuecomment-2543067830 for failed checks.
Since https://github.com/rust-lang/rust/pull/138944 though, `std` now provides these symbols, so we should be able to re-enable LLVM assertions, debug assertions and overflow checks.
Fixes https://github.com/rust-lang/rust/issues/59637.
try-job: `*apple*`
|
|
When a tuple-struct is re-exported that has inaccessible fields at the `use` scope, the type's constructor cannot be accessed through that re-export. We now account for this case and extend the resulting resolution error. We also check if the constructor would be accessible directly, not through the re-export, and if so, we suggest using the full path instead.
```
error[E0423]: cannot initialize a tuple struct which contains private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:12:33
|
LL | let crate::Foo(x) = crate::Foo(42);
| ^^^^^^^^^^
|
note: the type is accessed through this re-export, but the type's constructor is not visible in this import's scope due to private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:3:9
|
LL | pub use my_mod::Foo;
| ^^^^^^^^^^^
help: the type can be constructed directly, because its fields are available from the current scope
|
LL | let crate::Foo(x) = crate::my_mod::Foo(42);
| ~~~~~~~~~~~~~~~~~~
```
Fix #133343.
|
