| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#146281 (Support `#[rustc_align_static]` inside `thread_local!`)
- rust-lang/rust#146535 (mbe: Implement `unsafe` attribute rules)
- rust-lang/rust#146585 (indexing: reword help)
- rust-lang/rust#147004 (Tweak handling of "struct like start" where a struct isn't supported)
- rust-lang/rust#147221 (Forbid `//@ compile-flags: -Cincremental=` in tests)
- rust-lang/rust#147225 (Don't enable shared memory by default with Wasm atomics)
- rust-lang/rust#147227 (implement `Box::take`)
- rust-lang/rust#147233 (Initialize llvm submodule if not already the case to run citool)
- rust-lang/rust#147236 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't enable shared memory by default with Wasm atomics
This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it.
### Context
Currently the atomics target features is unstable and can't be used without re-building Std with it (`-Zbuild-std`).
Enabling the atomics target feature automatically enables shared memory.
Shared memory is required to actually allow multi-threading.
However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs.
So it is very undesirable to enable shared memory by default for the majority of users.
While it is possible to use atomics without shared memory, the question remains what use-case this scenario has.
The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (rust-lang/rust#136382).
So alternatively, we might consider *not* enabling atomics by default even when LLVM does. In which case everything would remain the same.
---
This will break current Web multi-threading users. To address this they can add the following `RUSTFLAGS`:
```
-Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base
```
We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only `threads` target feature.
Addresses rust-lang/rust#77839.
r? ``@alexcrichton``
|
|
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a `match` expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like `match a { b:` would confuse the parser and think everything after `match` *must* be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
|
|
indexing: reword help
After looking at https://github.com/rust-lang/rust/issues/40850, I thought I'd try to improve wording around error E0608 a bit. Hopefully I've succeeded.
|
|
mbe: Implement `unsafe` attribute rules
This implements `unsafe attr` rules for declarative `macro_rules!` attributes, as specified in [RFC 3697](https://github.com/rust-lang/rfcs/pull/3697).
An invocation of an attribute that uses an `unsafe attr` rule requires the `unsafe(attr(...))` syntax.
An invocation of an attribute that uses an ordinary `attr` rule must *not* use the `unsafe(attr(...))` syntax.
`unsafe` is only supported on an `attr` rule, not any other kind of `macro_rules!` rule.
Tracking issue for `macro_rules!` attributes: https://github.com/rust-lang/rust/issues/143547
|
|
Split Bound index into Canonical and Bound
See [#t-types/trait-system-refactor > perf `async-closures/post-mono-higher-ranked-hang.rs`](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/perf.20.60async-closures.2Fpost-mono-higher-ranked-hang.2Ers.60/with/541535613) for context
Things compile and tests pass, but not sure if this actually solves the perf issue (edit: it does). Opening up this to do a perf (and maybe crater) run.
r? lcnr
|
|
Turn ProjectionElem::Subtype into CastKind::Subtype
I noticed that drop elaboration can't, in general, handle `ProjectionElem::SubType`. It creates a disjoint move path that overlaps with other move paths. (`Subslice` does too, and I'm working on a different PR to make that special case less fragile.) If its skipped and treated as the same move path as its parent then `MovePath.place` has multiple possible projections. (It would probably make sense to remove all `Subtype` projections for the canonical place but it doesn't make sense to have this special case for a problem that doesn't actually occur in real MIR.)
The only reason this doesn't break is that `Subtype` is always the sole projection of the local its applied to. For the same reason, it works fine as a `CastKind` so I figured that makes more sense than documenting and validating this hidden invariant.
cc rust-lang/rust#112651, rust-lang/rust#133258
r? Icnr (bc you've been the main person dealing with `Subtype` it looks like)
|
|
`LegacyAttr` here
`LegacyAttr` is only used for builtin attributes, and builtin attributes
have their safety checked by `check_attribute_safety`, so we don't need
to check `unsafety` here.
|
|
|
|
This simplifies subsequent initialization of enum variants.
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#146593 (Allow specifying multiple bounds for same associated item, except in trait objects)
- rust-lang/rust#147177 ([DebugInfo] Fix MSVC tuple child creation)
- rust-lang/rust#147195 (iter repeat: add tests for new count and last behavior)
- rust-lang/rust#147202 (Swap order of `resolve_coroutine_interiors` and `handle_opaque_type_uses`)
- rust-lang/rust#147204 (Refactor ArrayWindows to use a slice)
- rust-lang/rust#147219 (Add proper error handling for closure in impl)
- rust-lang/rust#147226 (include `outer_inclusive_binder` of pattern types)
- rust-lang/rust#147230 (Fix typo in 'unfulfilled_lint_expectation' to plural)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
include `outer_inclusive_binder` of pattern types
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/237
r? ```@lcnr```
|
|
Add proper error handling for closure in impl
Fixes https://github.com/rust-lang/rust/issues/147146
Fixes https://github.com/rust-lang/rust/issues/146620
Not sure if it can cause any regressions or anything, as for test also have no idea where to store this one
cc ```@theemathas```
r? compiler
|
|
Swap order of `resolve_coroutine_interiors` and `handle_opaque_type_uses`
r? ```@BoxyUwU```
if the comment says x should be last, it helps if it's actually last hehe :P
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/239
|
|
Allow specifying multiple bounds for same associated item, except in trait objects
Supersedes https://github.com/rust-lang/rust/pull/143146, fixes https://github.com/rust-lang/rust/issues/143143.
This PR proposes to stop enforcing E0719 in all contexts other than trait object types.
E0719 forbids constraining the same associated item twice within the same angle-bracket delimited associated item bound list (the `…` inside `T: Trait<…>`). For example, the following are forbidden:
| Forbidden | Working alternative |
|--------------------------------------------|--------------------------------------------------------------------|
| `T: Trait<Gat<u32> = u32, Gat<u64> = u64>` | `T: Trait<Gat<u32> = u32> + Trait<Gat<u64> = u64>` |
| `T: Iterator<Item = u32, Item = i32>` | `T: Iterator<Item = u32> + Iterator<Item = i32>` (trivially false) |
| `T: Iterator<Item = u32, Item = u32>` | `T: Iterator<Item = u32>` |
| `T: Iterator<Item: Send, Item: Sync>` | `T: Iterator<Item: Send + Sync>` |
| `T: Trait<ASSOC = 3, ASSOC = 4>` | `T: Trait<ASSOC = 3> + Trait<ASSOC = 4>` (trivially false) |
| `T: Trait<ASSOC = 3, ASSOC = 3>` | `T: Trait<ASSOC = 3>` |
With this PR, all those previously forbidden examples would start working, as well as their APIT and RPIT equivalents.
Types like `dyn Iterator<Item = u32, Item = u32>` will continue to be rejected, however. See https://github.com/rust-lang/rust/pull/143146#issuecomment-3274421752 for the reason why.
```@rustbot``` label T-lang T-types needs-fcp
|
|
|
|
|
|
|
|
|
|
|
|
Fix autodiff empty ret regression
closes https://github.com/rust-lang/rust/issues/147144
The two gsoc summer projects caused a bit of churn, which was to be expected, especially since we don't run autodiff in CI yet.
This adds a void return testcase that we should have had anyway, and fixes the regression.
r? `@Zalathar` (Just guessing since I've seen you in a few LLVM PRs and Oli is probably still busy. Feel free to reroll!)
|
|
remove outdated comment in (inner) `InferCtxt`
This comment seems to have stopped being relevant around 3 years ago after https://github.com/rust-lang/rust/commit/9f95c605f83bcf4c158ea4b3fd5a7abb825a4178. A map? what map? :P
r? `@lcnr`
|
|
add tests
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/105
the index test is for rust-lang/rust#146637
r? types
|
|
simplify setup_constraining_predicates, and note it is potentially cubic
|
|
Co-authored-by: beef <ent3rm4n@gmail.com>
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#143069 (Add fast-path for accessing the current thread id)
- rust-lang/rust#146518 (Improve the documentation around `ZERO_AR_DATE`)
- rust-lang/rust#146596 (Add a dummy codegen backend)
- rust-lang/rust#146617 (Don’t suggest foreign `doc(hidden)` types in "the following other types implement trait" diagnostics)
- rust-lang/rust#146635 (cg_llvm: Stop using `as_c_char_ptr` for coverage-related bindings)
- rust-lang/rust#147184 (Fix the bevy implied bounds hack for the next solver)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Fix the bevy implied bounds hack for the next solver
The diff is trivial, of course, and basically what you already suggested. Mostly dug around a bunch to learn. I hope this is roughly what you had in mind.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/236.
r? `@lcnr`
|
|
cg_llvm: Stop using `as_c_char_ptr` for coverage-related bindings
[As explained by a note in `ffi.rs`](https://github.com/rust-lang/rust/blob/8a1b39995e5b630c5872f5de5079f1f569bd5ac2/compiler/rustc_codegen_llvm/src/llvm/ffi.rs#L4-L11), passing strings and byte slices through FFI is more convenient if we take advantage of the fact that `*const c_uchar` and `*const c_char` have the same ABI.
Doing so avoids having to rely on a special helper function, since we can just call `as_ptr` instead.
(The same logic applies to every other binding that currently uses the `as_c_char_ptr` helper; I just haven't adjusted all of them yet.)
---
As a drive-by change, this PR also marks some coverage-related FFI bindings as `safe`.
|
|
Don’t suggest foreign `doc(hidden)` types in "the following other types implement trait" diagnostics
Fixes https://github.com/rust-lang/rust/issues/132024.
``@rustbot`` label A-diagnostics T-compiler
|
|
Add a dummy codegen backend
This allows building a rustc capable of running the frontend without any backend present. While this may not seem all that useful, it allows running the frontend of rustc to report errors or running miri to interpret a program without any backend present. This is useful when you are trying to say run miri in the browser as upstream LLVM can't be compiled for wasm yet. Or to run rustc itself in miri like I did a while ago and caught some UB.
|
|
Improve the documentation around `ZERO_AR_DATE`
In particular, document why we don't use the new `-reproducible` flag.
I went through [the source for Apple's old linker](https://github.com/apple-oss-distributions/ld64), and compared the versions with [the mapping to Xcode versions on Wikipedia](https://en.wikipedia.org/wiki/Xcode) to find the relevant Xcode versions for these features.
r? compiler
|
|
|
|
cg_llvm: Replace enum `MetadataType` with a list of `MetadataKindId` constants
The metadata kind ID values declared in `MetadataType` are not part of the LLVM-C API, and are not machine-checked. If a value that we use ever goes out of sync with LLVM, the resulting bugs could be difficult to track down. And the existing values lack any clear indication of what LLVM declarations they correspond to.
On top of that, we currently have another way of expressing metadata kind IDs in the form of `MetadataKindId`, which creates confusing inconsistency in LLVM bindings.
This PR therefore consolidates all usage of “fixed” metadata kind IDs into one list of `MetadataKindId` constants, which is backed by static assertions in our C++ code that match them up with named anonymous-enum variants in `llvm::LLVMContext`.
|
|
|
|
Rename various "concrete opaque type" things to say "hidden type"
r? lcnr
I've found "concrete opaque type" terminology to be somewhat confusing as in conversation and when explaining opaque type stuff to people I always just talk about things in terms of hidden types. Also the hidden types of opaques are very much not *concrete* in the same sense that a type without any generic parameters is concrete which is an unfortunate overlap in terminology.
I've tried to update comments to also stop referring to things as concrete opaque types but this is mostly best effort as it difficult to find all such cases amongst the massive amounts of uses of "concrete" or "hidden" across the whole compiler.
|
|
cmse: fix 'region variables should not be hashed'
tracking issue: https://github.com/rust-lang/rust/issues/81391
fixes https://github.com/rust-lang/rust/issues/131639
Some background: the `cmse-nonsecure-call` calling convention is used for a call from "secure" to "non-secure" code. To make sure that "non-secure" cannot read any secrets, restrictions are put on the signatures of functions with this calling convention: they can only use 4 arguments for passing arguments, and one register for passing a result. No arguments are passed via the stack, and all other registers are cleared before the call.
We check during `hir_ty_lowering` that the signature follows these rules. We do that by determining and then inspecting the layout of the type. That works well overall, but can run into asserts when the type itself is ill-formed. This PR fixes one such case.
I believe that the fix here, just erasing the regions, is the right shape, but there may be some nuance that I'm missing.
r? types
|
|
Point at fn bound that introduced lifetime obligation
The last note is new
```
error[E0597]: `c` does not live long enough
--> $DIR/without-precise-captures-we-are-powerless.rs:19:20
|
LL | fn simple<'a>(x: &'a i32) {
| -- lifetime `'a` defined here
...
LL | let c = async move || { println!("{}", *x); };
| - binding `c` declared here
LL | outlives::<'a>(c());
| ---------------^---
| | |
| | borrowed value does not live long enough
| argument requires that `c` is borrowed for `'a`
LL | outlives::<'a>(call_once(c));
LL | }
| - `c` dropped here while still borrowed
|
note: requirement that `c` is borrowed for `'a` introduced here
--> $DIR/without-precise-captures-we-are-powerless.rs:7:33
|
LL | fn outlives<'a>(_: impl Sized + 'a) {}
| ^^
```
When encountering a `ConstraintCategory::Predicate` in a funtion call, point at the `Span` for that `Predicate` to explain where the lifetime obligation originates from.
CC rust-lang/rust#55307.
|
|
Fix unuseful span in type error in some format_args!() invocations
Fixed https://github.com/rust-lang/rust/issues/140578.
r? ``@m-ou-se``
|
|
|
|
|
|
|
|
|
|
|
|
Make replacement suggestion `_` in type verbose
```
error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types
--> $DIR/in-signature.rs:6:21
|
LL | fn arr_fn() -> [u8; _] {
| ^ not allowed in type signatures
|
help: replace with the correct return type
|
LL - fn arr_fn() -> [u8; _] {
LL + fn arr_fn() -> [u8; 3] {
|
```
|
|
builtin `Fn`-trait impls: instantiate binder before the return type `Sized` check
fixes
- https://github.com/rust-lang/trait-system-refactor-initiative/issues/220
- https://github.com/rust-lang/trait-system-refactor-initiative/issues/204
r? `@BoxyUwU`
|
|
Skip cleanups on unsupported targets
This commit is an update to the `AbortUnwindingCalls` MIR pass in the compiler. Specifically a new boolean is added for "can this target possibly unwind" and if that's `false` then terminators are all adjusted to be unreachable/not present. The end result is that this fixes rust-lang/rust#140293 for wasm targets.
The motivation for this PR is that currently on WebAssembly targets the usage of the `C-unwind` ABI can lead LLVM to either (a) emit exception-handling instructions or (b) hit a LLVM-ICE-style codegen error. WebAssembly as a base instruction set does not support unwinding at all, and a later proposal to WebAssembly, the exception-handling proposal, was what enabled this. This means that the current intent of WebAssembly targets is that they maintain the baseline of "don't emit exception-handling instructions unless enabled". The commit here is intended to restore this behavior by skipping these instructions even when `C-unwind` is present.
Exception-handling is a relatively tricky and also murky topic in WebAssembly, however. There are two sets of instructions LLVM can emit for WebAssembly exceptions, Rust's Emscripten target supports exceptions, WASI targets do not, the LLVM flags to enable this are not always obvious, and additionally this all touches on "changing exception-handling behavior should be a target-level concern, not a feature". Effectively WebAssembly's exception-handling integration into Rust is not finalized at this time. The best idea at this time is that a parallel set of targets will eventually be added which support exceptions, but it's not clear if/when to do this. In the meantime the goal is to keep existing targets working while still enabling experimentation with exception-handling with `-Zbuild-std` and various permutations of LLVM flags.
To that extent this commit does not blanket disable these landing pads and cleanup routines for WebAssembly but instead checks to see if panic=unwind is enabled or if `+exception-handling` is enabled. Tests are updated here as well to account for this where, by default, using a `C-unwind` ABI won't affect Rust codegen at all. If `+exception-handling` is enabled, however, then Rust codegen will look like native platforms where exceptions are caught and the program aborts. More-or-less I've done my best to keep exceptions working on wasm where it's possible to have them work, but turned them off where they're not supposed to be emitted.
Closes rust-lang/rust#140293
|
|
Emit allocator attributes for allocator shim
This emits the same attributes we place on allocator declarations on the definitions in the allocator shim as well. This complements https://github.com/rust-lang/rust/pull/146766, which added the attribute for `#[global_allocator]` definitions. Emitting the attributes on the definitions ensures that they cannot be lost of the allocator shim participates in LTO.
See https://github.com/rust-lang/rust/issues/145995 for context, though that one was about `#[global_allocator]`. I'm not sure whether this can occur with the allocator shim as well or not, but better safe than sorry.
I'm not sure whether there is any good way to test this, as the allocator shim is not part of `--emit=llvm-ir`. I've verified this locally by inspecting the bitcode produced by `-C save-temps`.
r? ``@bjorn3``
|
|
Use MirPatch in simplify_branches.
This allows to avoid clearing the CFG cache if we don't perform any change.
r? ``@ghost`` for perf
|
