Commit Graph

27054 Commits

Author SHA1 Message Date
bors
307c573d57 Auto merge of #114614 - RalfJung:offset-of-sanity, r=cjgillot
offset_of: guard against invalid use (with unsized fields)
2023-08-10 07:54:05 +00:00
bors
fd16988600 Auto merge of #114648 - compiler-errors:perf-114604, r=lqd
Only resolve target type in `try_coerce` in new solver

Only needed in new solver, seems to affect perf in old solver.

cc #114604/#114594
2023-08-10 02:00:30 +00:00
bors
832db2fcee Auto merge of #114673 - matthiaskrgr:rollup-9kroqpp, r=matthiaskrgr
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
2023-08-09 23:27:46 +00:00
Matthias Krüger
a87dda3b3d
Rollup merge of #114670 - compiler-errors:issue-114660, r=cjgillot
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
2023-08-09 23:00:00 +02:00
Matthias Krüger
bbc1109b79
Rollup merge of #114587 - ouz-a:smir_allocation, r=oli-obk
Convert Const to Allocation in smir

Continuation of previous pr https://github.com/rust-lang/rust/pull/114466

cc https://github.com/rust-lang/project-stable-mir/issues/15

r? `@oli-obk`
2023-08-09 23:00:00 +02:00
Matthias Krüger
90c0371ca9
Rollup merge of #114469 - estebank:arbitrary-self-types-mut-diff, r=davidtwco
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.
2023-08-09 22:59:59 +02:00
Matthias Krüger
7d78885a8e
Rollup merge of #111891 - rustbox:feat/riscv-isr-cconv, r=jackh726
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
2023-08-09 22:59:58 +02:00
Michael Goulet
d8e3986d42 Don't use type_of to determine if item has intrinsic shim 2023-08-09 20:00:38 +00:00
bjorn3
37751893cc Merge commit '8f9ac9c22d6594cf059d8e6c71d414cc5ccd7975' into sync_cg_clif-2023-08-09 2023-08-09 18:20:12 +00:00
ouz-a
8f1ea576b7 only allocate bytes within AllocRange 2023-08-09 21:05:03 +03:00
Michael Goulet
214d78daec Only resolve in new solver 2023-08-09 17:00:59 +00:00
Esteban Kuber
9de1a472b6 Suggest using Arc on !Send/!Sync types 2023-08-09 14:04:10 +00:00
ouz-a
c41339a52f Convert Const to Allocation in smir 2023-08-09 15:00:00 +03:00
Esteban Küber
843549e478 review comments 2023-08-09 10:28:53 +00:00
Matthias Krüger
41d26941d6
Rollup merge of #114606 - bvanjoi:fix-113462, r=compiler-errors
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``
2023-08-09 06:32:25 +02:00
Matthias Krüger
0c2f179901
Rollup merge of #114548 - fee1-dead-contrib:migrate-to-trans, r=davidtwco
Migrate a trait selection error to use diagnostic translation
2023-08-09 06:32:25 +02:00
Seth Pellegrino
d88ab223c5 fix: add RiscvInterrupt* cconv to smir
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.
2023-08-08 18:09:56 -07:00
Seth Pellegrino
897c7bb23b 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
2023-08-08 18:09:56 -07:00
bors
a946c1e017 Auto merge of #114470 - pnkfelix:dont-export-no-mangle-from-proc-macros-issue-99978, r=bjorn3
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 #111888
Fix #99978.
2023-08-09 00:38:00 +00:00
bors
e3590fccfb Auto merge of #114637 - matthiaskrgr:rollup-544y8p5, r=matthiaskrgr
Rollup of 11 pull requests

Successful merges:

 - #106425 (Make ExitStatus implement Default)
 - #113480 (add aarch64-unknown-teeos target)
 - #113586 (Mention style for new syntax in tracking issue template)
 - #113593 (CFI: Fix error compiling core with LLVM CFI enabled)
 - #114612 (update llvm-wrapper include to silence deprecation warning)
 - #114613 (Prevent constant rebuilds of `rustc-main` (and thus everything else))
 - #114615 (interpret: remove incomplete protection against invalid where clauses)
 - #114628 (Allowing re-implementation of mir_drops_elaborated query)
 - #114629 (tests: Uncomment now valid GAT code behind FIXME)
 - #114630 (Migrate GUI colors test to original CSS color format)
 - #114631 (add provisional cache test for new solver)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-08-08 22:00:40 +00:00
Matthias Krüger
acf3791c16
Rollup merge of #114628 - cedihegi:master, r=oli-obk
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`.
2023-08-08 21:44:46 +02:00
Matthias Krüger
5c5ae6c5f3
Rollup merge of #114615 - RalfJung:interpret-invalid-where, r=lcnr
interpret: remove incomplete protection against invalid where clauses

Cc https://github.com/rust-lang/rust/issues/97477, https://github.com/rust-lang/project-const-generics/issues/37

r? ``@lcnr``
2023-08-08 21:44:45 +02:00
Matthias Krüger
54a9c2cb2a
Rollup merge of #114612 - lqd:east-17-warning, r=nikic
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```
2023-08-08 21:44:44 +02:00
Matthias Krüger
c097e48082
Rollup merge of #113593 - rcvalle:rust-cfi-fix-90546, r=wesleywiser
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.
2023-08-08 21:44:43 +02:00
Matthias Krüger
088763643f
Rollup merge of #113480 - Sword-Destiny:master, r=petrochenkov
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)
2023-08-08 21:44:42 +02:00
bors
f88a8b71ce Auto merge of #114545 - fee1-dead-contrib:lower-impl-effect, r=oli-obk
correctly lower `impl const` to bind to host effect param

r? `@oli-obk`
2023-08-08 19:23:41 +00:00
bors
f525bb4e2a Auto merge of #114439 - Kobzol:remark-pgo-hotness, r=tmiasko
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`
2023-08-08 15:41:44 +00:00
cedihegi
0166092f87 Added comment on reason for method being public 2023-08-08 17:36:30 +02:00
cedihegi
15d408c6b0 Allow reimplementation of drops_elaborated query
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.
2023-08-08 16:30:43 +02:00
Jakub Beránek
9d417d7c86
Only enable hotness information when PGO is available 2023-08-08 15:36:55 +02:00
bors
bf62436bce Auto merge of #114602 - compiler-errors:rpit-outlives-sadness, r=oli-obk
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 #114597
Fixes #114579
Fixes #114285

Also fixes #114601, since it turns out we had other bugs with RPITITs and their duplicated lifetime params 😅.

Supersedes #114574

r? `@oli-obk`
2023-08-08 13:03:10 +00:00
Rémy Rakic
bcf7bfc9f4 remove 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`.
2023-08-08 10:48:20 +00:00
bors
617821ab32 Auto merge of #114339 - ttsugriy:unsafe-utf8, r=davidtwco
[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
```
2023-08-08 10:25:37 +00:00
Michael Goulet
ef2a611803 Simplify via map_rpit_lifetime_to_fn_lifetime 2023-08-08 09:39:42 +00:00
Oli Scherer
67703b9161 Stop using identity args for opaque type wf checks and instead load the args from the single use of a RPIT in its parent function's return type 2023-08-08 09:39:42 +00:00
Michael Goulet
420ee167a8 Install bidirectional outlives predicates for RPITITs (and RPITs) correctly 2023-08-08 09:39:42 +00:00
Ralf Jung
a7132bf387 interpret: remove incomplete protection against invalid where clauses 2023-08-08 10:35:22 +02:00
Ralf Jung
9215346d35 offset_of: guard against invalid use (with unsized fields) 2023-08-08 10:34:08 +02:00
bors
6d55184d05 Auto merge of #114520 - RalfJung:unsized-valtrees, r=oli-obk
simplify handling of valtrees for unsized types
2023-08-08 07:48:01 +00:00
bohan
078b942fef fix: not insert missing lifetime for ConstParamTy 2023-08-08 14:48:17 +08:00
bors
6742e2b185 Auto merge of #114578 - petrochenkov:noplugin, r=cjgillot
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.
2023-08-08 05:10:11 +00:00
Michael Goulet
8dcb8e0759 Unconditionally record lifetime mapping 2023-08-08 03:16:04 +00:00
Matthias Krüger
418b91a3d7
Rollup merge of #114594 - compiler-errors:new-solver-resolve-aliases, r=lcnr
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`
2023-08-08 03:30:56 +02:00
Matthias Krüger
3cd0a109a8
Rollup merge of #114566 - fmease:type-alias-laziness-is-crate-specific, r=oli-obk
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`
2023-08-08 03:30:56 +02:00
Matthias Krüger
28ee1a919e
Rollup merge of #114500 - taiki-e:arm-crypto, r=Amanieu
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`
2023-08-08 03:30:55 +02:00
Matthias Krüger
6f36f1ffbd
Rollup merge of #114497 - taiki-e:revert-riscv-atomic, r=Amanieu
Revert #98333 "Re-enable atomic loads and stores for all RISC-V targets"

This reverts #98333.

As said in https://github.com/rust-lang/rust/pull/98333#issuecomment-1666375293, `forced-atomics` target feature is also needed to enable atomic load/store on these targets (otherwise, libcalls are generated): https://godbolt.org/z/433qeG7vd

However, `forced-atomics` target feature is currently broken (https://github.com/rust-lang/rust/issues/114153), so AFAIK, there is currently no way to enable atomic load/store (via core::intrinsics) on these targets properly.

r? `@Amanieu`
2023-08-08 03:30:55 +02:00
Matthias Krüger
42cdc7df20
Rollup merge of #114413 - CohenArthur:warn-macro-export-decl-macros, r=cjgillot
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
2023-08-08 03:30:54 +02:00
Matthias Krüger
328e9785fb
Rollup merge of #114376 - inferiorhumanorgans:rustc-codegen-ssa-duplicate-export, r=wesleywiser
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/
2023-08-08 03:30:54 +02:00
Ramon de C Valle
f837c48f0d 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.
2023-08-07 15:59:15 -07:00
Arthur Cohen
bdf4e3de9c check_attrs: Warn when #[macro_export] is used on macros 2.0
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.
2023-08-07 21:14:28 +02:00