And adds tests to validate it still works.
There is an anticipated feature request to support a compiler flag that
only adds coverage for specific files (or perhaps mods). As I thought
about where that change would need to be supported, I realized that
checking the attribute in mapgen (for unused functions) was unnecessary.
The unused functions are only synthesized if they have MIR coverage, and
functions with the `no_coverage` attribute will not have been
instrumented with MIR coverage statements in the first place.
New tests confirm this.
Also, while adding tests, I updated resolved comments and FIXMEs in
other tests.
Fixes: #84884
This solution might be considered a compromise, but I think it is the
better choice.
The results in the `closure.rs` test correctly resolve all test cases
broken as described in #84884.
One test pattern (in both `closure_macro.rs` and
`closure_macro_async.rs`) was also affected, and removes coverage
statistics for the lines inside the closure, because the closure
includes a macro. (The coverage remains at the callsite of the macro, so
we lose some detail, but there isn't a perfect choice with macros.
Often macro implementations are split across the macro and the callsite,
and there doesn't appear to be a single "right choice" for which body
should be covered. For the current implementation, we can't do both.
The callsite is most likely to be the preferred site for coverage.
I applied this fix to all `MacroKinds`, not just `Bang`.
I'm trying to resolve an issue of lost coverage in a
`MacroKind::Attr`-based, function-scoped macro. Instead of only
searching for a body_span that is "not a function-like macro" (that is,
MacroKind::Bang), I'm expanding this to all `MacroKind`s. Maybe I should
expand this to `ExpnKind::Desugaring` and `ExpnKind::AstPass` (or
subsets, depending on their sub-kinds) as well, but I'm not sure that's
a good idea.
I'd like to add a test of the `Attr` macro on functions, but I need time
to figure out how to constract a good, simple example without external
crate dependencies. For the moment, all tests still work as expected (no
change), this new commit shouldn't have a negative affect, and more
importantly, I believe it will have a positive effect. I will try to
confirm this.
Deduplicate ParamCandidates with the same value except for bound vars
Fixes#84398
This is kind of a hack. I wonder if we can get other types of candidates that are the same except for bound vars. This won't be a problem with Chalk, since we don't really need to know that there are two different "candidates" if they both give the same final substitution.
r? `@nikomatsakis`
Since the beginning of time the `-Ctarget-feature` flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
`#[target_feature]` attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:
#[target_feature(enable = "pclmulqdq")]
unsafe fn foo() {
// ...
}
but on the command line you would write:
RUSTFLAGS="-Ctarget-feature=+pclmul" cargo build --release
This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like [WebAssembly
SIMD](https://github.com/rust-lang/rust/issues/74372) which may be more
prevalent.
This commit implements a mapping to translate requests via
`-Ctarget-feature` through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
`+pclmulqdq` will work on x86 targets where as previously it did not.
I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
`-Ctarget-feature`, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.
lazify backtrace formatting for delayed diagnostics
Formatting backtraces causes debug info to be parsed, which is superfluous work if the delayed bugs get cleared later.
Lazifying them results in these speedups for the UI testsuite:
| | debuginfo = 0 | debuginfo = 1 | debuginfo = 2 |
|-------|---------------|---------------|---------------|
| eager | 31.59s | 37.55s | 42.64s |
| lazy | 30.44s | 30.86s | 34.07s |
Fix#84467 linker_args with --target=sparcv9-sun-solaris
Trying to cross-compile for sparcv9-sun-solaris
getting a error message for -zignore
Introduced when -z -ignore was seperated here
22d0ab0
No formatting done
Reproduce
``` bash
rustup target add sparcv9-sun-solaris
cargo new --bin hello && cd hello && cargo run --target=sparcv9-sun-solaris
```
config.toml
[target.sparcv9-sun-solaris]
linker = "gcc"
This commit implements both the native linking modifiers infrastructure
as well as an initial attempt at the individual modifiers from the RFC.
It also introduces a feature flag for the general syntax along with
individual feature flags for each modifier.
This defers backtrace formatting to the point where we
actually want to flush delayed diagnostics. If they are discarded
before that point then we can avoid invoking the backtrace formatting
machinery which will parse debug info and symbol tables.
for debuginfo=2 this leads to a 20% walltime reduction of the UI testsuite
Do not ICE on invalid const param
When encountering a path that can't have generics, do not call
`generics_of`. This would happen when writing something like
`path::this_is_a_mod<const_val>`.
Fix#84831.
Remove `rustc_middle::mir::interpret::CheckInAllocMsg::NullPointerTest`
Removing it per https://github.com/rust-lang/rust/pull/84842#discussion_r625589674: it's a dead enum variant.
Note that `PointerArithmeticTest` also seems dead:
```
$ rg -F PointerArithmeticTest -C5
compiler/rustc_middle/src/mir/interpret/error.rs
169-
170-/// Details of why a pointer had to be in-bounds.
171-#[derive(Debug, Copy, Clone, TyEncodable, TyDecodable, HashStable)]
172-pub enum CheckInAllocMsg {
173- MemoryAccessTest,
174: PointerArithmeticTest,
175- InboundsTest,
176-}
177-
178-impl fmt::Display for CheckInAllocMsg {
179- /// When this is printed as an error the context looks like this
--
182- write!(
183- f,
184- "{}",
185- match *self {
186- CheckInAllocMsg::MemoryAccessTest => "memory access",
187: CheckInAllocMsg::PointerArithmeticTest => "pointer arithmetic",
188- CheckInAllocMsg::InboundsTest => "inbounds test",
189- }
190- )
191- }
192-}
```
Not sure if that is also desirable to be removed, however.
using allow_internal_unstable (as recommended)
Fixes: #84836
```shell
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/run-make-fulldeps/coverage/no_cov_crate.rs
error[E0554]: `#![feature]` may not be used on the dev release channel
--> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1
|
2 | #![feature(no_coverage)]
| ^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0554`.
```
Deduplicate native libs before they are passed to the linker
Stop spamming the linker with the same native library over and over again, if they directly follow from each other. This would help prevent [this situation](https://github.com/MSxDOS/ntapi/issues/2).
Issue #38460 has been open since 2016 so I think it's worth making an incomplete fix that at least addresses the most common symptom and without otherwise changing how Rust handles native libs. This PR is intended to be easy to revert (if necessary) when a more permanent fix is implemented.
Retain data in vectorized registers for longer
This seems to be a mild performance improvement on the keccak crate at least, though not sure it'll show up more broadly.
When encountering a path that can't have generics, do not call
`generics_of`. This would happen when writing something like
`path::this_is_a_mod<const_val>`.
Fix#84831.
Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021
This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition.
r? `@estebank`
- It's used exactly once, so it's trivial to replace
- It doesn't match the normal convention for containers: normally
`get()` returns and option and indexing panics. Instead `get()` panicked
and there's no indexing operation available.
This extracts a new `parse_cfg` function that's used between both.
- Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)]
#[doc(cfg(y))]`. Previously it would be completely ignored.
- Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)]
#[doc(cfg(x))]`. Previously, the cfg would be ignored.
- Pass the cfg predicate through to rustc_expand to be validated
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
Replace 'NULL' with 'null'
This replaces occurrences of "NULL" with "null" in docs, comments, and compiler error/lint messages. This is for the sake of consistency, as the lowercase "null" is already the dominant form in Rust. The all-caps NULL looks like the C macro (or SQL keyword), which seems out of place in a Rust context, given that NULL does not exist in the Rust language or standard library (instead having [`ptr::null()`](https://doc.rust-lang.org/stable/std/ptr/fn.null.html)).
Fix debuginfo for generators
First, all fields except the discriminant (including `outer_fields`) should be put into structures inside the variant part, which gives an equivalent layout but offers us much better integration with debuggers.
Second, artificial flags in generator variants should be removed.
- Literally, variants are not artificial. We have `yield` statements, upvars and inner variables in the source code.
- Functionally, we don't want debuggers to suppress the variants. It contains the state of the generator, which is useful when debugging. So they shouldn't be marked artificial.
- Debuggers may use artificial flags to find the active variant. In this case, marking variants artificial will make debuggers not work properly.
Fixes#62572.
Fixes#79009.
And refer https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Debuginfo.20for.20generators.
Remove dead code in `rustc_session::Options`
- Don't recompile the same functions for each debugging option
This reduces the amount of items in the crate by quite a lot.
- Remove unused `parse_opt_list` and `parse_pathbuf_push` functions
- Remove unused macro parameters
- Remove `allow(dead_code)`.
Fixes: #84018
With `-Z instrument-coverage`, coverage reporting of dead blocks
(for example, blocks dropped because a conditional branch is dropped,
based on const evaluation) is now supported.
If `instrument-coverage` is enabled, `simplify::remove_dead_blocks()`
finds all dropped coverage `Statement`s and adds their `code_region`s as
`Unreachable` coverage `Statement`s to the `START_BLOCK`, so they are
still included in the coverage map.
Check out the resulting changes in the test coverage reports in this PR.
This ensures that `ParamEnv::and` preserves the original `caller_bounds`
when we have a value containing fresh tys/consts. This ensures that when
we cache a `SelectionCandidate`, the cache key (a `ParamEnvAnd`)
contains all of the information that influenced the computation of our
result (e.g. we may end up choosing a `ParamCandidate`)
Move HIR parenting information out of hir_owner
Split out of #82681.
The parent of a HIR node and its content are currently bundled together, but are rarely used together.
This PR separates both information in two distinct queries for HIR owners.
This reduces incremental invalidation for HIR items that appear within a function body when this body (and the local ids) changes.
Be stricter about rejecting LLVM reserved registers in asm!
LLVM will silently produce incorrect code if these registers are used as operands.
cc `@rust-lang/wg-inline-asm`
Rollup of 8 pull requests
Successful merges:
- #84601 (rustdoc: Only store locations in Cache::extern_locations and calculate the other info on-demand)
- #84704 (platform-support.md: Update for consistency with Target Tier Policy)
- #84724 (Replace llvm::sys::fs::F_None with llvm::sys::fs::OF_None)
- #84740 (Reset the docs' copy path button after 1 second)
- #84749 (Sync `rustc_codegen_cranelift`)
- #84756 (Add a ToC to the Target Tier Policy documentation)
- #84765 (Update cargo)
- #84774 (Fix misspelling)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Sync `rustc_codegen_cranelift`
Retrying #84746
r? ``@bjorn3``
---
Edit(bjorn3): Since the last sync there have been some refactorings around the driver code in preparation for a planned new feature. In addition ``@mominul`` implemented `-Ctarget-cpu` support and ``@XAMPPRocky`` fixed compilation of cg_clif itself for Windows with the MSVC toolchain.
Vastly improves coverage spans for macros
Fixes: #84561
This resolves problems where macros like `trace!(...)` would show zero coverage if tracing was disabled, and `assert_eq!(...)` would show zero coverage if the assertion did not fail, because only one coverage span was generated, for the branch.
This PR started with an idea that I could just drop branching blocks with same span as expanded macro. (See the fixed issue for more details.)
That did help, but it didn't resolve everything.
I also needed to add a span specifically for the macro name (plus `!`) to ensure the macro gets coverage even if it's internal expansion adds conditional branching blocks that are retained, and would otherwise drop the outer span. Now that outer span is _only_ the `(argument, list)`, which can safely be dropped now), because the macro name has its own span.
While testing, I also noticed the spanview debug output can cause an ICE on a function with no body. The
workaround for this is included in this PR (separate commit).
r? `@tmandry`
cc? `@wesleywiser`
Moved -z ignore to add_as_needed
Trying to cross-compile for sparcv9-sun-solaris
getting an error message for -zignore
Introduced when -z -ignore was separated here
22d0ab0
No formatting done
Reproduce
``` bash
rustup target add sparcv9-sun-solaris
cargo new --bin hello && cd hello && cargo run --target=sparcv9-sun-solaris
```
config.toml
[target.sparcv9-sun-solaris]
linker = "gcc"
Move iter_results to dyn FnMut rather than a generic
This means that we're no longer generating the iteration/locking code for each invocation site of iter_results, rather just once per query (roughly), which seems much better: this is a 15% win in instruction counts when compiling the rustc_query_impl crate. The code where this is used also is pretty cold, I suspect; the old solution didn't fully monomorphize either.
- Literally, variants are not artificial. We have `yield` statements,
upvars and inner variables in the source code.
- Functionally, we don't want debuggers to suppress the variants. It
contains the state of the generator, which is useful when debugging.
So they shouldn't be marked artificial.
- Debuggers may use artificial flags to find the active variant. In
this case, marking variants artificial will make debuggers not work
properly.
Fixes#79009.
All fields except the discriminant (including `outer_fields`)
should be put into structures inside the variant part, which gives
an equivalent layout but offers us much better integration with
debuggers.
Implement RFC 1260 with feature_name `imported_main`.
This is the second extraction part of #84062 plus additional adjustments.
This (mostly) implements RFC 1260.
However there's still one test case failure in the extern crate case. Maybe `LocalDefId` doesn't work here? I'm not sure.
cc https://github.com/rust-lang/rust/issues/28937
r? `@petrochenkov`
This means that we're no longer generating the iteration/locking code for each
invocation site of iter_results, rather just once per query.
This is a 15% win in instruction counts when compiling the rustc_query_impl crate.
Revert PR 77885 everywhere
Change to probe-stack=call (instead of inline-or-call) everywhere again, for now.
We had already reverted the change on stable back in PR #83412.
Since then, we've had some movement on issue #83139, but not a 100% fix.
But also since then, we had bug reported, issue #84667, that looks like outright codegen breakage, rather than problems confined to debuginfo issues. So we are reverting PR #77885 on stable and beta. We'll reland PR #77885 (or some variant) switching back to an LLVM-dependent selection of out-of-line call vs inline-asm, after these other issues have been resolved.
We had already reverted the change on stable back in PR #83412.
Since then, we've had some movement on issue #83139, but not a 100% fix.
But also since then, we had bug reported, issue #84667, that looks like outright
codegen breakage, rather than problems confined to debuginfo issues.
So we are reverting PR #77885 on stable and beta. We'll reland PR #77885 (or some
variant) switching back to an LLVM-dependent selection of out-of-line call vs
inline-asm, after these other issues have been resolved.
use correct feature flag for impl-block-level trait bounds on const fn
I am not sure what that special hack was needed for, but it doesn't seem needed any more...
This removes the last use of the `const_fn` feature flag -- Cc https://github.com/rust-lang/rust/issues/84510
r? `@oli-obk`
Add TRACKED_NO_CRATE_HASH and use it for `--remap-path-prefix`
I verified locally that this fixes https://github.com/rust-lang/rust/issues/66955.
r? `@Aaron1011` (feel free to reassign)
Rollup of 11 pull requests
Successful merges:
- #84484 (Don't rebuild rustdoc and clippy after checking bootstrap)
- #84530 (`test tidy` should ignore alternative `build` dir patterns)
- #84531 (Ignore commented out lines when finding features)
- #84540 (Build sanitizers for x86_64-unknown-linux-musl)
- #84555 (Set `backtrace-on-ice` by default for compiler and codegen profiles)
- #84585 (Add `x.py check src/librustdoc` as an alias for `x.py check src/tools/rustdoc`)
- #84636 (rustdoc: change aliases attribute to data-aliases)
- #84646 (Add some regression tests related to #82494)
- #84661 (Remove extra word in `rustc_mir` docs)
- #84663 (Remove `DropGuard` in `sys::windows::process` and use `StaticMutex` instead)
- #84668 (Update books)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
don't enable parking_lot nightly features
Having the compiler itself depend on external libraries that use nightly features can lead to "fun" bootstrap situations. Within the rustc repo we use `cfg(bootstrap)` to resolve those, but that is not a reasonable option for external dependencies.
So I propose we stop enabling the "nightly" feature of `parking_lot` here. In my experiments, this then indeed leads to the feature not being enabled (i.e., nothing else enables it), and everything still builds. However, this means parking_lot's `RwLock` will no longer have hardware lock elision for readers -- I hope that is okay to lose in exchange for less bootstrap brain twisting. ;)
Cc `@Amanieu`
Adds feature-gated `#[no_coverage]` function attribute, to fix derived Eq `0` coverage issue #83601
Derived Eq no longer shows uncovered
The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.
Fixes: #83601
The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).
Adding a `no_coverage` feature gate with tracking issue #84605.
r? `@tmandry`
cc: `@wesleywiser`
Improve coverage spans for chained function calls
Fixes: #84180
For chained function calls separated by the `?` try operator, the
function call following the try operator produced a MIR `Call` span that
matched the span of the first call. The `?` try operator started a new
span, so the second call got no span.
It turns out the MIR `Call` terminator has a `func` `Operand`
for the `Constant` representing the function name, and the function
name's Span can be used to reset the starting position of the span.
r? `@tmandry`
cc: `@wesleywiser`
Revert "Rollup merge of #82296 - spastorino:pubrules, r=nikomatsakis"
This reverts commit e2561c58a4, reversing
changes made to 2982ba50fc.
As discussed in #83641 this feature is not complete and in particular doesn't work cross macros and given that this is not going to be included in edition 2021 nobody seems to be trying to fix the underlying problem. When can add this again I guess, whenever somebody has the time to make it work cross crates.
r? `@nikomatsakis`
Update grab bag
This PR slides a bunch of crate versions forward until suddenly a bunch of deps fall out of the tree!
In doing so this mostly picks up a version bump in the `redox_users` crate which makes most of the features default to optional.
crossbeam-utils 0.7 => 0.8.3 (where applicable)
https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-utils/CHANGELOG.md
directories 3.0.1 => 3.0.2
ignore 0.4.16 => 0.4.17
tempfile 3.0.5 => tempfile 3.2
Removes constant_time_eq from deps exceptions
Removes arrayref from deps exceptions
And also removes:
- blake2b_simd
- const_fn (the package, not the feature)
- constant_time_eq
- redox_users 0.3.4
- rust-argon2
The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.
Fixes: #83601
The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).
While testing, I also noticed two other issues:
* spanview debug file output ICEd on a function with no body. The
workaround for this is included in this PR.
* `assert_*!()` macro coverage can appear covered if followed by another
`assert_*!()` macro. Normally they appear uncovered. I submitted a new
Issue #84561, and added a coverage test to demonstrate this issue.
This is necessary for options that should invalidate the incremental
hash but *not* affect the crate hash (e.g. --remap-path-prefix).
This doesn't add `for_crate_hash` to the trait directly because it's not
relevant for *types*, only for *options*, which are fields on a larger
struct. Instead, it adds a new `SUBSTRUCT` directive for options, which
does take a `for_crate_hash` parameter.
- Use TRACKED_NO_CRATE_HASH for --remap-path-prefix
- Add test that `remap_path_prefix` is tracked
- Reduce duplication in the test suite to avoid future churn
Fix coverage ICE because fn_sig can have a span that crosses file bou…
Fixes: #83792
MIR `InstrumentCoverage` assumed the `FnSig` span was contained within a
single file, but this is not always the case. Some macro constructions
can result in a span that starts in one `SourceFile` and ends in a
different one.
The `FnSig` span is included in coverage results as long as that span is
in the same `SourceFile` and the same macro context, but by assuming the
`FnSig` span's `hi()` and `lo()` were in the same file, I took this for
granted, and checked only that the `FnSig` `hi()` was in the same
`SourceFile` as the `body_span`.
I actually drop the `hi()` though, and extend the `FnSig` span to the
`body_span.lo()`, so I really should have simply checked that the
`FnSig` span's `lo()` was in the `SourceFile` of the `body_span`.
r? `@tmandry`
cc: `@wesleywiser`
Fix typo in report_unsed_assign
The function was called `report_unsed_assign`, which I assume is a typo, considering the rest of the file.
This replaces `report_unsed_assign` with `report_unused_assign`.
Always reject `const fn` in `trait` during parsing.
'const fn' in trait are rejected in the AST:
b78c0d8a4d/compiler/rustc_ast_passes/src/ast_validation.rs (L1411)
So this feature gate check is a NOP and we can just remove it.
The src/test/ui/feature-gates/feature-gate-min_const_fn.rs and src/test/ui/feature-gates/feature-gate-const_fn.rs tests ensure that we still reject `const fn` in `trait`
Cc https://github.com/rust-lang/rust/issues/84510
r? `@oli-obk`
Get rid of is_min_const_fn
This removes the last trace of the min_const_fn mechanism by making the unsafety checker agnostic about whether something is a min or "non-min" const fn. It seems this distinction was used to disallow some features inside `const fn`, but that is the responsibility of the const checker, not of the unsafety checker. No test seems to even notice this change in the unsafety checker so I guess we are good...
r? `@oli-obk`
Cc https://github.com/rust-lang/rust/issues/84510
Improve diagnostics for function passed when a type was expected.
This PR improves diagnostics, it provides more information when a function is passed where a type is expected.
r? `@lcnr`
Handle pretty printing of `else if let` clauses without ICEing
When pretty printing the HIR of `if ... {} else if let ... {}` clauses, this displays it the `else if let` part as `match` it gets desugared to, the same way normal `if let` statements are currently displayed, instead of ICEing.
```rust
pub fn main() {
if true {
// 1
} else if let a = 1 {
// 2
} else {
// 3
}
}
```
now gets desugared (via `rustc -Zunpretty=hir,typed src/x.rs`) to:
```rust
#[prelude_import]
use ::std::prelude::rust_2015::*;
#[macro_use]
extern crate std;
pub fn main() ({
(if (true as bool)
({
// 1
} as
()) else {match (1 as i32) {
a => {
// 2
}
_ => {
// 3
}
}} as ())
} as ())
```
For comparison, this code gets HIR prettyprinted the same way before and after this change:
```rust
pub fn main() {
if let a = 1 {
// 2
} else {
// 3
}
}
```
turns into
```rust
#[prelude_import]
use ::std::prelude::rust_2015::*;
#[macro_use]
extern crate std;
pub fn main() ({
(match (1 as i32) {
a => {
// 2
}
_ => {
// 3
}
} as ())
} as ())
```
This closes#82329. It closes#84434 as well, due to having the same root cause.
Give a better error when `std` or `core` are missing
- Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this, but it seems harmless enough and it will be a big help.
- On nightly, suggest using `cargo build -Z build-std` if `CARGO` is set
- Add a note about `#![no_std]` if `std` is missing but not core
- Add a note that std may be unsupported if `std` is missing but not core
Fixes https://github.com/rust-lang/rust/issues/84418.
r? `@petrochenkov`
- Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this, but it seems harmless enough and it will be a big help.
- Add a note about `#![no_std]` if `std` is missing but not core
- On nightly, suggest using `cargo build -Z build-std` if `CARGO` is set
- Add a note that std may be unsupported if `std` is missing but not core
- Don't suggest `#![no_std]` when the load isn't injected by the
compiler
various const parameter defaults improvements
Actually resolve names in const parameter defaults, fixing `struct Foo<const N: usize = { usize::MAX }>`.
---
Split generic parameter ban rib for types and consts, allowing
```rust
#![feature(const_generics_defaults)]
struct Q;
struct Foo<T = Q, const Q: usize = 3>(T);
```
---
Remove the type/const ordering restriction if `const_generics_defaults` is active, even if `const_generics` is not. allowing us to stabilize and test const param defaults separately.
---
Check well formedness of const parameter defaults, eagerly emitting an error for `struct Foo<const N: usize = { 0 - 1 }>`
---
Do not forbid const parameters in param defaults, allowing `struct Foo<const N: usize, T = [u8; N]>(T)` and `struct Foo<const N: usize, const M: usize = N>`. Note that this should not change anything which is stabilized, as on stable, type parameters must be in front of const parameters, which means that type parameter defaults are only allowed if no const parameters exist.
We still forbid generic parameters inside of const param types.
r? `@varkor` `@petrochenkov`
move core::hint::black_box under its own feature gate
The `black_box` function had its own RFC and is tracked separately from the `test` feature at https://github.com/rust-lang/rust/issues/64102. Let's reflect this in the feature gate.
To avoid breaking all the benchmarks, libtest's `test::black_box` is a wrapping definition, not a reexport -- this means it is still under the `test` feature gate.
Cautiously add IntoIterator for arrays by value
Add the attribute described in #84133, `#[rustc_skip_array_during_method_dispatch]`, which effectively hides a trait from method dispatch when the receiver type is an array.
Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally, but `array.into_iter()` has edition-dependent behavior, returning `slice::Iter` for 2015 and 2018 editions, or `array::IntoIter` for 2021 and later.
r? `@nikomatsakis`
cc `@LukasKalbertodt` `@rust-lang/libs`
Fixes: #84180
For chained function calls separated by the `?` try operator, the
function call following the try operator produced a MIR `Call` span that
matched the span of the first call. The `?` try operator started a new
span, so the second call got no span.
It turns out the MIR `Call` terminator has a `func` `Operand`
for the `Constant` representing the function name, and the function
name's Span can be used to reset the starting position of the span.
Static initializer can read other statics. Initializers are evaluated at
compile time, and so their content could become inlined into another
crate. Ensure that initializers of reachable statics are also reachable.
Previously, when an item incorrectly considered to be unreachable was
reached from another crate an attempt would be made to codegen it. The
attempt could fail with an ICE (in the case MIR wasn't available to do
so) in some circumstances the attempt could also succeed resulting in
a local codegen of non-local items, including static ones.
further split up const_fn feature flag
This continues the work on splitting up `const_fn` into separate feature flags:
* `const_fn_trait_bound` for `const fn` with trait bounds
* `const_fn_unsize` for unsizing coercions in `const fn` (looks like only `dyn` unsizing is still guarded here)
I don't know if there are even any things left that `const_fn` guards... at least libcore and liballoc do not need it any more.
`@oli-obk` are you currently able to do reviews?
Fixes: #83792
MIR `InstrumentCoverage` assumed the `FnSig` span was contained within a
single file, but this is not always the case. Some macro constructions
can result in a span that starts in one `SourceFile` and ends in a
different one.
The `FnSig` span is included in coverage results as long as that span is
in the same `SourceFile` and the same macro context, but by assuming the
`FnSig` span's `hi()` and `lo()` were in the same file, I took this for
granted, and checked only that the `FnSig` `hi()` was in the same
`SourceFile` as the `body_span`.
I actually drop the `hi()` though, and extend the `FnSig` span to the
`body_span.lo()`, so I really should have simply checked that the
`FnSig` span's `lo()` was in the `SourceFile` of the `body_span`.
Implement a lint that highlights all moves larger than a configured limit
Tracking issue: #83518
[MCP 420](https://github.com/rust-lang/compiler-team/issues/420) still ~blazing~ in progress
r? ```@pnkfelix```
The main open issue I see with this minimal impl of the feature is that the lint is immediately "stable" (so it can be named on stable), even if it is never executed on stable. I don't think we have the concept of unstable lint names or hiding lint names without an active feature gate, so that would be a bigger change.
Rollup of 10 pull requests
Successful merges:
- #83990 (implement `TrustedRandomAccess` for `Take` iterator adapter)
- #84250 (bootstrap: use bash on illumos to run install scripts)
- #84320 (Use details tag for trait implementors.)
- #84436 (Make a few functions private)
- #84453 (Document From implementations for Waker and RawWaker)
- #84458 (Remove unnecessary fields and parameters in rustdoc)
- #84485 (Add some associated type bounds tests)
- #84489 (Mention FusedIterator case in Iterator::fuse doc)
- #84492 (rustdoc: Remove unnecessary dummy span)
- #84496 (Add some specialization tests)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Make a few functions private
These were made public in 3105bcfdc1. This
is so long ago I doubt anyone remembers why they're public. No one outside rustc_session uses
them, including in-tree tools.
On stable, suggest removing `#![feature]` for features that have been stabilized
I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the
appropriate help with `channel = "beta"`:
```
error[E0554]: `#![feature]` may not be used on the beta release channel
--> src/lib.rs:2:1
|
2 | #![feature(min_const_generics)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute
|
= help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable
error[E0554]: `#![feature]` may not be used on the beta release channel
--> src/lib.rs:3:1
|
3 | #![feature(min_const_generics, min_specialization)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable
error[E0554]: `#![feature]` may not be used on the beta release channel
--> src/lib.rs:4:1
|
4 | #![feature(box_patterns)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
Closes https://github.com/rust-lang/rust/issues/83715.
Fix ICE if original_span(fn_sig) returns a span not in body sourcefile
Fixes: #84421
r? ````@tmandry````
fyi: ````@wesleywiser```` ````@sdroege```` ````@rajivshah3````
rustc: Use LLVM's new saturating float-to-int intrinsics
This commit updates rustc, with an applicable LLVM version, to use
LLVM's new `llvm.fpto{u,s}i.sat.*.*` intrinsics to implement saturating
floating-point-to-int conversions. This results in a little bit tighter
codegen for x86/x86_64, but the main purpose of this is to prepare for
upcoming changes to the WebAssembly backend in LLVM where wasm's
saturating float-to-int instructions will now be implemented with these
intrinsics.
This change allows simplifying a good deal of surrounding code, namely
removing a lot of wasm-specific behavior. WebAssembly no longer has any
special-casing of saturating arithmetic instructions and the need for
`fptoint_may_trap` is gone and all handling code for that is now
removed. This means that the only wasm-specific logic is in the
`fpto{s,u}i` instructions which only get used for "out of bounds is
undefined behavior". This does mean that for the WebAssembly target
specifically the Rust compiler will no longer be 100% compatible with
pre-LLVM 12 versions, but it seems like that's unlikely to be relied on
by too many folks.
Note that this change does immediately regress the codegen of saturating
float-to-int casts on WebAssembly due to the specialization of the LLVM
intrinsic not being present in our LLVM fork just yet. I'll be following
up with an LLVM update to pull in those patches, but affects a few other
SIMD things in flight for WebAssembly so I wanted to separate this change.
Eventually the entire `cast_float_to_int` function can be removed when
LLVM 12 is the minimum version, but that will require sinking the
complexity of it into other backends such as Cranelfit.
RustWrapper: work around unification of diagnostic handlers
This lets me build against llvm/main as of March 23rd, 2021. I'm not
entirely sure this is _correct_, but it appears to be functionally
identical to what was done in LLVM: existing callsites of
setInlineAsmDiagnosticHandler were moved to SetDiagnosticHandler() on
the context object, which we already set up in both places that we
called setInlineAsmDiagnosticHandler().
Use arrayvec 0.7, drop smallvec 0.6
With the arrival of min const generics, many alt-vec libraries have
updated to use it in some way and arrayvec is no exception. Use the
latest with minor refactoring.
Also, rustc_workspace_hack is the only user of smallvec 0.6 in the
entire tree, so drop it.
This lets me build against llvm/main as of March 23rd, 2021. I'm not
entirely sure this is _correct_, but it appears to be functionally
identical to what was done in LLVM: existing callsites of
setInlineAsmDiagnosticHandler were moved to SetDiagnosticHandler() on
the context object, which we already set up in both places that we
called setInlineAsmDiagnosticHandler().
Check for intrinsics before coercing to a function pointer
Return an error if coercing function items / non-capturing closures
to a common function pointer type would require reifying an intrinsic.
Turns ICE reported in #84297 into a proper error.
With the arrival of min const generics, many alt-vec libraries have
updated to use it in some way and arrayvec is no exception. Use the
latest with minor refactoring.
Also, rustc_workspace_hack is the only user of smallvec 0.6 in the
entire tree, so drop it.
Rollup of 12 pull requests
Successful merges:
- #84013 (Replace all `fmt.pad` with `debug_struct`)
- #84119 (Move `sys::vxworks` code to `sys::unix`)
- #84212 (Replace `Void` in `sys` with never type)
- #84251 (fix 'const-stable since' for NonZeroU*::new_unchecked)
- #84301 (Document that `index` and `index_mut` can panic)
- #84365 (Improve the docstrings of the `Lto` struct.)
- #84378 (Fix broken doc link)
- #84379 (Add GAT related tests)
- #84380 (Write Rustdoc titles like "x in crate::mod - Rust")
- #84390 (Format `Struct { .. }` on one line even with `{:#?}`.)
- #84393 (Support `x.py doc std --open`)
- #84406 (Remove `delete` alias from `mem::drop`.)
Failed merges:
- #84387 (Move `sys_common::poison` to `sync::poison`)
r? `@ghost`
`@rustbot` modify labels: rollup
This commit updates rustc, with an applicable LLVM version, to use
LLVM's new `llvm.fpto{u,s}i.sat.*.*` intrinsics to implement saturating
floating-point-to-int conversions. This results in a little bit tighter
codegen for x86/x86_64, but the main purpose of this is to prepare for
upcoming changes to the WebAssembly backend in LLVM where wasm's
saturating float-to-int instructions will now be implemented with these
intrinsics.
This change allows simplifying a good deal of surrounding code, namely
removing a lot of wasm-specific behavior. WebAssembly no longer has any
special-casing of saturating arithmetic instructions and the need for
`fptoint_may_trap` is gone and all handling code for that is now
removed. This means that the only wasm-specific logic is in the
`fpto{s,u}i` instructions which only get used for "out of bounds is
undefined behavior". This does mean that for the WebAssembly target
specifically the Rust compiler will no longer be 100% compatible with
pre-LLVM 12 versions, but it seems like that's unlikely to be relied on
by too many folks.
Note that this change does immediately regress the codegen of saturating
float-to-int casts on WebAssembly due to the specialization of the LLVM
intrinsic not being present in our LLVM fork just yet. I'll be following
up with an LLVM update to pull in those patches, but affects a few other
SIMD things in flight for WebAssembly so I wanted to separate this change.
Eventually the entire `cast_float_to_int` function can be removed when
LLVM 12 is the minimum version, but that will require sinking the
complexity of it into other backends such as Cranelfit.
Suggest `.as_ref()` on borrow error involving `Option`/`Result`
When encountering a E0382 borrow error involving an `Option` or `Result`
provide a suggestion to use `.as_ref()` on the prior move location to
avoid the move.
Fix#84165.
coverage of async function bodies should match non-async
This fixes some missing coverage within async function bodies.
Commit 1 demonstrates the problem in the fixed issue, and commit 2 corrects it.
Fixes: #83985
Add coverage to continue statements
`continue` statements were missing coverage. This was particularly
noticeable in a match pattern that contained only a `continue`
statement, leaving the branch appear uncounted. This PR addresses the
problem and adds tests to prove it.
r? `@tmandry`
cc: `@wesleywiser`
When encountering a E0382 borrow error involving an `Option` or `Result`
provide a suggestion to use `.as_ref()` on the prior move location to
avoid the move.
Fix#84165.
Introduce CompileMonoItem DepNode
This is likely required for allowing efficient hot code swap support in cg_clif's jit mode. My prototype currently requires re-compiling all functions, which is both slow and uses a lot of memory as there is not support for freeing the memory used by replaced functions yet.
cc https://github.com/bjorn3/rustc_codegen_cranelift/issues/1087
Match against attribute name when validating attributes
Extract attribute name once and match it against symbols that are being
validated, instead of using `Session::check_name` for each symbol
individually.
Assume that all validated attributes are used, instead of marking them
as such, since the attribute check should be exhaustive.
Stablize `non-ascii-idents`
This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467).
r? `@Manishearth`
Don't set fast-math for the SIMD operations we set it for previously
Instead of `fast-math`. `fast-math` implies things like functions not
being able to accept as an argument or return as a result, say, `inf`
which made these functions confusingly named or behaving incorrectly,
depending on how you interpret it. It seems that the intended behaviour
was to set a `afn` flag instead. In doing so we also renamed the
intrinsics to say `_approx` so that it is clear these are not precision
oriented and the users can act accordingly.
Fixes#84268
`continue` statements were missing coverage. This was particularly
noticeable in a match pattern that contained only a `continue`
statement, leaving the branch appear uncounted. This PR addresses the
problem and adds tests to prove it.
`fast-math` implies things like functions not being able to accept as an
argument or return as a result, say, `inf` which made these functions
confusingly named or behaving incorrectly, depending on how you
interpret it. Since the time when these intrinsics have been implemented
the intrinsics user's (stdsimd) approach has changed significantly and
so now it is required that these intrinsics operate normally rather than
in "whatever" way.
Fixes#84268
fix incomplete diagnostic notes when closure returns conflicting for genric type
fixes#84128
Correctly report the span on for conflicting return type in closures
Builtin derive macros: fix error with const generics default
This fixes a bug where builtin derive macros (like Clone, Debug) would basically copy-paste the default from a const generic, causing a compile error with very confusing message - it would say defaults are not allowed in impl blocks, while pointing at struct/enum/union definition.
Detect when suggested paths enter extern crates more rigorously
When reporting resolution errors, the compiler tries to avoid suggesting importing inaccessible paths from other crates. However, the search for suggestions only recognized when it was entering a crate root directly, and so failed to recognize a path like `crate::module::private_item`, where `module` was imported from another crate with `use other_crate::module`, as entering another crate.
Fixes#80079Fixes#84081
Compiler error messages: reduce assertiveness of message E0384
This message is emitted as guidance by the compiler when a developer attempts to reassign a value to an immutable variable. Following the message will always currently work, but it may not always be the best course of action; following the 'consider ...' messaging pattern provides a hint to the developer that it could be wise to explore other alternatives.
Resolves#84144
Remove #[main] attribute.
This removes the #[main] attribute support from the compiler according to the decisions within #29634. For existing use cases within test harness generation, replaced it with a newly-introduced internal attribute `#[rustc_main]`.
This is first part extracted from #84062 .
Closes#29634.
r? `@petrochenkov`
Add simd_{round,trunc} intrinsics
LLVM supports many functions from math.h in its IR. Many of these
have SIMD instructions on various platforms. So, let's add round and
trunc so std::arch can use them.
Yes, exact comparison is intentional: rounding must always return a
valid integer-equal value, except for inf/NAN.
Update docs for unsafe_op_in_unsafe_fn stability.
The unsafe_op_in_unsafe_fn lint was stabilized in #79208, but the bottom of this documentation wasn't updated.
I'm just guessing at the reason here, hopefully it is close to correct. The only discussion I found is https://github.com/rust-lang/rust/issues/71668#issuecomment-730399862 which didn't really explain the thought process behind the decision.
LLVM supports many functions from math.h in its IR. Many of these have
single-instruction variants on various platforms. So, let's add them so
std::arch can use them.
Yes, exact comparison is intentional: rounding must always return a
valid integer-equal value, except for inf/NAN.
add lint deref_nullptr detecting when a null ptr is dereferenced
fixes#83856
changelog: add lint that detect code like
```rust
unsafe {
&*core::ptr::null::<i32>()
};
unsafe {
addr_of!(std::ptr::null::<i32>())
};
let x: i32 = unsafe {*core::ptr::null()};
let x: i32 = unsafe {*core::ptr::null_mut()};
unsafe {*(0 as *const i32)};
unsafe {*(core::ptr::null() as *const i32)};
```
```
warning: Dereferencing a null pointer causes undefined behavior
--> src\main.rs:5:26
|
5 | let x: i32 = unsafe {*core::ptr::null()};
| ^^^^^^^^^^^^^^^^^^
| |
| a null pointer is dereferenced
| this code causes undefined behavior when executed
|
= note: `#[warn(deref_nullptr)]` on by default
```
Limitation:
It does not detect code like
```rust
const ZERO: usize = 0;
unsafe {*(ZERO as *const i32)};
```
or code where `0` is not directly a literal
Avoid an `Option<Option<_>>`
By simply swapping the calls to `map` and `and_then` around the complexity of
handling an `Option<Option<_>>` disappears.
`@rustbot` modify labels +C-cleanup +T-compiler
Fix typo in error message
Also tweaked the message a bit by
- removing the hyphen, because in my opinion the hyphen makes the
message a bit harder to read, especially combined with the backticks;
- adding the word "be", because I think it's a bit clearer that way.
This message is emitted as guidance by the compiler when a developer attempts to reassign a value to an immutable variable. Following the message will always currently work, but it may not always be the best course of action; following the 'consider ...' messaging pattern provides a hint to the developer that it could be wise to explore other alternatives.
Also tweaked the message a bit by
- removing the hyphen, because in my opinion the hyphen makes the
message a bit harder to read, especially combined with the backticks;
- adding the word "be", because I think it's a bit clearer that way.
Improve trait/impl method discrepancy errors
* Use more accurate spans
* Clean up some code by removing previous hack
* Provide structured suggestions
Structured suggestions are particularly useful for cases where arbitrary self types are used, like in custom `Future`s, because the way to write `self: Pin<&mut Self>` is not necessarily self-evident when first encountered.
Issue 81508 fix
Fix#81508
**Problem**: When variable name is used incorrectly as path, error and warning point to undeclared/unused name, when in fact the name is used, just incorrectly (should be used as a variable, not part of a path).
**Summary for fix**: When path resolution errs, diagnostics checks for variables in ```ValueNS``` that have the same name (e.g., variable rather than path named Foo), and adds additional suggestion that user may actually intend to use the variable name rather than a path.
The fix does not suppress or otherwise change the *warning* that results. I did not find a straightforward way in the code to modify this, but would love to make changes here as well with any guidance.
This PR modifies the macro expansion infrastructure to handle attributes
in a fully token-based manner. As a result:
* Derives macros no longer lose spans when their input is modified
by eager cfg-expansion. This is accomplished by performing eager
cfg-expansion on the token stream that we pass to the derive
proc-macro
* Inner attributes now preserve spans in all cases, including when we
have multiple inner attributes in a row.
This is accomplished through the following changes:
* New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced.
These are very similar to a normal `TokenTree`, but they also track
the position of attributes and attribute targets within the stream.
They are built when we collect tokens during parsing.
An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when
we invoke a macro.
* Token capturing and `LazyTokenStream` are modified to work with
`AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which
is created during the parsing of a nested AST node to make the 'outer'
AST node aware of the attributes and attribute target stored deeper in the token stream.
* When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`),
we tokenize and reparse our target, capturing additional information about the locations of
`#[cfg]` and `#[cfg_attr]` attributes at any depth within the target.
This is a performance optimization, allowing us to perform less work
in the typical case where captured tokens never have eager cfg-expansion run.
Extract attribute name once and match it against symbols that are being
validated, instead of using `Session::check_name` for each symbol
individually.
Assume that all validated attributes are used, instead of marking them
as such, since the attribute check should be exhaustive.
This enables us to set more generic labels shared between targets. For
example `target_family="wasm"` across all targets that are conceptually
"wasm".
See https://github.com/rust-lang/reference/pull/1006
Expand derive invocations in left-to-right order
While derives were being collected in left-to-order order, the
corresponding `Invocation`s were being pushed in the wrong order.
Avoid `;` -> `,` recovery and unclosed `}` recovery from being too verbose
Those two recovery attempts have a very bad interaction that causes too
unnecessary output. Add a simple gate to avoid interpreting a `;` as a
`,` when there are unclosed braces.
Fix#83498.
Categorize and explain target features support
There are 3 different uses of the `-C target-feature` args passed to rustc:
1. All of the features are passed to LLVM, which uses them to configure code-generation. This is sort-of stabilized since 1.0 though LLVM does change/add/remove target features regularly.
2. Target features which are in [the compiler's allowlist](69e1d22ddb/compiler/rustc_codegen_ssa/src/target_features.rs (L12-L34)) can be used in `cfg!(target_feature)` etc. These may have different names than in LLVM and are renamed before passing them to LLVM.
3. Target features which are in the allowlist and which are stabilized or feature-gate-enabled can be used in `#[target_feature]`.
It can be confusing that `rustc --print target-features` just prints out the LLVM features without separating out the rustc features or even mentioning that the dichotomy exists.
This improves the situation by separating out the rustc and LLVM target features and adding a brief explanation about the difference.
Abbreviated Example Output:
```
$ rustc --print target-features
Features supported by rustc for this target:
adx - Support ADX instructions.
aes - Enable AES instructions.
...
xsaves - Support xsaves instructions.
crt-static - Enables libraries with C Run-time Libraries(CRT) to be statically linked.
Code-generation features supported by LLVM for this target:
16bit-mode - 16-bit mode (i8086).
32bit-mode - 32-bit mode (80386).
...
x87 - Enable X87 float instructions.
xop - Enable XOP instructions.
Use +feature to enable a feature, or -feature to disable it.
For example, rustc -C target-cpu=mycpu -C target-feature=+feature1,-feature2
Code-generation features cannot be used in cfg or #[target_feature],
and may be renamed or removed in a future version of LLVM or rustc.
```
Motivated by #83975.
CC https://github.com/rust-lang/rust/issues/49653
Those two recovery attempts have a very bad interaction that causes too
unnecessary output. Add a simple gate to avoid interpreting a `;` as a
`,` when there are unclosed braces.
Don't concatenate binders across types
Partially addresses #83737
There's actually two issues that I uncovered in #83737. The first is that we are concatenating bound vars across types, i.e. in
```
F: Fn(&()) -> &mut (dyn Future<Output = ()> + Unpin)
```
the bound vars on `Future` get set as `for<anon>` since those are the binders on `Fn(&()`. This is obviously wrong, since we should only concatenate directly nested trait refs. This is solved here by introducing a new `TraitRefBoundary` scope, that we put around the "syntactical" trait refs and basically don't allow concatenation across.
Now, this alone *shouldn't* be a super terrible problem. At least not until you consider the other issue, which is a much more elusive and harder to design a "perfect" fix. A repro can be seen in:
```
use core::future::Future;
async fn handle<F>(slf: &F)
where
F: Fn(&()) -> &mut (dyn for<'a> Future<Output = ()> + Unpin),
{
(slf)(&()).await;
}
```
Notice the `for<'a>` around `Future`. Here, `'a` is unused, so the `for<'a>` Binder gets changed to a `for<>` Binder in the generator witness, but the "local decl" still has it. This has heavy intersections with region anonymization and erasing. Luckily, it's not *super* common to find this unique set of circumstances. It only became apparently because of the first issue mentioned here. However, this *is* still a problem, so I'm leaving #83737 open.
r? `@nikomatsakis`
The issue was that the resulting debuginfo was too complex for LLVM to
translate into CodeView records correctly. As a result, it simply
ignored the debuginfo which meant Windows debuggers could not display
any closed over variables when stepping inside a closure.
This fixes that by spilling additional variables to the stack so that
the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and
LLVM can generate the correct CV records.
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.
When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.
Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.
To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.
With the addition of a new ABI, this enables rustc to:
* Eventually remove the "wasm-bindgen compat hack". Once this
ABI is stable wasm-bindgen can switch to using it everywhere.
Afterwards the wasm32-unknown-unknown target can have its default ABI
updated to match C.
* Expose the ability to precisely match an ABI signature for a
WebAssembly function, regardless of what the C ABI that clang chooses
turns out to be.
* Continue to evolve the definition of the default C ABI to match what
clang does on all targets, since the purpose of that ABI will be
explicitly matching C rather than generating particular function
imports/exports.
Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
Remove the insta-stable `cfg(wasm)`
The addition of `cfg(wasm)` was an oversight on my end that turns out to have a number
of downsides:
* It was introduced as an insta-stable addition, forgoing the usual
staging mechanism we use for potentially far-reaching changes;
* It is a breaking change for people who are using `--cfg wasm` either
directly or via cargo for other purposes;
* It is not entirely clear if a bare `wasm` cfg is a right option or
whether `wasm` family of targets are special enough to warrant
special-casing these targets specifically.
As for the last point, there appears to be a fair amount of support for
reducing the boilerplate in specifying architectures from the same
family, while ignoring their pointer width. The suggested way forward
would be to propose such a change as a separate RFC as it is potentially
a quite contentious addition.
cc #83879 `@devsnek`
Add more info for common trait resolution and async/await errors
* Suggest `Pin::new`/`Box::new`/`Arc::new`/`Box::pin` in more cases
* Point at `impl` and type defs introducing requirements on E0277
The addition of `cfg(wasm)` was an oversight on my end that has a number
of downsides:
* It was introduced as an insta-stable addition, forgoing the usual
staging mechanism we use for potentially far-reaching changes;
* It is a breaking change for people who are using `--cfg wasm` either
directly or via cargo for other purposes;
* It is not entirely clear if a bare `wasm` cfg is a right option or
whether `wasm` family of targets are special enough to warrant
special-casing these targets specifically.
As for the last point, there appears to be a fair amount of support for
reducing the boilerplate in specifying architectures from the same
family, while ignoring their pointer width. The suggested way forward
would be to propose such a change as a separate RFC as it is potentially
a quite contentious addition.
Stabilize cmp_min_max_by
I would like to propose cmp::{min_by, min_by_key, max_by, max_by_key}
for stabilization.
These are relatively simple and seemingly uncontroversial functions and
have been unchanged in unstable for a while now.
Closes: #64460
Rollup of 8 pull requests
Successful merges:
- #83476 (Add strong_count mutation methods to Rc)
- #83634 (Do not emit the advanced diagnostics on macros)
- #83816 (Trigger `unused_doc_comments` on macros at once)
- #83916 (Use AnonConst for asm! constants)
- #83935 (forbid `impl Trait` in generic param defaults)
- #83936 (Disable using non-ascii identifiers in extern blocks.)
- #83945 (Add suggestion to reborrow mutable references when they're moved in a for loop)
- #83954 (Do not ICE when closure is involved in Trait Alias Impl Trait)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
I would like to propose cmp::{min_by, min_by_key, max_by, max_by_key}
for stabilization.
These are relatively simple and seemingly uncontroversial functions and
have been unchanged in unstable for a while now.
use a `SmallVec` in `impl_or_trait_item`
#83293 showed that this is fairly hot, slightly improves max-rss and cpu cycles, does not noticeably improve instruction counts
