Encode DepKind as u16
The derived Encodable/Decodable impls serialize/deserialize as a varint, which results in a lot of code size around the encoding/decoding of these types which isn't justified: The full range of values here is rather small but doesn't quite fit in to a `u8`. Growing _all_ serialized `DepKind` to 2 bytes costs us on average 1% size in the incr comp dep graph, which I plan to recoup in https://github.com/rust-lang/rust/pull/110050 by taking advantage of the unused bits in all the serialized `DepKind`.
r? `@nnethercote`
Don't manually compute param indices when adding implicit `Sized` and `ConstParamHasTy`
We can just use resolve_bound_vars to compute these indices faithfully.
This also makes the code easier to support where clauses on `non_lifetime_binders` (like `where for<T: Debug> ...`, etc, which I've got a [WIP implementation of](https://github.com/rust-lang/rust/compare/master...compiler-errors:rust:non-lifetime-binder-where-clauses)).
r? `@cjgillot`
Since `filename_for_metadata()` and
`OutputFilenames::path(OutputType::Metadata)` had different logic for
the name of the metadata file, the `.d` file contained a file name
different from the actual name used. Share the logic to fix the
out-of-sync name.
Closes 68839.
rustc_llvm: Link to `zlib` on dragonfly and solaris
On native builds `llvm-config` picks up `zlib` and this gets pased into
the rust build tools, but on cross builds `llvm-config` is explicitly
ignored as it contains information for the host system and cannot be
trusted to be accurate for the target system.
Both DragonFly and Solaris contain `zlib` in the base system, so this is
both a safe assumption and required for a successful cross build unless
`zlib` support is disabled in LLVM.
This is more or less in the same vein as rust-lang#75713 and rust-lang#75655.
Skip rendering metadata strings from include_str!/include_bytes!
The const rendering code in rustdoc completely ignores consts from expansions, but the compiler was rendering all consts. So some consts (namely those from `include_bytes!`) were rendered then ignored.
Most of the diff here is from moving `print_const_expr` from rustdoc into `rustc_hir_pretty` so that it can be used in rustdoc and when building rmeta files.
Lower `Or` pattern without allocating place
cc `@azizghuloum` `@cjgillot`
Related to #111583 and #111644
While reviewing #111644, it occurs to me that while we directly lower conjunctive predicates, which are connected with `&&`, into the desirable control flow, today we don't directly lower the disjunctive predicates, which are connected with `||`, in the similar fashion. Instead, we allocate a place for the boolean temporary to hold the result of evaluating the `||` expression.
Usually I would expect optimization at later stages to "inline" the evaluation of boolean predicates into simple CFG, but #111583 is an example where `&&` is failing to be optimized away and the assembly shows that both the expensive operands are evaluated. Therefore, I would like to make a small change to make the CFG a bit more straight-forward without invoking the `as_temp` machinery, and plus avoid allocating the place to hold the boolean result as well.
Permit recursive weak type aliases
I saw #63097 and thought "we can do ~~better~~ funnier". So here it is. It's not useful, but it's certainly something. This may actually become feasible with lazy norm (so in 5 years (constant, not reducing over time)).
r? `@estebank`
cc `@GuillaumeGomez`
Capture lifetimes for associated type bounds destined to be lowered to opaques
Some associated type bounds get lowered to opaques, but they're not represented in the AST as opaques.
That means that we never collect lifetimes for them (`record_lifetime_params_for_impl_trait`) which are used currently for RPITITs, which capture all of their in-scope lifetimes[^1]. This means that the nested RPITITs that arise from some type like `impl Foo<Type: Bar>` (~> `impl Foo<Type = impl Bar>`) don't capture any lifetimes, leading to ICEs.
This PR makes sure we collect the lifetimes for associated type bounds as well, and make sure that they are set up correctly for opaque type lowering later.
Fixes#115360
[^1]: #114489
Work around ICE in diagnostics for local super-universes missing `UniverseInfo`s
In issue #114907, canonicalization of liveness dropck-outlives results (IIUC) encounters universes absent from the original query. Some local universes [are created](f3a1bae88c/compiler/rustc_infer/src/infer/canonical/query_response.rs (L417-L425)) for the mapping, but importantly, they won't have associated causes.
These missing `UniverseInfo`s can be [needed](f3a1bae88c/compiler/rustc_borrowck/src/diagnostics/region_errors.rs (L376)) during diagnostics, [causing the `IndexMap: key not found` ICE](d55522aad8/compiler/rustc_borrowck/src/region_infer/mod.rs (L2252)) seen in the issue.
This PR works around this by returning the suboptimal catch-all cause, to avoid the ICE. It does results in suboptimal diagnostics right now, but it's better than an ICE.
r? `@matthewjasper.`
Let me know if there's a good easy-ish way to fix this, but I believe that for some of these erroneous cases and diagnostics, that inference/canonicalization/higher-ranked subtyping/etc may not behave exactly the same with the new trait solver? If that's the case then it'd probably be best to wait a bit more to do the correct fix.
Fixes#114907.
cc `@aliemjay`
This was backfilling causes for new universes that may have been created
by an op, when there was no error info to use for improved
diagnostics. We don't need to do that anymore: `other()` is the default when
there is no registered universe cause.
`rustc_layout_scalar_valid_range` makes ctors unsafe
We already validate this when we use the ctor in a call, e.g. `Variant(1)`, but not if we use the ctor as a fn ptr, e.g. `.map(Variant)`. The easiest way to fix the latter is (afaict) is by marking the ctor as unsafe itself.
Fixes#115284
This was pre-filling causes for universes that could already exist in
the InferCtxt. We don't need to do that anymore: `other()` is the default when
there is no registered universe cause.
This was backfilling causes for the new universes that can be created by
the InferCtxt. We don't need to do that anymore: `other()` is the default when
there is no registered universe cause.
Some SMIR Const cleanups
Only e1def3bd41b021ce87a5d639b10cdf4a7df1d0b5 is new logic, everywhere else I just used the implementations that y'all had already written.
r? `@spastorino`
cc `@ouz-a`
Make `termcolor` types public in `rustc_errors`
After https://github.com/rust-lang/rust/pull/114104, `rust-gpu` is unable to create a custom `Emitter` as the bounds have changed to include `WriteColor`.
I was able to work around this by adding `termcolor` as a direct dependency, but I believe this should be exposed as part of `rustc_errors` proper.
See https://github.com/rust-lang/rust/pull/102992 for why `rust-gpu` needs to create a custom emitter.
Fix bors missing a commit when merging #115355
bors incorrectly merged an outdated version of PR #115355 (via rollup #115370):
- it [recorded r+](https://github.com/rust-lang/rust/pull/115355#issuecomment-1698372365) as approving commit 325b585259, and thus merged the original revision 7762ac7bb5
- but the branch at the time was at commit eefa07d69b, so bors missed the `compiler/rustc_trait_selection/src/solve/search_graph/mod.rs` cleanup in commit 0e1e964a34😓
Thankfully the change that bors missed was small, and this new PR corrects the situation (as I'd rather avoid having confusing multiple merge commits of PR #115355 in the git history)
r? ``@compiler-errors``
Fix inlining with -Zalways-encode-mir
Only inline functions that are considered eligible for inlining
by the reachability pass.
This constraint was previously indirectly enforced by only exporting MIR
of eligible functions, but that approach doesn't work with
-Zalways-encode-mir enabled.
After https://github.com/rust-lang/rust/pull/114104, `rust-gpu` is unable to create a custom `Emitter` as the bounds have changed to include `WriteColor`.
I was able to work around this by adding `termcolor` as a direct dependency, but I believe this should be exposed as part of `rustc_errors` proper.
See https://github.com/rust-lang/rust/pull/102992 for why `rust-gpu` needs to create a custom emitter.
Add `ParallelGuard` type to handle unwinding in parallel sections
This adds a `ParallelGuard` type to handle unwinding in parallel sections instead of manually dealing with panics in each parallel operation. This also adds proper panic handling to the `join` operation.
cc `@SparrowLii`
Inline functions called from `add_coverage`
This removes quite a bit of indirection and duplicated code related to getting the `FunctionCoverage`.
CC `@Zalathar`
Capture all lifetimes for TAITs and impl trait in associated types
This reverts commit cb9467515b, reversing changes made to 57781b24c5. (This is only true for the tests, the change itself was done from scratch, as the compiler has diverged sufficiently for a revert to not make sense anymore).
This implements the lang team decision from this meeting: https://hackmd.io/sFaSIMJOQcuwCdnUvCxtuQ?view
r? `@cjgillot` on the impl
Use conditional synchronization for Lock
This changes `Lock` to use synchronization only if `mode::is_dyn_thread_safe` could be true. This reduces overhead for the parallel compiler running with 1 thread.
The emitters are changed to use `DynSend` instead of `Send` so they can still use `Lock`.
A Rayon thread pool is not used with 1 thread anymore, as session globals contains `Lock`s which are no longer `Sync`.
Performance improvement with 1 thread and `cfg(parallel_compiler)`:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">1.7665s</td><td align="right">1.7336s</td><td align="right">💚 -1.86%</td></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.2780s</td><td align="right">0.2736s</td><td align="right">💚 -1.61%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.9994s</td><td align="right">0.9824s</td><td align="right">💚 -1.70%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">1.5875s</td><td align="right">1.5656s</td><td align="right">💚 -1.38%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check</td><td align="right">6.0682s</td><td align="right">5.9532s</td><td align="right">💚 -1.90%</td></tr><tr><td>Total</td><td align="right">10.6997s</td><td align="right">10.5083s</td><td align="right">💚 -1.79%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9831s</td><td align="right">💚 -1.69%</td></tr></table>
cc `@SparrowLii`
Rollup of 7 pull requests
Successful merges:
- #113565 (Make SIGSEGV handler emit nicer backtraces)
- #114704 (parser: not insert dummy field in struct)
- #115272 (miri/diagnostics: don't forget to print_backtrace when ICEing on unexpected errors)
- #115313 (Make `get_return_block()` return `Some` only for HIR nodes in body)
- #115347 (suggest removing `impl` in generic trait bound position)
- #115355 (new solver: handle edge case of a recursion limit of 0)
- #115363 (Don't suggest adding parentheses to call an inaccessible method.)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't suggest adding parentheses to call an inaccessible method.
Previously, code of this form would emit E0615 (attempt to use a method as a field), thus emphasizing the existence of private methods that the programmer probably does not care about. Now it ignores their existence instead, producing error E0609 (no field). The motivating example is:
```rust
let x = std::rc::Rc::new(());
x.inner;
```
which would previously mention the private method `Rc::inner()`, even though `Rc<T>` intentionally has no public methods so that it can be a transparent smart pointer for any `T`.
```rust
error[E0615]: attempted to take value of method `inner` on type `Rc<()>`
--> src/main.rs:3:3
|
3 | x.inner;
| ^^^^^ method, not a field
|
help: use parentheses to call the method
|
3 | x.inner();
| ++
```
With this change, it emits E0609 and no suggestion.
new solver: handle edge case of a recursion limit of 0
Apparently a recursion limit of 0 is possible/valid/useful/used/cute, the more you know 🌟 .
(It's somewhat interesting to me that the old solver seemingly handles this, and that the new solver currently requires a recursion limit of 2 here)
r? `@compiler-errors.`
Fixes#115351.
suggest removing `impl` in generic trait bound position
rustc already does this recovery in type param position (`<T: impl Trait>` -> `<T: Trait>`).
This PR also adds that suggestion in trait bound position (e.g. `where T: impl Trait` or `trait Trait { type Assoc: impl Trait; }`)
Make `get_return_block()` return `Some` only for HIR nodes in body
Fixes#114918
The issue occurred while compiling the following input:
```rust
fn uwu() -> [(); { () }] {
loop {}
}
```
It was caused by the code below trying to suggest a missing return type which resulted in a const eval cycle: 1bd043098e/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs (L68-L75)
The root cause was `get_return_block()` returning an `Fn` node for a node in the return type (i.e. the second `()` in the return type `[(); { () }]` of the input) although it is supposed to do so only for nodes that lie in the body of the function and return `None` otherwise (at least as per my understanding).
The PR fixes the issue by fixing this behaviour of `get_return_block()`.
parser: not insert dummy field in struct
Fixes#114636
This PR eliminates the dummy field, initially introduced in #113999, thereby enabling unrestricted use of `ident.unwrap()`. A side effect of this action is that we can only report the error of the first macro invocation field within the struct node.
An alternative solution might be giving a virtual name to the macro, but it appears more complex.(https://github.com/rust-lang/rust/issues/114636#issuecomment-1670228715). Furthermore, if you think https://github.com/rust-lang/rust/issues/114636#issuecomment-1670228715 is a better solution, feel free to close this PR.
Make SIGSEGV handler emit nicer backtraces
This annotates the code heavily with comments to explain what is going on, for the benefit of other compiler contributors. The backtrace also emits appropriate comments to clarify, to a programmer who may not know why a bunch of file paths and hexadecimal blather was just dumped into stderr, what is going on. Finally, it detects cycles and uses their regularity to avoid repeating a bunch of text. The previous backtraces we were emitting was extremely unfriendly, potentially confusing, and often alarming, and this makes things almost "nice".
We can't necessarily make them much nicer than this, because a signal handler must use "signal-safe" functions. This precludes conveniences like dynamic allocations. Fortunately, Rust's stdlib has allocation-free formatting, but it may hinder integrating this error with our localization middleware, as I wasn't able to clearly ascertain, at a glance, whether there was a zero-alloc path through it.
r? `@Nilstrieb`
Adapt table sizes to the contents
This is an implementation of https://github.com/rust-lang/compiler-team/issues/666
The objective of this PR is to permit the rmeta format to accommodate larger crates that need offsets larger than a `u32` can store without compromising performance for crates that do not need such range. The second commit is a number of tiny optimization opportunities I noticed while looking at perf recordings of the first commit.
The rmeta tables need to have fixed-size elements to permit lazy random access. But the size only needs to be fixed _per table_, not per element type. This PR adds another `usize` to the table header which indicates the table element size. As each element of a table is set, we keep track of the widest encoded table value, then don't bother encoding all the unused trailing bytes on each value. When decoding table elements, we copy them to a full-width array if they are not already full-width.
`LazyArray` needs some special treatment. Most other values that are encoded in tables are indexes or offsets, and those tend to be small so we get to drop a lot of zero bytes off the end. But `LazyArray` encodes _two_ small values in a fixed-width table element: A position of the table and the length of the table. The treatment described above could trim zero bytes off the table length, but any nonzero length shields the position bytes from the optimization. To improve this, we interleave the bytes of position and length. This change is responsible for about half of the crate metadata win on many crates.
Fixes https://github.com/rust-lang/rust/issues/112934 (probably)
Fixes https://github.com/rust-lang/rust/issues/103607
Previously, the test code would emit E0615, thus revealing the existence
of private methods that the programmer probably does not care about.
Now it ignores their existence instead, producing error E0609 (no field).
The motivating example is:
```rust
let x = std::rc::Rc::new(());
x.inner;
```
which would previously mention the private method `Rc::inner()`, even
though `Rc<T>` intentionally has no public methods so that it can be a
transparent smart pointer for any `T`.
Always add LC_BUILD_VERSION for metadata object files
As of Xcode 15 Apple's linker has become a bit more strict about the warnings it produces. One of those new warnings requires all valid Mach-O object files in an archive to have a LC_BUILD_VERSION load command:
```
ld: warning: no platform load command found in 'ARCHIVE[arm64][2106](lib.rmeta)', assuming: iOS-simulator
```
This was already being done for Mac Catalyst so this change expands this logic to include it for all Apple platforms. I filed this behavior change as FB12546320 and was told it was the new intentional behavior.
Tweaks and improvements on SMIR around generics_of and predicates_of
r? `@oli-obk`
This allows an API like the following ...
```rust
let trait_decls = stable_mir::all_trait_decls().iter().map(|trait_def| {
let trait_decl = stable_mir::trait_decl(trait_def);
let generics = trait_decl.generics_of();
let predicates = trait_decl.predicates_of().predicates;
```
I didn't like that much `trait_def.trait_decl()` which is it possible but adding a method to a def_id that loads up a whole trait definition looks backwards to me.
Remove conditional use of `Sharded` from query state
`Sharded` is already a zero cost abstraction, so it shouldn't affect the performance of the single thread compiler if LLVM does its job.
r? `@cjgillot`
Use `preserve_mostcc` for `extern "rust-cold"`
As experimentation in #115242 has shown looks better than `coldcc`. Notably, clang exposes `preserve_most` (https://clang.llvm.org/docs/AttributeReference.html#preserve-most) but not `cold`, so this change should put us on a better-supported path.
And *don't* use a different convention for cold on Windows, because that actually ends up making things worse. (See comment in the code.)
cc tracking issue #97544
miri ABI compatibility check: accept u32 and i32
If only the sign differs, then surely these types are compatible. (We do still check that `arg_ext` is the same, just in case.)
Also I made it so that the ABI check must *imply* that size and alignment are the same, but it doesn't actively check that itself. With how crazy ABI constraints get, having equal size and align really shouldn't be used as a signal for anything I think...
Make RPITITs capture all in-scope lifetimes
Much like #114616, this implements the lang team decision from this T-lang meeting on [opaque captures strategy moving forward](https://hackmd.io/sFaSIMJOQcuwCdnUvCxtuQ?view). This will be RFC'd soon, but given that RPITITs are a nightly feature, this shouldn't necessarily be blocked on that.
We unconditionally capture all lifetimes in RPITITs -- impl is not as simple as #114616, since we still need to duplicate RPIT lifetimes to make sure we reify any late-bound lifetimes in scope.
Closes#112194
don't use SnapshotVec in Graph implementation, as it looks unused; use Vec instead
`Graph` don't use `SnapshotVec` methods, so use simple `Vec` instead?
More precisely detect cycle errors from type_of on opaque
Not sure if this still needs work. Just putting it up for initial impressions, since it seems that a few people are frustrated with the increased error verbosity due to #113320.
Essentially we introduce a new sub-query for `type_of` specifically for opaques which returns a value that is able to distinguish "has errors" from "due to cycle recovery".
Fixes#115188
r? `@oli-obk`
codegen_llvm/llvm_type: avoid matching on the Rust type
This `match` is highly suspicious. Looking at `scalar_llvm_type_at` I think it makes no difference. But if it were to make a difference that would be a huge problem, since it doesn't look through `repr(transparent)`!
Cc `@eddyb` `@bjorn3`
Avoid duplicate `large_assignments` lints
By checking for overlapping spans.
This PR does the "reduce noisiness" task in #83518.
r? `@oli-obk` who added E-mentor and E-help-wanted and wrote the initial code.
(The fix itself is in dc82736677. The two commits before that are just small refactorings.)
Rollup of 6 pull requests
Successful merges:
- #109660 (Document that SystemTime does not count leap seconds)
- #114238 (Fix implementation of `Duration::checked_div`)
- #114512 (std/tests: disable ancillary tests on freebsd since the feature itsel…)
- #114919 (style-guide: Add guidance for defining formatting for specific macros)
- #115278 (tell people what to do when removing an error code)
- #115280 (avoid triple-backtrace due to panic-during-cleanup)
r? `@ghost`
`@rustbot` modify labels: rollup
tell people what to do when removing an error code
Currently tidy and CI send developers on a wild goose chase:
- you edit the code
- CI/tidy tells you that an error code is gone, so you remove it from the list
- CI/tidy tells you that the markdown file is stale, so you remove that as well
- CI (but not tidy) tells you not to remove an error description and copy what E0001 does
Let's be nice to people and directly tell them what to do rather than making them follow misleading breadcrumbs.
r? ``@GuillaumeGomez``
Load include_bytes! directly into an Lrc
This PR deletes an innocent-looking `.into()` that was converting from a `Vec<u8>` to `Lrc<[u8]>`. This has significant runtime and memory overhead when using `include_bytes!` to pull in a large binary file.
Add a specialization for encoding byte arrays in rmeta
This specialization already exists for FileEncoder, but since EncodeContext is implemented by forwarding down to FileEncoder, using EncodeContext used to bypass the specialization.
Only inline functions that are considered eligible for inlining
by the reachability pass.
This constraint was previously indirectly enforced by only exporting MIR
of eligible functions, but that approach doesn't work with
-Zalways-encode-mir enabled.
Add an (perma-)unstable option to disable vtable vptr
This flag is intended for evaluation of trait upcasting space cost for embedded use cases.
Compared to the approach in #112355, this option provides a way to evaluate end-to-end cost of trait upcasting. Rationale: https://github.com/rust-lang/rust/issues/112355#issuecomment-1658207769
## How this flag should be used (after merge)
Build your project with and without `-Zno-trait-vptr` flag. If you are using cargo, set `RUSTFLAGS="-Zno-trait-vptr"` in the environment variable. You probably also want to use `-Zbuild-std` or the binary built may be broken. Save both binaries somewhere.
### Evaluate the space cost
The option has a direct and indirect impact on vtable space usage. Directly, it gets rid of the trait vptr entry needed to store a pointer to a vtable of a supertrait. (IMO) this is a small saving usually. The larger saving usually comes with the indirect saving by eliminating the vtable of the supertrait (and its parent).
Both impacts only affects vtables (notably the number of functions monomorphized should , however where vtable reside can depend on your relocation model. If the relocation model is static, then vtable is rodata (usually stored in Flash/ROM together with text in embedded scenario). If the binary is relocatable, however, the vtable will live in `.data` (more specifically, `.data.rel.ro`), and this will need to reside in RAM (which may be a more scarce resource in some cases), together with dynamic relocation info living in readonly segment.
For evaluation, you should run `size` on both binaries, with and without the flag. `size` would output three columns, `text`, `data`, `bss` and the sum `dec` (and it's hex version). As explained above, both `text` and `data` may change. `bss` shouldn't usually change. It'll be useful to see:
* Percentage change in text + data (indicating required flash/ROM size)
* Percentage change in data + bss (indicating required RAM size)
Move a local to the `#if` block where it is used
For other cases (LLVM < 17), this was complaining under `-Wall`:
```
warning: llvm-wrapper/PassWrapper.cpp: In function ‘void LLVMRustPrintTargetCPUs(LLVMTargetMachineRef, const char*)’:
warning: llvm-wrapper/PassWrapper.cpp:311:26: warning: unused variable ‘MCInfo’ [-Wunused-variable]
warning: 311 | const MCSubtargetInfo *MCInfo = Target->getMCSubtargetInfo();
warning: | ^~~~~~
```
This reverts commit 4410868798, reversing
changes made to 249595b752.
This causes linker failures with the binutils version used by
cross (#115239), as well as miscompilations when using the mold
linker.
As experimentation in 115242 has shown looks better than `coldcc`.
And *don't* use a different convention for cold on Windows, because that actually ends up making things worse.
cc tracking issue 97544
Point at type parameter that introduced unmet bound instead of full HIR node
```
error[E0277]: the size for values of type `[i32]` cannot be known at compilation time
--> $DIR/issue-87199.rs:18:15
|
LL | ref_arg::<[i32]>(&[5]);
| ^^^^^ doesn't have a size known at compile-time
```
instead of
```
error[E0277]: the size for values of type `[i32]` cannot be known at compilation time
--> $DIR/issue-87199.rs:18:22
|
LL | ref_arg::<[i32]>(&[5]);
| ---------------- ^^^^ doesn't have a size known at compile-time
| |
| required by a bound introduced by this call
```
------
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/own-bound-span.rs:14:24
|
LL | let _: <S as D>::P<String>;
| ^^^^^^ the trait `Copy` is not implemented for `String`
|
note: required by a bound in `D::P`
--> $DIR/own-bound-span.rs:4:15
|
LL | type P<T: Copy>;
| ^^^^ required by this bound in `D::P`
```
instead of
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/own-bound-span.rs:14:12
|
LL | let _: <S as D>::P<String>;
| ^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String`
|
note: required by a bound in `D::P`
--> $DIR/own-bound-span.rs:4:15
|
LL | type P<T: Copy>;
| ^^^^ required by this bound in `D::P`
```
Fix#105306.
Remove lub_empty from lexical region resolve
As of my understanding this method made sense when we had `ReEmpty`.
Removed `lub_empty` and made the calling site code equivalent.
r? `@lcnr` `@compiler-errors`
Fix waiting on a query that panicked
This fixes waiting on a query that panicked. The code now looks for `QueryResult::Poisoned` in the query state in addition to the query cache. This fixes https://github.com/rust-lang/rust/issues/111528.
r? `@cjgillot`
Revert "Use the same DISubprogram for each instance of the same inline function within the caller"
This reverts commit 687bffa493.
Reverting to resolve ICEs reported on nightly.
cc `@dpaoliello`
Fixes#115156
Stop emitting non-power-of-two vectors in (non-portable-SIMD) codegen
Fixes#115212
It's unclear what makes this not work sometimes, since it often *does* work, so for now just disable the unusual cases. A future PR can consider doing something smarter, but this is an easy and safe tweak that we can do to resolve the regressions for now.
On the following example, point at `String` instead of the whole type:
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/own-bound-span.rs:14:24
|
LL | let _: <S as D>::P<String>;
| ^^^^^^ the trait `Copy` is not implemented for `String`
|
note: required by a bound in `D::P`
--> $DIR/own-bound-span.rs:4:15
|
LL | type P<T: Copy>;
| ^^^^ required by this bound in `D::P`
```
Add missing high-level stable_mir::generics_of fn
We forgot to add this function in https://github.com/rust-lang/rust/pull/115092, as we have done on https://github.com/rust-lang/rust/pull/115084 and other high level APIs.
At some point I think we should re-organize the structure of the code but this is what we have for now.
r? `@compiler-errors`
Would have assigned `@oli-obk` but he is still on vacations
Walk through full path in `point_at_path_if_possible`
We already had sufficient information to point at the `[u8]` in `Option::<[u8]>::None` (the `fallback_param_to_point_at` parameter), we just were neither using it nor walking through hir paths sufficiently to encounter it.
This should alleviate the need to add additional logic to extract params in a somewhat arbitrary manner of looking at the grandparent def path: https://github.com/rust-lang/rust/pull/115219#discussion_r1305946358
r? `@estebank`
Add stable for Constant in smir
Previously https://github.com/rust-lang/rust/pull/114587 we covered much of the groundwork needed to cover Const in smir, so there is no reason keep `Constant` as String.
r? `@spastorino`
Treat `StatementKind::Coverage` as completely opaque for SMIR purposes
Coverage statements in MIR are heavily tied to internal details of the coverage implementation that are likely to change, and are unlikely to be useful to third-party tools for the foreseeable future.
Add comment to the push_trailing function
## Add comment to the `push_trailing` function for clarity.
I improve the explanation by describing:
- how the code handles unicode and emoji characters using `char_indices`,
- how the code handles the absence of high indexes, and
- what the code's overall aim is.
Fix CFI: f32 and f64 are encoded incorrectly for cross-language CFI
Fix#115150 by encoding f32 and f64 correctly for cross-language CFI. I missed changing the encoding for f32 and f64 when I introduced the integer normalization option in #105452 as integer normalization does not include floating point. `f32` and `f64` should be always encoded as `f` and `d` since they are both FFI safe when their representation are the same (i.e., IEEE 754) for both the Rust compiler and Clang.
Fix#115150 by encoding f32 and f64 correctly for cross-language CFI. I
missed changing the encoding for f32 and f64 when I introduced the
integer normalization option in #105452 as integer normalization does
not include floating point. `f32` and `f64` should be always encoded as
`f` and `d` since they are both FFI safe when their representation are
the same (i.e., IEEE 754) for both the Rust compiler and Clang.
Allow explicit `#[repr(Rust)]`
This is identical to no `repr()` at all. For `Rust, packed` and `Rust, align(x)`, it should be the same as no `Rust` at all (as, afaik, `#[repr(align(16))]` uses the Rust ABI.)
The main use case for this is being able to explicitly say "I want to use the Rust ABI" in very very rare circumstances where the first obvious choice would be the C ABI yet is undesirable, which is already possible with functions as `extern "Rust"`. This would be useful for silencing https://github.com/rust-lang/rust-clippy/pull/11253. It's also more consistent with `extern`.
The lack of this also tripped me up a bit when I was new to Rust, as I expected this to be possible.
Add symbols for Clippy usage
The `arithmetic_side_effects` lint is always "interning" these non-existing symbols related to math operations causing a bit of a slowdown.
refactor(lint): translate `RenamedOrRemovedLint`
I was trying to address <https://github.com/rust-lang/cargo/issues/12495> and found that maybe I should refactor relevant lints a bit.
This PR translates `RenamedOrRemovedLint` into fluent file. To make diagnostic types clearer and easier to organize, this PR splits it into two structs.
The second commit adds lifetime annotations for removing unnecessary clones. If people feel too noisy, we can revert such change.
### Possibly relevant UI tests:
* `tests/ui/lint-removed*`
* `tests/ui/lint-renamed*`
* `tests/ui/rustdoc-renamed.rs`
* `tests/rustdoc-ui/lints/unknown-renamed-lints.rs`
elaborate a bit on the (lack of) safety in 'Mmap::map'
Sadly none of the callers of this function even consider it worth mentioning in their unsafe block that what they are doing is completely unsound.
resolve: Stop creating `NameBinding`s on every use, create them once per definition instead
`NameBinding` values are supposed to be unique, use referential equality, and be created once for every name declaration.
Before this PR many `NameBinding`s were created on name use, rather than on name declaration, because it's sufficiently cheap, and comparisons are not actually used in practice for some binding kinds.
This PR makes `NameBinding`s consistently unique and created on name declaration.
There are two special cases
- for extern prelude names creating `NameBinding` requires loading the corresponding crate, which is expensive, so such bindings are created lazily on first use, but they still keep the uniqueness by being reused on further uses.
- for legacy derive helpers (helper attributes written before derives that introduce them) the declaration and the use is basically the same thing (that's one of the reasons why they are deprecated), so they are still created on use, but we can still maybe do a bit better in a way that I described in FIXME in the last commit.
Fix races conditions with `SyntaxContext` decoding
This changes `SyntaxContext` decoding to work with concurrent decoding. The `remapped_ctxts` field now only stores `SyntaxContext` which have completed decoding, while the new `decoding` and `local_in_progress` keeps track of `SyntaxContext`s which are in process of being decoding and on which threads.
This fixes 2 issues with the current implementation. It can return an `SyntaxContext` which contains dummy data if another thread starts decoding before the first one has completely finished. Multiple threads could also allocate multiple `SyntaxContext`s for the same `raw_id`.
Suggest mutable borrow on read only for-loop that should be mutable
```
error[E0596]: cannot borrow `*test` as mutable, as it is behind a `&` reference
--> $DIR/suggest-mut-iterator.rs:22:9
|
LL | for test in &tests {
| ------ this iterator yields `&` references
LL | test.add(2);
| ^^^^ `test` is a `&` reference, so the data it refers to cannot be borrowed as mutable
|
help: use a mutable iterator instead
|
LL | for test in &mut tests {
| +++
```
Fix#114311.
Parse unnamed fields and anonymous structs or unions (no-recovery)
It is part of #114782 which implements #49804. Only parse anonymous structs or unions in struct field definition positions.
r? `@petrochenkov`
Anonymous structs or unions are only allowed in struct field
definitions.
Co-authored-by: carbotaniuman <41451839+carbotaniuman@users.noreply.github.com>
Make `Sharded` an enum and specialize it for the single thread case
This changes `Sharded` to use a single shard by an enum, reducing the size of `Sharded` for greater cache efficiency.
Performance improvement with 1 thread and `cfg(parallel_compiler)`:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">1.7009s</td><td align="right">1.6748s</td><td align="right">💚 -1.53%</td></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.2525s</td><td align="right">0.2451s</td><td align="right">💚 -2.90%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.9519s</td><td align="right">0.9353s</td><td align="right">💚 -1.74%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">1.5504s</td><td align="right">1.5280s</td><td align="right">💚 -1.45%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check</td><td align="right">5.9536s</td><td align="right">5.8873s</td><td align="right">💚 -1.11%</td></tr><tr><td>Total</td><td align="right">10.4092s</td><td align="right">10.2706s</td><td align="right">💚 -1.33%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9825s</td><td align="right">💚 -1.75%</td></tr></table>
I did see an unexpected 0.23% change for the serial compiler, so this could use a perf run to see if that reproduces.
cc `@SparrowLii`
Ensure that THIR unsafety check is done before stealing it
This ensures that THIR unsafety check is done before stealing it by running it on the typeck root instead of on a closure, which does nothing.
Fixes https://github.com/rust-lang/rust/issues/111520
```
error[E0596]: cannot borrow `*test` as mutable, as it is behind a `&` reference
--> $DIR/suggest-mut-iterator.rs:22:9
|
LL | for test in &tests {
| ------ this iterator yields `&` references
LL | test.add(2);
| ^^^^ `test` is a `&` reference, so the data it refers to cannot be borrowed as mutable
|
help: use a mutable iterator instead
|
LL | for test in &mut tests {
| +++
```
Address #114311.
This option tells LLVM to emit relaxable relocation types
R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX/R_386_GOT32X in applicable cases. True
matches Clang's CMake default since 2020-08 [1] and latest LLVM default[2].
This also works around a GNU ld<2.41 issue[3] when using
general-dynamic/local-dynamic TLS models in `-Z plt=no` mode with latest LLVM.
[1]: c41a18cf61
[2]: 2aedfdd9b8
[3]: https://sourceware.org/bugzilla/show_bug.cgi?id=24784
ArchiveWrapper: handle LLVM API update
In llvm/llvm-project@f740bcb370 a boolean parameter changed to an enum.
r? ``@nikic``
``@rustbot`` label: +llvm-main
Add support for `ptr::write`s for the `invalid_reference_casting` lint
This PR adds support for `ptr::write` and others for the `invalid_reference_casting` lint.
Detecting instances where instead of using the deref (`*`) operator to assign someone uses `ptr::write`, `ptr::write_unaligned` or `ptr::write_volatile`.
```rust
let data_len = 5u64;
std::ptr::write(
std::mem::transmute::<*const u64, *mut u64>(&data_len),
new_data_len,
);
```
r? ``@est31``
Don't do intra-pass validation on MIR shims
Fixes#114375
In the test that was committed, we end up generating the drop shim for `struct Foo` that looks like:
```
fn std::ptr::drop_in_place(_1: *mut Foo) -> () {
let mut _0: ();
bb0: {
goto -> bb5;
}
bb1: {
return;
}
bb2 (cleanup): {
resume;
}
bb3: {
goto -> bb1;
}
bb4 (cleanup): {
drop(((*_1).0: foo::WrapperWithDrop<()>)) -> [return: bb2, unwind terminate];
}
bb5: {
drop(((*_1).0: foo::WrapperWithDrop<()>)) -> [return: bb3, unwind: bb2];
}
}
```
In `bb4` and `bb5`, we assert that `(*_1).0` has type `WrapperWithDrop<()>`. However, In a user-facing param env, the type is actually `WrapperWithDrop<Tait>`. These types are not equal in a user-facing param-env (and can't be made equal even if we use `DefiningAnchor::Bubble`, since it's a non-local TAIT).
Use the same DISubprogram for each instance of the same inlined function within a caller
# Issue Details:
The call to `panic` within a function like `Option::unwrap` is translated to LLVM as a `tail call` (as it will never return), when multiple calls to the same function like this is inlined LLVM will notice the common `tail call` block (i.e., loading the same panic string + location info and then calling `panic`) and merge them together.
When merging these instructions together, LLVM will also attempt to merge the debug locations as well, but this fails (i.e., debug info is dropped) as Rust emits a new `DISubprogram` at each inline site thus LLVM doesn't recognize that these are actually the same function and so thinks that there isn't a common debug location.
As an example of this when building for x86_64 Windows (note the lack of `.cv_loc` before the call to `panic`, thus it will be attributed to the same line at the `addq` instruction):
```
.cv_loc 0 1 23 0 # src\lib.rs:23:0
addq $40, %rsp
retq
leaq .Lalloc_f570dea0a53168780ce9a91e67646421(%rip), %rcx
leaq .Lalloc_629ace53b7e5b76aaa810d549cc84ea3(%rip), %r8
movl $43, %edx
callq _ZN4core9panicking5panic17h12e60b9063f6dee8E
int3
```
# Fix Details:
Cache the `DISubprogram` emitted for each inlined function instance within a caller so that this can be reused if that instance is encountered again, this also requires caching the `DILexicalBlock` and `DIVariable` objects to avoid creating duplicates.
After this change the above assembly now looks like:
```
.cv_loc 0 1 23 0 # src\lib.rs:23:0
addq $40, %rsp
retq
.cv_inline_site_id 5 within 0 inlined_at 1 0 0
.cv_inline_site_id 6 within 5 inlined_at 1 12 0
.cv_loc 6 2 935 0 # library\core\src\option.rs:935:0
leaq .Lalloc_5f55955de67e57c79064b537689facea(%rip), %rcx
leaq .Lalloc_e741d4de8cb5801e1fd7a6c6795c1559(%rip), %r8
movl $43, %edx
callq _ZN4core9panicking5panic17hde1558f32d5b1c04E
int3
```
Add disclaimer on size assertion macro
Sometimes people are inspired by rustc to add size assertions to their code and copy the macro. This is bad because it causes hard build errors. rustc happens to be special where it makes this okay.
For example, see #115028 (not sure whether they were directly inspired by this function), but I think I've also seen other cases.
Warn on elided lifetimes in associated constants (`ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT`)
Elided lifetimes in associated constants (in impls) erroneously resolve to fresh lifetime parameters on the impl since #97313. This is not correct behavior (see #38831).
I originally opened #114716 to fix this, but given the time that has passed, the crater results seem pretty bad: https://github.com/rust-lang/rust/pull/114716#issuecomment-1682091952
This PR alternatively implements a lint against this behavior, and I'm hoping to bump this to deny in a few versions.
Redefine the pluralize macro's arm
Redefine the unintuitive pluralize macro's arm because of the negation. The initial code starts with check if count is not 1, which is confusing and unintuitive.
The arm shoud start with checking,
- if "count" `is 1` then, append `""` (empty string) - indicate as singular
- Then check if "count" `is not 1` (more than 1), append `"s"` - indicate as plural
Before:
```rs
// This arm is abit confusing since it start with checking, if "count" is more than 1, append "s".
($x:expr) => {
if $x != 1 { "s" } else { "" }
};
```
After:
```rs
// Pluralize based on count (e.g., apples)
($x:expr) => {
if $x == 1 { "" } else { "s" }
};
```
Coverage statements in MIR are heavily tied to internal details of the coverage
implementation that are likely to change, and are unlikely to be useful to
third-party tools for the foreseeable future.
Sometimes people are inspired by rustc to add size assertions to their
code and copy the macro. This is bad because it causes hard build
errors. rustc happens to be special where it makes this okay.
As of Xcode 15 Apple's linker has become a bit more strict about the
warnings it produces. One of those new warnings requires all valid
Mach-O object files in an archive to have a LC_BUILD_VERSION load
command:
```
ld: warning: no platform load command found in 'ARCHIVE[arm64][2106](lib.rmeta)', assuming: iOS-simulator
```
This was already being done for Mac Catalyst so this change expands this
logic to include it for all Apple platforms. I filed this behavior
change as FB12546320 and was told it was the new intentional behavior.
coverage: Give the instrumentor its own counter type, separate from MIR
Within the MIR representation of coverage data, `CoverageKind` is an important part of `StatementKind::Coverage`, but the `InstrumentCoverage` pass also uses it heavily as an internal data structure. This means that any change to `CoverageKind` also needs to update all of the internal parts of `InstrumentCoverage` that manipulate it directly, making the MIR representation difficult to modify.
---
This change fixes that by giving the instrumentor its own `BcbCounter` type for internal use, which is then converted to a `CoverageKind` when injecting coverage information into MIR.
The main change is mostly mechanical, because the initial `BcbCounter` is drop-in compatible with `CoverageKind`, minus the unnecessary `CoverageKind::Unreachable` variant.
I've then removed the `function_source_hash` field from `BcbCounter::Counter`, as a small example of how the two types can now usefully differ from each other. Every counter in a MIR-level function should have the same source hash, so we can supply the hash during the conversion to `CoverageKind::Counter` instead.
---
*Background:* BCB stands for “basic coverage block”, which is a node in the simplified control-flow graph used by coverage instrumentation. The instrumentor pass uses the function's actual MIR control-flow graph to build a simplified BCB graph, then assigns coverage counters and counter expressions to various nodes/edges in that simplified graph, and then finally injects corresponding coverage information into the underlying MIR.
Fix a stack overflow with long else if chains
This fixes stack overflows when running the `issue-74564-if-expr-stack-overflow.rs` test with the parallel compiler.
Add MIR validation for unwind out from nounwind functions + fixes to make validation pass
`@Nilstrieb` This is the MIR validation you asked in https://github.com/rust-lang/rust/pull/112403#discussion_r1222739722.
Two passes need to be fixed to get the validation to pass:
* `RemoveNoopLandingPads` currently unconditionally introduce a resume block (even there is none to begin with!), changed to not do that
* Generator state transform introduces a `assert` which may unwind, and its drop elaboration also introduces many new `UnwindAction`s, so in this case run the AbortUnwindingCalls after the transformation.
I believe this PR should also fixRust-for-Linux/linux#1016, cc `@ojeda`
r? `@Nilstrieb`
custom_mir: change Call() terminator syntax to something more readable
I find our current syntax very hard to read -- I cannot even remember the order of arguments, and having the "next block" *before* the actual function call is very counter-intuitive IMO. So I suggest we use `Call(ret_val = function(v), next_block)` instead.
r? `@JakobDegen`
Ignore unexpected incr-comp session dirs
Clearly the code path can be hit without the presence of a compiler bug.
All it takes is mischief. See #71698.
Ignore problematic directories instead of ICE:ing. `continue`ing is
already done for problematic dirs in the code block above us.
Closes#71698.
With this fix, the output is this instead of ICE:
```
$ cargo +stage1 new gz-ice && cd gz-ice
$ cargo +stage1 build
$ find target -type f -exec gzip {} \;
$ cargo +stage1 run
Created binary (application) `gz-ice` package
Compiling gz-ice v0.1.0 (/tmp/gz-ice)
Finished dev [unoptimized + debuginfo] target(s) in 0.13s
gzip: target/debug/gz-ice has 1 other link -- unchanged
gzip: target/debug/deps/gz_ice-de919414dd9926b9 has 1 other link -- unchanged
Compiling gz-ice v0.1.0 (/tmp/gz-ice)
warning: failed to garbage collect invalid incremental compilation session directory `/tmp/gz-ice/target/debug/incremental/gz_ice-23qx9z9j9vghe/s-gnwd8daity-kp10sj.lock.gz`: Not a directory (os error 20)
warning: `gz-ice` (bin "gz-ice") generated 1 warning
Finished dev [unoptimized + debuginfo] target(s) in 0.13s
Running `target/debug/gz-ice`
Hello, world!
```
Avoid side-effects from `try_coerce` when suggesting borrowing LHS of cast
The name `try_coerce` is a bit misleading -- it has side-effects, so when it's used in diagnostics code, it sometimes causes spurious obligations to be registered which cause other errors to occur that really make no sense in context.
Addendum: let's just rename `try_coerce` to `coerce` -- the `try_` part doesn't really add much, imo.
Normalize return type of `deduce_future_output_from_obligations`
Fixes#114909
Also confirmed to fix#114727 manually
Now that we have weak/lazy type aliases, we need to normalize those in future signatures to ensure that `replace_opaque_types_with_inference_vars` actually sees TAITs behind them. This isn't needed in the new solver, but added a test to make sure it doesn't regress there either.
r? types cc `@oli-obk` (who's gone, worst case can delay this PR until he's back)
Fix ABI flags in RISC-V/LoongArch ELF file generated by rustc
Fix#114153
It turns out the current way to set these flags are completely wrong. In LLVM the target ABI is used instead of target features to determine these flags.
Not sure how to write a test though. Or maybe a test isn't necessary because this affects only those touching target json?
r? `@Nilstrieb`
This shows one small benefit of separating `BcbCounter` from `CoverageKind`.
The function source hash will be the same for all counters within a function,
so instead of passing it through `CoverageCounters` and storing it in every
counter, we can just supply it during the final conversion to `CoverageKind`.
rustdoc: Add lint `redundant_explicit_links`
Closes#87799.
- Lint warns by default
- Reworks link parser to cache original link's display text
r? `@jyn514`
Clearly the code path can be hit without the presence of a compiler bug.
All it takes is mischief. See 71698.
Ignore problematic directories instead of ICE:ing. `continue`ing is
already done for problematic dirs in the code block above us.
`Nonterminal`-related cleanups
In #114647 I am trying to remove `Nonterminal`. It has a number of preliminary cleanups that are worth merging even if #114647 doesn't merge, so let's do them in this PR.
r? `@petrochenkov`
Otherwise the file name generated for generator_drop will become
core.ptr-drop_in_place.[generator@<FILEPATH>_<NUMBERS>].generator_drop.0.mir
instead of main-{closure#0}.generator_drop.0.mir which breaks a mir-opt
test.
Replace the \01__gnu_mcount_nc to LLVM intrinsic for ARM
Current `-Zinstrument-mcount` for ARM32 use the `\01__gnu_mcount_nc` directly for its instrumentation function.
However, the LLVM does not use this mcount function directly, but it wraps it to intrinsic, `llvm.arm.gnu.eabi.mcount` and the transform pass also only handle the intrinsic.
As a result, current `-Zinstrument-mcount` not work on ARM32. Refer: https://github.com/namhyung/uftrace/issues/1764
This commit replaces the mcount name from native function to the LLVM intrinsic so that the transform pass can handle it.
[RFC-3086] Restrict the parsing of `count`
Fix#111904
The original RFC didn't mention the possibility of using `${count(t,)}` and such thing isn't very semantically accurate which can lead to confusion.
Normalize before checking if local is freeze in `deduced_param_attrs`
Not normalizing the local type eagerly results in possibly exponential amounts of normalization happening downstream in `is_freeze_raw`.
Fixes#113372
It's much more complicated than it needs to be, and it doesn't modify
the expression. We can do the `Result` handling outside of it, and
change it to just return a span.
Also fix an errant comma that makes the comment hard to read.
Speed up compilation of `type-system-chess`
[`type-system-chess`](https://github.com/rust-lang/rustc-perf/pull/1680) is an unusual program that implements a compile-time chess position solver in the trait system(!) This PR is about making it compile faster.
r? `@ghost`
Revert PR #114052 to fix invalid suggestion
This PR reverts https://github.com/rust-lang/rust/pull/114052 to fix the invalid suggestion produced by the PR.
Unfortunately the invalid suggestion cannot be improved from the current position where it's emitted since we lack enough information (is an assignment?, left or right?, ...) to be able to fix it here. Furthermore the previous wasn't wrong, just suboptimal, contrary to the current one which is just wrong.
Added a regression test and commented out some code instead of removing it so we can use it later.
Reopens https://github.com/rust-lang/rust/issues/114050
Fixes https://github.com/rust-lang/rust/issues/114925
Fix suggestion for attempting to define a string with single quotes
Currently attempting to compile `fn main() { let _ = '\\"'; }` will result in the following error message:
```
error: character literal may only contain one codepoint
--> src/main.rs:1:21
|
1 | fn main() { let _ = '\\"'; }
| ^^^^^
|
help: if you meant to write a `str` literal, use double quotes
|
1 | fn main() { let _ = "\\""; }
| ~~~~~
```
The suggestion is invalid as it fails to escape the `"`. This PR fixes the suggestion so that it now reads:
```
help: if you meant to write a `str` literal, use double quotes
|
1 | fn main() { let _ = "\\\""; }
| ~~~~~~
```
The relevant test is also updated to ensure that this does not regress in future.
Current `-Zinstrument-mcount` for ARM32 use the `\01__gnu_mcount_nc`
directly for its instrumentation function.
However, the LLVM does not use this mcount function directly, but it wraps
it to intrinsic, `llvm.arm.gnu.eabi.mcount` and the transform pass also
only handle the intrinsic.
As a result, current `-Zinstrument-mcount` not work on ARM32.
Refer: https://github.com/namhyung/uftrace/issues/1764
This commit replaces the mcount name from native function to the
LLVM intrinsic so that the transform pass can handle it.
Signed-off-by: ChoKyuWon <kyuwoncho18@gmail.com>
Remove conditional use of `Sharded` from query caches
`Sharded` is already a zero cost abstraction, so it shouldn't affect the performance of the single thread compiler if LLVM does its job.
r? `@cjgillot`
Only run MaybeInitializedPlaces dataflow once to elaborate drops
This pass allows forward dataflow analyses to modify the CFG depending on the dataflow state. This possibility is used for the `MaybeInitializedPlace` analysis in drop elaboration, to skip the dataflow effect of dead unwinds without having to compute dataflow twice.
Fix argument removal suggestion around macros
Fixes#112437.
Fixes#113866.
Helps with #114255.
The issue was that `span.find_ancestor_inside(outer)` could previously return a span with a different expansion context from `outer`.
This happens for example for the built-in macro `panic!`, which expands to another macro call of `panic_2021!` or `panic_2015!`. Because the call site of `panic_20xx!` has not associated source code, its span currently points to the call site of `panic!` instead.
Something similar also happens items that get desugared in AST->HIR lowering. For example, `for` loops get two spans: One "inner" span that has the `.desugaring_kind()` kind set to `DesugaringKind::ForLoop` and one "outer" span that does not. Similar to the macro situation, both of these spans point to the same source code, but have different expansion contexts.
This causes problems, because joining two spans with different expansion contexts will usually[^1] not actually join them together to avoid creating "spaghetti" spans that go from the macro definition to the macro call. For example, in the following snippet `full_span` might not actually contain the `adjusted_start` and `adjusted_end`. This caused the broken suggestion / debug ICE in the linked issues.
```rust
let adjusted_start = start.find_ancestor_inside(shared_ancestor);
let adjusted_end = end.find_ancestor_inside(shared_ancestor);
let full_span = adjusted_start.to(adjusted_end)
```
To fix the issue, this PR introduces a new method, `find_ancestor_inside_same_ctxt`, which combines the functionality of `find_ancestor_inside` and `find_ancestor_in_same_ctxt`: It finds an ancestor span that is contained within the parent *and* has the same syntax context, and is therefore safe to extend. This new method should probably be used everywhere, where the returned span is extended, but for now it is just used for the argument removal suggestion.
Additionally, this PR fixes a second issue where the function call itself is inside a macro but the arguments come from outside the macro. The test is added in the first commit to include stderr diff, so this is best reviewed commit by commit.
[^1]: If one expansion context is the root context and the other is not.
Don't add associated type bound for non-types
We had this fix for equality constraints (#99890), but for some reason not trait constraints 😅Fixes#114744
Point at return type when it influences non-first `match` arm
When encountering code like
```rust
fn foo() -> i32 {
match 0 {
1 => return 0,
2 => "",
_ => 1,
}
}
```
Point at the return type and not at the prior arm, as that arm has type `!` which isn't influencing the arm corresponding to arm `2`.
Fix#78124.
Deny `FnDef` in patterns
We can only see these via `const { .. }` patterns, which are unstable.
cc #76001 (tracking issue for inline const pats)
Fixes#114658Fixes#114659
Point out expectation even if we have `TypeError::RegionsInsufficientlyPolymorphic`
just a minor tweak, since saying "one type is more general than the other" kinda sucks if we don't actually point out two types.
Rollup of 10 pull requests
Successful merges:
- #114711 (Infer `Lld::No` linker hint when the linker stem is a generic compiler driver)
- #114772 (Add `{Local}ModDefId` to more strongly type DefIds`)
- #114800 (std: add some missing repr(transparent))
- #114820 (Add test for unknown_lints from another file.)
- #114825 (Upgrade std to gimli 0.28.0)
- #114827 (Only consider object candidates for object-safe dyn types in new solver)
- #114828 (Probe when assembling upcast candidates so they don't step on eachother's toes in new solver)
- #114829 (Separate `consider_unsize_to_dyn_candidate` from other unsize candidates)
- #114830 (Clean up some bad UI testing annotations)
- #114831 (Check projection args before substitution in new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
Separate `consider_unsize_to_dyn_candidate` from other unsize candidates
Move the unsize candidate assembly *just for* `T -> dyn Trait` out of `assemble_candidates_via_self_ty` so that we only consider it once, instead of for every normalization step of the self ty. This makes sure that we don't assemble several candidates that are equal modulo normalization when we really don't care about normalizing the self type of an `T: Unsize<dyn Trait>` goal anyways.
Fixesrust-lang/trait-system-refactor-initiative#57
r? lcnr
Probe when assembling upcast candidates so they don't step on eachother's toes in new solver
Lack of a probe causes one candidate to disqualify the other due to inference side-effects.
r? lcnr
Infer `Lld::No` linker hint when the linker stem is a generic compiler driver
This PR basically reverts the temporary solution in https://github.com/rust-lang/rust/pull/113631 to a more long-term solution.
r? ``@petrochenkov``
In [this comment](https://github.com/rust-lang/rust/pull/113631#issuecomment-1634598238), you had ideas about a long-term solution:
> I wonder what a good non-temporary solution for the inference would look like.
>
> * If the default is `(Cc::No, Lld::Yes)` (e.g. `rust-lld`)
>
> * and we switch to some specific platform compiler (e.g. `-C linker=arm-none-eabi-gcc`), should we change to `Lld::No`? Maybe yes?
> * and we switch to some non-default but generic compiler `-C linker=clang`? Then maybe not?
>
> * If the default is `(Cc::Yes, Lld::Yes)` (e.g. future x86_64 linux with default LLD)
>
> * and we switch to some specific platform compiler (e.g. `-C linker=arm-none-eabi-gcc`), should we change to `Lld::No`? Maybe yes?
> * and we switch to some non-default but generic compiler `-C linker=clang`? Then maybe not?
>
I believe that we should infer the `Lld::No` linker hint for any `-Clinker` override, and all the cases above:
- the linker drivers have their own defaults, so in my mind `-Clinker` is a signal to use its default linker / flavor, rather than ours or the target's. In the case of generic compilers, it's more likely than not going to be `Lld::No`. I would expect this to be the case in general, even when including platform-specific compilers.
- the guess will be wrong if the linker driver uses lld by default (and we also don't want to search for `-fuse-ld` link args), but will work in the more common cases. And the minority of other cases can fix the wrong guess by opting into the precise linker flavor.
- this also ensures backwards-compatibility: today, even on targets with an lld default and overriding the linker, rustc will not use lld. That includes `thumbv6m-none-eabi` where issue #113597 happened.
It looks like the simplest option, and the one with least churn: we maintain the current behavior in ambiguous cases.
I've tested that this works on #113597, as expected from the failure.
(I also have a no-std `run-make` test using a custom target json spec: basically simulating a future `x86_64-unknown-linux-gnu` using an lld flavor by default, to check that e.g. `-Clinker=clang` doesn't use lld. I could add that test to this PR, but IIUC such a custom target requires `cargo -Z build-std` and we have no tests depending on this cargo feature yet. Let me know if you want to add this test of the linker inference for such targets.)
What do you think ?
Use `unstable_target_features` when checking inline assembly
This is necessary to properly validate register classes even when the relevant target feature name is still unstable.
Switch to LLD as default linker for loongarch64-unknown-none*
The [LLD already supports LoongArch](6084ee7420), it's time to switch to LLD as default linker for `loongarch64-unknown-none*`.
Warn on inductive cycle in coherence leading to impls being considered not overlapping
This PR implements a `coinductive_overlap_in_coherence` lint (#114040), which warns users against cases where two impls are considered **not** to overlap during coherence due to an inductive cycle disproving one of the predicates after unifying the two impls.
Cases where this lint fires will become an overlap error if we ever move to coinduction, so I'd like to make this a warning to avoid having more crates take advantage of this behavior in the mean time. Also, since the new trait solver treats inductive cycles as ambiguity, not an error, this is a blocker for landing the new trait solver in coherence.
Couple of global state and driver refactors
* Remove some unused global mutable state
* Remove a couple of unnecessary queries (both driver and `TyCtxt` queries)
* Remove an unnecessary use of `FxIndexMap`
add a csky-unknown-linux-gnuabiv2 target
This is the rustc side changes to support csky based Linux target(`csky-unknown-linux-gnuabiv2`).
Tier 3 policy:
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
I pledge to do my best maintaining it.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
This `csky` section is the arch name and the `unknown-linux` section is the same as other linux target, and `gnuabiv2` is from the cross-compile toolchain of `gcc`
> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
I think the explanation in platform support doc is enough to make this aspect clear.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
It's using open source tools only.
> The target must not introduce license incompatibilities.
No new license
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Understood.
> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
There are no new dependencies/features required.
> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
As previously said it's using open source tools only.
> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
There are no such terms present/
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
I'm not the reviewer here.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
I'm not the reviewer here.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
It supports for std
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
I have added the documentation, and I think it's clear.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
Understood.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
Understood.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
I believe I didn't break any other target.
> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
I think there are no such problems in this PR.
When encountering code like
```rust
fn foo() -> i32 {
match 0 {
1 => return 0,
2 => "",
_ => 1,
}
}
```
Point at the return type and not at the prior arm, as that arm has type
`!` which isn't influencing the arm corresponding to arm `2`.
Fix#78124.
Remove unnecessary FIXME
Found this while browsing rustc, I traced it back to https://github.com/rust-lang/rust/pull/27893 when MIR first introduced, some time passed since then and I think this FIXME is no longer necessary.
fixed *const [type error] does not implement the Copy trait
Removes "error: arguments for inline assembly must be copyable" when moving an unknown type
Fixes: #113788
Make Const more useful in smir
Since https://github.com/rust-lang/rust/pull/114587 is merged, we can make use of what we built and make Const more useful by making it not `Opaque`
r? `@spastorino`
Select obligations before processing wf obligation in `compare_method_predicate_entailment`
We need to select obligations before processing the WF obligation for the `IMPLIED_BOUNDS_ENTAILMENT` lint, since it skips over type variables.
Fixes#114783
r? `@jackh726`
TAITs do not constrain generic params
Fixes#108425
Not sure if I should rework those two failing tests. I guess `tests/ui/type-alias-impl-trait/coherence.rs` could just have the type parameter removed from it? IDK what `tests/ui/type-alias-impl-trait/coherence_generalization.rs` is even testing, though.
r? `@aliemjay`
cc `@lcnr` `@oli-obk` (when he's back from 🌴)
coverage: Store BCB counter info externally, not directly in the BCB graph
When deciding how to instrument the underlying MIR for coverage, the `InstrumentCoverage` pass builds a simplified “Basic Counter Block” graph, and then allocates coverage counters/expressions to various nodes/edges in the BCB graph as necessary. Those counters/expressions are then injected into the function's MIR.
The awkward thing here is that the code for doing this needs `&mut` access to the graph, in order to associate coverage info with individual nodes, even though it isn't making any structural changes to the graph itself. That makes it harder to understand and modify the instrumentation code.
In addition, the graph alone can't hold all the information that is needed. There ends up being an extra vector of “intermediate expressions” that needs to be passed around separately anyway.
---
This PR simplifies things by instead storing all of that temporary coverage information in a number of side-tables inside `CoverageCounters`.
This makes it easier to see all of the information produced by the make-counters step, and how it is used by the inject-into-mir step.
---
Looking at the combined changes is possible, but I recommend reviewing the commits individually, because the big changes are mostly independent of each other (despite being conceptually related).
Extract a create_wrapper_function for use in allocator shim writing
This deduplicates some logic and makes it easier to follow what wrappers are produced. In the future it may allow moving the code to determine which wrappers to create to cg_ssa.
All of them are not exported from rustc_interface and used only during
global_ctxt(). Inlining them makes it easier to follow the order of
queries and slightly reduces line count.
Also consider `mem::transmute` with the `invalid_reference_casting` lint
This PR extend the `invalid_reference_casting` lint with regard to the `std::mem::transmute` function.
```
error: casting `&T` to `&mut T` is undefined behavior, even if the reference is unused, consider instead using an `UnsafeCell`
--> $DIR/reference_casting.rs:27:16
|
LL | let _num = &mut *std::mem::transmute::<_, *mut i32>(&num);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
*I encourage anyone reviewing this PR to do so [without whitespaces](https://github.blog/2011-10-21-github-secrets/#whitespace).*
rustc: Move `features` from `Session` to `GlobalCtxt`
Removes one more piece of mutable state.
Follow up to #114622.
The rule I used for passing feature in function signatures:
- if a crate already depends on `rustc_middle`, then `Session` is replaced with `TyCtxt`
- otherwise session and features are passed as a pair `sess: &Session, features: &Features`
The code in `rustc_lint` is ultimately used for implementing a trait from `rustc_expand`, so it also doesn't use tcx despite the dependency on `rustc_middle`.
normalize in `trait_ref_is_knowable` in new solver
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/51
Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into:
- applicable without normalizing self type
- applicable for aliases, even if they can be normalized
- applicable for stuff which cannot get normalized further
I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`.
r? `@compiler-errors`
Storing coverage counter information in `CoverageCounters` has a few advantages
over storing it directly inside BCB graph nodes:
- The graph doesn't need to be mutable when making the counters, making it
easier to see that the graph itself is not modified during this step.
- All of the counter data is clearly visible in one place.
- It becomes possible to use a representation that doesn't correspond 1:1 to
graph nodes, e.g. storing all the edge counters in a single hashmap instead of
several.
remove builtin `Copy` and `Clone` impl for float and int infer
it's only change is whether `{integer}: Copy` is ambiguous, this has the following properties
- these goals get proven earlier, potentially resulting in slightly better perf
- it causes inconsistent behavior and ICE if there do not exist impls for all integers, causing issues when using `#[no_core]`
- it means `Clone` has user-facing differences from other traits from `core` with the new solver because it can potentially guide inference there
- it's just very sus™ to have a builtin impl which applies during type inference but not afterwards
Rollup of 7 pull requests
Successful merges:
- #94455 (Partially stabilize `int_roundings`)
- #114132 (Better Debug for Vars and VarsOs)
- #114584 (E0277 nolonger points at phantom `.await`)
- #114667 (Record binder for bare trait object in LifetimeCollectVisitor)
- #114692 (downgrade `internal_features` to warn)
- #114703 (Cover ParamConst in smir)
- #114734 (Mark oli as "on vacation")
r? `@ghost`
`@rustbot` modify labels: rollup
Respect `#[expect]` the same way `#[allow]` is with the `dead_code` lint
This PR makes the `#[expect]` attribute being respected in the same way the `#[allow]` attribute is with the `dead_code` lint.
The fix is much more involved than I would have liked (and it's not because I didn't tried!), because the implementation took advantage of the fact that firing a lint in a allow context is a nop (for the user, as the lint is suppressed) to not fire-it at all.
And will it's fine for `#[allow]`, it definitively isn't for `#[expect]`, as the presence and absence of the lint is significant. So a big part of the PR is just adding the context information of whenever an item is on the worklist because of an `[allow]`/`#[expect]` or not.
Fixes https://github.com/rust-lang/rust/issues/114557
downgrade `internal_features` to warn
Not sure if this requires an FCP or whatever. By having the lint as deny I need to modify test cases when testing them outside of the test suite as the test suite implicitly allows the lint. This takes maybe 10 to 20 seconds per test, but given just how frequently I end up copying tests to different repos it's a significant annoyance.
r? `@Nilstrieb`
make `typeid::typeid_itanium_cxx_abi::transform_ty` evaluate length in array types
the ICE in https://github.com/rust-lang/rust/issues/114275 was caused by `transform_ty`
in compiler/rustc_symbol_mangling/src/typeid/typeid_itanium_cxx_abi.rs encountering an unevaluated const, while expecting it to already be evaluated.
Rollup of 7 pull requests
Successful merges:
- #114599 (Add impl trait declarations to SMIR)
- #114622 (rustc: Move `crate_types` and `stable_crate_id` from `Session` to `GlobalCtxt`)
- #114662 (Unlock trailing where-clauses for lazy type aliases)
- #114693 (Remove myself from the review rotation)
- #114694 (make the provisional cache slightly less broken)
- #114705 (Add spastorino to mailmap)
- #114712 (Fix a couple of bad comments)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix a couple of bad comments
A couple of nits I saw. Sorry, this really should be folded into some other PR of mine, but I will literally forget if I don't put these up now.
make the provisional cache slightly less broken
It is still broken for the following cycles:
```mermaid
graph LR
R["R: coinductive"] --> A["A: inductive"]
R --> B["B: coinductive"]
A --> B
B --> R
```
the `R -> A -> B -> R` cycle should be considered to not hold, as it is mixed, but because we first put `B` into the cache from the `R -> B -> R` cycle which is coinductive, it does hold.
This issue will also affect our new coinduction approach. Longterm cycles are coinductive as long as one step goes through an impl where-clause, see f4fc5bae36/crates/formality-prove/src/prove/prove_wc.rs (L51-L62). Here we would first have a fully inductive cycle `R -> B -> R` which is then entered by a cycle with a coinductive step `R -> A -coinductive-> B -> R`.
I don't know how to soundly implement a provisional cache for goals not on the stack without tracking all cycles the goal was involved in and whether they were inductive or not. We could then only use goals from the cache if the *inductivity?* of every cycle remained the same. This is a mess to implement. I therefore want to rip out the provisional cache entirely, but will wait with this until I talked about it with `@nikomatsakis.`
r? `@compiler-errors`
Unlock trailing where-clauses for lazy type aliases
Allows trailing where-clauses on lazy type aliases and forbids[^1] leading ones.
Completes #89122 (see section *Top-level type aliases*).
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
[^1]: This is absolutely fine since lazy type aliases are only meant to be stabilized as part of a new edition.
coverage: Don't convert filename/symbol strings to `CString` for FFI
LLVM APIs are usually perfectly happy to accept pointer/length strings, as long as we supply a suitable length value when creating a `StringRef` or `std::string`.
This lets us avoid quite a few intermediate `CString` copies during coverage codegen. It also lets us use an `IndexSet<Symbol>` (instead of an `IndexSet<CString>`) when building the deduplicated filename table.
Remove redundant calls to `resolve_vars_with_obligations`
I've been auditing the calls to `resolve_vars_with_obligations` for the new solver, and have found a few that have no effect on diagnostics. Let's just remove 'em.
Also remove a redundant `resolve_vars_with_obligations_and_mutate_fulfillment` call.
r? ``@lcnr``
`Expr::can_have_side_effects()` is incorrect for struct/enum/array/tuple literals
It would return 'false' unless *all* sub-expressions had side effects. This would easily allow side effects to slip through, and also wrongly label empty literals as having side effects. Add some tests for the last point
The function is only used for simple lints and error messages, so not a serious bug.
this ICE was caused by `transform_ty`
in compiler/rustc_symbol_mangling/src/typeid/typeid_itanium_cxx_abi.rs
encountering an unevaluated const, while expecting it to already be evaluated.
add a regression test
Update tests/ui/sanitize/issue-114275-cfi-const-expr-in-arry-len.rs
Co-authored-by: Michael Goulet <michael@errs.io>
Update tests/ui/sanitize/issue-114275-cfi-const-expr-in-arry-len.rs
Co-authored-by: Michael Goulet <michael@errs.io>
fix test compiling for targets with -crt-static and failing
this was causign https://github.com/rust-lang/rust/pull/114686 to fail
Rollup of 6 pull requests
Successful merges:
- #110435 (rustdoc-json: Add test for field ordering.)
- #111891 (feat: `riscv-interrupt-{m,s}` calling conventions)
- #114377 (test_get_dbpath_for_term(): handle non-utf8 paths (fix FIXME))
- #114469 (Detect method not found on arbitrary self type with different mutability)
- #114587 (Convert Const to Allocation in smir)
- #114670 (Don't use `type_of` to determine if item has intrinsic shim)
Failed merges:
- #114599 (Add impl trait declarations to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't use `type_of` to determine if item has intrinsic shim
When we're calling `resolve_instance` on an inline const, we were previously looking at the `type_of` for that const, seeing that it was an `extern "intrinsic"` fn def, and treating it as if we were computing the instance of that intrinsic itself. This is incorrect.
Instead, we should be using the def-id of the item we're computing to determine if it's an intrinsic.
Fixes#114660
Detect method not found on arbitrary self type with different mutability
```
error[E0599]: no method named `x` found for struct `Pin<&S>` in the current scope
--> $DIR/arbitrary_self_type_mut_difference.rs:11:18
|
LL | Pin::new(&S).x();
| ^ help: there is a method with a similar name: `y`
|
note: method is available for `Pin<&mut S>`
--> $DIR/arbitrary_self_type_mut_difference.rs:6:5
|
LL | fn x(self: Pin<&mut Self>) {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Related to #57994, as one of the presented cases can lead to code like this.
feat: `riscv-interrupt-{m,s}` calling conventions
Similar to prior support added for the mips430, avr, and x86 targets this change implements the rough equivalent of clang's [`__attribute__((interrupt))`][clang-attr] for riscv targets, enabling e.g.
```rust
static mut CNT: usize = 0;
pub extern "riscv-interrupt-m" fn isr_m() {
unsafe {
CNT += 1;
}
}
```
to produce highly effective assembly like:
```asm
pub extern "riscv-interrupt-m" fn isr_m() {
420003a0: 1141 addi sp,sp,-16
unsafe {
CNT += 1;
420003a2: c62a sw a0,12(sp)
420003a4: c42e sw a1,8(sp)
420003a6: 3fc80537 lui a0,0x3fc80
420003aa: 63c52583 lw a1,1596(a0) # 3fc8063c <_ZN12esp_riscv_rt3CNT17hcec3e3a214887d53E.0>
420003ae: 0585 addi a1,a1,1
420003b0: 62b52e23 sw a1,1596(a0)
}
}
420003b4: 4532 lw a0,12(sp)
420003b6: 45a2 lw a1,8(sp)
420003b8: 0141 addi sp,sp,16
420003ba: 30200073 mret
```
(disassembly via `riscv64-unknown-elf-objdump -C -S --disassemble ./esp32c3-hal/target/riscv32imc-unknown-none-elf/release/examples/gpio_interrupt`)
This outcome is superior to hand-coded interrupt routines which, lacking visibility into any non-assembly body of the interrupt handler, have to be very conservative and save the [entire CPU state to the stack frame][full-frame-save]. By instead asking LLVM to only save the registers that it uses, we defer the decision to the tool with the best context: it can more accurately account for the cost of spills if it knows that every additional register used is already at the cost of an implicit spill.
At the LLVM level, this is apparently [implemented by] marking every register as "[callee-save]," matching the semantics of an interrupt handler nicely (it has to leave the CPU state just as it found it after its `{m|s}ret`).
This approach is not suitable for every interrupt handler, as it makes no attempt to e.g. save the state in a user-accessible stack frame. For a full discussion of those challenges and tradeoffs, please refer to [the interrupt calling conventions RFC][rfc].
Inside rustc, this implementation differs from prior art because LLVM does not expose the "all-saved" function flavor as a calling convention directly, instead preferring to use an attribute that allows for differentiating between "machine-mode" and "superivsor-mode" interrupts.
Finally, some effort has been made to guide those who may not yet be aware of the differences between machine-mode and supervisor-mode interrupts as to why no `riscv-interrupt` calling convention is exposed through rustc, and similarly for why `riscv-interrupt-u` makes no appearance (as it would complicate future LLVM upgrades).
[clang-attr]: https://clang.llvm.org/docs/AttributeReference.html#interrupt-risc-v
[full-frame-save]: 9281af2ecf/src/lib.rs (L440-L469)
[implemented by]: b7fb2a3fec/llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp (L61-L67)
[callee-save]: 973f1fe7a8/llvm/lib/Target/RISCV/RISCVCallingConv.td (L30-L37)
[rfc]: https://github.com/rust-lang/rfcs/pull/3246
fix: not insert missing lifetime for `ConstParamTy`
Fixes#113462
We should ignore the missing lifetime, as it's illegal to include a lifetime in a const param.
r? ``@compiler-errors``
These new interrupt calling conventions are not themselves stabilized,
but there are other unstable calling conventions present in the SMIR
mapping (e.g. AVR interrupts) and the mapping appears to be "complete"
so far, with no obvious way to represent unstable conventions separately
from the stable ones.
Similar to prior support added for the mips430, avr, and x86 targets
this change implements the rough equivalent of clang's
[`__attribute__((interrupt))`][clang-attr] for riscv targets, enabling
e.g.
```rust
static mut CNT: usize = 0;
pub extern "riscv-interrupt-m" fn isr_m() {
unsafe {
CNT += 1;
}
}
```
to produce highly effective assembly like:
```asm
pub extern "riscv-interrupt-m" fn isr_m() {
420003a0: 1141 addi sp,sp,-16
unsafe {
CNT += 1;
420003a2: c62a sw a0,12(sp)
420003a4: c42e sw a1,8(sp)
420003a6: 3fc80537 lui a0,0x3fc80
420003aa: 63c52583 lw a1,1596(a0) # 3fc8063c <_ZN12esp_riscv_rt3CNT17hcec3e3a214887d53E.0>
420003ae: 0585 addi a1,a1,1
420003b0: 62b52e23 sw a1,1596(a0)
}
}
420003b4: 4532 lw a0,12(sp)
420003b6: 45a2 lw a1,8(sp)
420003b8: 0141 addi sp,sp,16
420003ba: 30200073 mret
```
(disassembly via `riscv64-unknown-elf-objdump -C -S --disassemble ./esp32c3-hal/target/riscv32imc-unknown-none-elf/release/examples/gpio_interrupt`)
This outcome is superior to hand-coded interrupt routines which, lacking
visibility into any non-assembly body of the interrupt handler, have to
be very conservative and save the [entire CPU state to the stack
frame][full-frame-save]. By instead asking LLVM to only save the
registers that it uses, we defer the decision to the tool with the best
context: it can more accurately account for the cost of spills if it
knows that every additional register used is already at the cost of an
implicit spill.
At the LLVM level, this is apparently [implemented by] marking every
register as "[callee-save]," matching the semantics of an interrupt
handler nicely (it has to leave the CPU state just as it found it after
its `{m|s}ret`).
This approach is not suitable for every interrupt handler, as it makes
no attempt to e.g. save the state in a user-accessible stack frame. For
a full discussion of those challenges and tradeoffs, please refer to
[the interrupt calling conventions RFC][rfc].
Inside rustc, this implementation differs from prior art because LLVM
does not expose the "all-saved" function flavor as a calling convention
directly, instead preferring to use an attribute that allows for
differentiating between "machine-mode" and "superivsor-mode" interrupts.
Finally, some effort has been made to guide those who may not yet be
aware of the differences between machine-mode and supervisor-mode
interrupts as to why no `riscv-interrupt` calling convention is exposed
through rustc, and similarly for why `riscv-interrupt-u` makes no
appearance (as it would complicate future LLVM upgrades).
[clang-attr]: https://clang.llvm.org/docs/AttributeReference.html#interrupt-risc-v
[full-frame-save]: 9281af2ecf/src/lib.rs (L440-L469)
[implemented by]: b7fb2a3fec/llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp (L61-L67)
[callee-save]: 973f1fe7a8/llvm/lib/Target/RISCV/RISCVCallingConv.td (L30-L37)
[rfc]: https://github.com/rust-lang/rfcs/pull/3246
Restrict linker version script of proc-macro crates to just its two symbols
Restrict linker version script of proc-macro crates to just the two symbols of each proc-macro crate.
The main known effect of doing this is to stop including `#[no_mangle]` symbols in the linker version script.
Background:
The combination of a proc-macro crate with an import of another crate that itself exports a no_mangle function was broken for a period of time, because:
* In PR #99944 we stopped exporting no_mangle symbols from proc-macro crates; proc-macro crates have a very limited interface and are meant to be treated as a blackbox to everything except rustc itself. However: he constructed linker version script still referred to them, but resolving that discrepancy was left as a FIXME in the code, tagged with issue #99978.
* In PR #108017 we started telling the linker to check (via the`--no-undefined-version` linker invocation flag) that every symbol referenced in the "linker version script" is provided as linker input. So the unresolved discrepancy from #99978 started surfacing as a compile-time error (e.g. #111888).
Fix#111888Fix#99978.
Allowing re-implementation of mir_drops_elaborated query
For our use case of the rust compiler interface (a rust verifier called [Prusti](https://github.com/viperproject/prusti-dev/)), it would be extremely useful if we were able to "copy" the implementation of the `mir_drops_elaborated_and_const_checked` query to override it. This would mean that the following items would need to be made public:
>6d55184d05/compiler/rustc_mir_transform/src/lib.rs (L434)
>6d55184d05/compiler/rustc_mir_transform/src/inline.rs (L32)
(for the latter its module needs to be public or it needs to be re-exported)
To explain why (we think) this is necessary: I am currently working on a new feature, where we try to modify the generated executables by inserting certain additional checks, and potentially perform some optimizations based on verification results.
We are using the rust compiler interface and most of our goals can be achieved by overriding queries, in our case this is currently `mir_drops_elaborated_and_const_checked`.
However, at the moment this approach is somewhat limited. When overriding queries, we can call and steal the base-query and then modify the results before allocating and returning those.
The problem is that the verification works with a copy of `mir_promoted`. For the modifications we want to make to the mir, we would often want to rely on results of the verifier that refer to Locations in the `mir_promoted`. We can not modify the `mir_promoted` query using these results, because to run the verification we also need the results of `mir_borrowck()`, which means `mir_promoted` will already be constructed and cached.
The Locations we get from the verifier are also no longer usable to modify `mir_drops_elaborated_and_const_checked`, because the MIR obviously changes between those 2 phases. Tracking all Locations between the two seems to be pretty much unfeasible, and would also be extremely unstable.
By being able to override the query with its original implementation, we could modify the MIR before drop elaboration and the various other passes are performed.
I have spent quite a bit of time investigating other solutions, and didn't find any other way solving this problem. If I still missed something I would of course be happy to hear any suggestions that do not require exposing more internal compiler functionality. However, I think being able to re-implement certain queries could also benefit other use cases in the future, for example in PR #108328 one of the approaches discussed involved doing the same thing for `mir_promoted`.
update llvm-wrapper include to silence deprecation warning
Includes of `include/llvm/Support/Host.h` now emit a deprecated warning: `warning: This header is deprecated, please use llvm/TargetParser/Host.h`.
I don't believe we are using this include.
I don't believe we need to bump the `download-ci-llvm` stamp since these warnings are emitted while building the `llvm-wrapper`.
r? ```@nikic```
CFI: Fix error compiling core with LLVM CFI enabled
Fix#90546 by filtering out global value function pointer types from the type tests, and adding the LowerTypeTests pass to the rustc LTO optimization pipelines.
add aarch64-unknown-teeos target
TEEOS is a mini os run in TrustZone, for trusted/security apps. The libc of TEEOS is a part of musl. The kernel of TEEOS is micro kernel.
This MR is to add a target for teeos.
MRs for libc and rust-std are in progress.
Compiler team MCP: [MCP](https://github.com/rust-lang/compiler-team/issues/652)
Add hotness data to LLVM remarks
Slight improvement of https://github.com/rust-lang/rust/pull/113040. This makes sure that if PGO is used, remarks generated using `-Zremark-dir` will include the `Hotness` attribute.
r? `@tmiasko`
Make module inner and function run_analysis_to_runtime_passes in
rustc_mir_transform public to allow re-implementing the query from the
rust compiler interface.
Map RPIT duplicated lifetimes back to fn captured lifetimes
Use the [`lifetime_mapping`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.OpaqueTy.html#structfield.lifetime_mapping) to map an RPIT's captured lifetimes back to the early- or late-bound lifetimes from its parent function. We may be going thru several layers of mapping, since opaques can be nested, so we introduce `TyCtxt::map_rpit_lifetime_to_fn_lifetime` to loop through several opaques worth of mapping, and handle turning it into a `ty::Region` as well.
We can then use this instead of the identity substs for RPITs in `check_opaque_meets_bounds` to address #114285.
We can then also use `map_rpit_lifetime_to_fn_lifetime` to properly install bidirectional-outlives predicates for both RPITs and RPITITs. This addresses #114601.
I based this on #114574, but I don't actually know how much of that PR we still need, so some code may be redundant now... 🤷
---
Fixes#114597Fixes#114579Fixes#114285
Also fixes#114601, since it turns out we had other bugs with RPITITs and their duplicated lifetime params 😅.
Supersedes #114574
r? `@oli-obk`
[rustc_data_structures][base_n][perf] Remove unnecessary utf8 check.
Since all output characters taken from `BASE_64` are valid UTF8 chars there is no need to waste cycles on validation.
Even though it's obviously a perf win, I've also used a [benchmark](https://gist.github.com/ttsugriy/e1e63c07927d8f31e71695a9c617bbf3) on M1 MacBook Air with following results:
```
Running benches/base_n_benchmark.rs (target/release/deps/base_n_benchmark-825fe5895b5c2693)
push_str/old time: [14.670 µs 14.852 µs 15.074 µs]
Found 11 outliers among 100 measurements (11.00%)
4 (4.00%) high mild
7 (7.00%) high severe
push_str/new time: [12.573 µs 12.674 µs 12.801 µs]
Found 11 outliers among 100 measurements (11.00%)
7 (7.00%) high mild
4 (4.00%) high severe
```
rustc_interface: Dismantle `register_plugins` query
It did three independent things:
- Constructed `LintStore`
- Prepared incremental directories and dep graph
- Initialized some fields in `Session`
The `LintStore` construction (now `passes::create_lint_store`) is more or less left in place.
The incremental stuff is now moved into `fn dep_graph_future`.
This helps us to start loading the dep graph a bit earlier.
The `Session` field initialization is moved to tcx construction point.
Now that tcx is constructed early these fields don't even need to live in `Session`, they can live in tcx instead and be initialized at its creation (see the FIXME).
Three previously existing `rustc_interface` queries are de-querified (`register_plugins`, `dep_graph_future`, `dep_graph`) because they are only used locally in `fn global_ctxt` and their results don't need to be saved elsewhere.
On the other hand, `crate_types` and `stable_crate_id` are querified.
They are used from different places and their use is very similar to the existing `crate_name` query in this regard.
Structurally normalize weak and inherent in new solver
It seems pretty obvious to me that we should be normalizing weak and inherent aliases too, since they can always be normalized. This PR still leaves open the question of what to do with opaques, though 💀
**Also**, we need to structurally resolve the target of a coercion, for the UI test to work.
r? `@lcnr`
Store the laziness of type aliases in their `DefKind`
Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.
With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:
Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.
As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.
---
This fixes#114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
Remove arm crypto target feature
Follow-up to https://github.com/rust-lang/stdarch/pull/1407.
LLVM has moved away from a combined `crypto` feature on both aarch64 and arm, and we did the same on aarch64, but were deferred from doing the same on arm due to compatibility with older LLVM.
As the minimum LLVM version has increased, we can now remove this (unstable) target feature on arm.
r? `@Amanieu`
Warn when #[macro_export] is applied on decl macros
The existing code checks if `#[macro_export]` is being applied to an item other than a macro, and warns in that case, but fails to take into account macros 2.0/decl macros, despite the attribute having no effect on these macros.
This PR adds a special case for decl macros with the aforementioned attribute, so that the warning is a bit more precise. Instead of just saying "this attribute has no effect", hint towards the fact that decl macros get exported and resolved like regular items.
It also removes a `#[macro_export]` attribute which was applied on one of `core`'s decl macros.
- core: Remove #[macro_export] from `debug_assert_matches`
- check_attrs: Warn when #[macro_export] is used on macros 2.0
Avoid exporting __rust_alloc_error_handler_should_panic more than once.
Exporting `__rust_alloc_error_handler_should_panic` multiple times causes `ld.gold` to balk with: `error: version script assignment of to symbol __rust_alloc_error_handler_should_panic failed: symbol not defined`
Specifically this breaks builds of 1.70.0 and newer on DragonFly and YoctoProject with `ld.gold`. Builds with `ld.bfd` and `lld` should be unaffected.
http://errors.yoctoproject.org/Errors/Details/708194/
On native builds `llvm-config` picks up `zlib` and this gets pased into
the rust build tools, but on cross builds `llvm-config` is explicitly
ignored as it contains information for the host system and cannot be
trusted to be accurate for the target system.
Both DragonFly and Solaris contain `zlib` in the base system, so this is
both a safe assumption and required for a successful cross build unless
`zlib` support is disabled in LLVM.
This is more or less in the same vein as #75713 and #75655.
Fix#90546 by filtering out global value function pointer types from the
type tests, and adding the LowerTypeTests pass to the rustc LTO
optimization pipelines.
The compiler should emit a more specific error when the `#[macro_export]`
attribute is present on a decl macro, instead of silently ignoring it.
This commit adds the required error message in rustc_passes/messages.ftl,
as well as a note. A new variant is added to the `errors::MacroExport`
enum, specifically for the case where the attribute is added to a macro
2.0.
Rollup of 9 pull requests
Successful merges:
- #113568 (Fix spurious test failure with `panic=abort`)
- #114196 (Bubble up nested goals from equation in `predicates_for_object_candidate`)
- #114485 (Add trait decls to SMIR)
- #114495 (Set max_atomic_width for AVR to 16)
- #114496 (Set max_atomic_width for sparc-unknown-linux-gnu to 32)
- #114510 (llvm-wrapper: adapt for LLVM API changes)
- #114562 (stabilize abi_thiscall)
- #114570 ([miri][typo] Fix a typo in a vector_block comment.)
- #114573 (CI: do not hide error logs in a group)
r? `@ghost`
`@rustbot` modify labels: rollup
Bubble up nested goals from equation in `predicates_for_object_candidate`
This used to be needed for https://github.com/rust-lang/rust/pull/114036#discussion_r1273987510, but since it's no longer, I'm opening this as a separate PR. This also fixes one ICEing UI test: (`tests/ui/unboxed-closures/issue-53448.rs`)
r? `@lcnr`
