Suggest defining const parameter when appropriate
Helps a bit with #91119.
Following #105523's lead, I use placeholder `/* Type */` instead of `_` in the suggestion.
It should be easier for newcomers to parse.
`@rustbot` label A-diagnostics
r? diagnostics
Add tier 3 no_std x86 support for QNX Neutrino RTOS, version 7.0
This PR adds the target `i586-pc-nto-qnx700`, which targets QNX Neutrino RTOS version 7.0 on x86 32-bit targets.
cc: `@flba-eb` `@gh-tr`
This target falls under the umbrella of Tier 3 QNX Neutrino RTOS support documented in `nto-qnx.md` and previously started with #102701.
Make the "codegen" profile of `config.toml` download and build llvm from source.
The stated purpose of the codegen profile in config.toml is:
> `# These defaults are meant for contributors to the compiler who modify codegen or LLVM`
but `download-ci-llvm` must be set to be false for the llvm source to even be downloaded. This patch adds that in.
Also included: a small docs fix in `config.example.toml`
Enforce that `PointerLike` requires a pointer-like ABI
At least temporarily, let's ban coercing things that are pointer-sized and pointer-aligned but *not* `Abi::Scalar(..)` into `dyn*`. See: https://github.com/rust-lang/rust/pull/104694#discussion_r1142522073
This can be lifted in the future if we decie that we *want* to be able to coerce something `repr(C)` into a `dyn*`, but we'll have to figure out what to do with Miri and codegen...
r? compiler
Make elaboration generic over input
Combines all the `elaborate_*` family of functions into just one, which is an iterator over the same type that you pass in (e.g. elaborating `Predicate` gives `Predicate`s, elaborating `Obligation`s gives `Obligation`s, etc.)
Clippy Book Chapter Updates Reborn: Type Checking
This PR adds a new chapter to the book: "Type Checking", it hasn't changed a lot from the source mainly because there wasn't many reviews on it and I haven't see a lot of things that needed a change.
## Notes
- I have some doubts about the whole "`is_*` Usage" section, what do you think about it.
- For discussion about the whole project, please use the tracking issue for the project #10597 (It also contains a timeline, discussions, and more information)
changelog: Add a new "Type Checking" chapter to the book
r? `@flip1995`
Add ability to transmute (somewhat) with generic consts in arrays
Previously if the expression contained generic consts and did not have a directly equivalent type, transmuting the type in this way was forbidden, despite the two sizes being identical. Instead, we should be able to lazily tell if the two consts are identical, and if so allow them to be transmuted.
This is done by normalizing the forms of expressions into sorted order of multiplied terms, which is not generic over all expressions, but should handle most cases.
This allows for some _basic_ transmutations between types that are equivalent in size without requiring additional stack space at runtime.
I only see one other location at which `SizeSkeleton` is being used, and it checks for equality so this shouldn't affect anywhere else that I can tell.
See [this Stackoverflow post](https://stackoverflow.com/questions/73085012/transmute-nested-const-generic-array-rust) for what was previously necessary to convert between types. This PR makes converting nested `T -> [T; 1]` transmutes possible, and `[uB*2; N] -> [uB; N * 2]` possible as well.
I'm not sure whether this is something that would be wanted, and if it is it definitely should not be insta-stable, so I'd add a feature gate.
Receiver disconnection relies on the incorrect assumption that
`head.index != tail.index` implies that the channel is initialized (i.e
`head.block` and `tail.block` point to allocated blocks). However, it
can happen that `head.index != tail.index` and `head.block == null` at
the same time which leads to a segfault when a channel is dropped in
that state.
This can happen because initialization is performed in two steps. First,
the tail block is allocated and the `tail.block` is set. If that is
successful `head.block` is set to the same pointer. Importantly,
initialization is skipped if `tail.block` is not null.
Therefore we can have the following situation:
1. Thread A starts to send the first value of the channel, observes that
`tail.block` is null and begins initialization. It sets `tail.block`
to point to a newly allocated block and then gets preempted.
`head.block` is still null at this point.
2. Thread B starts to send the second value of the channel, observes
that `tail.block` *is not* null and proceeds with writing its value
in the allocated tail block and sets `tail.index` to 1.
3. Thread B drops the receiver of the channel which observes that
`head.index != tail.index` (0 and 1 respectively), therefore there
must be messages to drop. It starts traversing the linked list from
`head.block` which is still a null pointer, leading to a segfault.
This PR fixes this problem by waiting for initialization to complete
when `head.index != tail.index` and the `head.block` is still null. A
similar check exists in `start_recv` for similar reasons.
Fixes#110001
Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
Switched provisional evaluation cache map to FxIndexMap, and replaced map.drain_filter with map.retain
Switching ProvisionalEvaluationCache's map field from FxHashMap to FxIndexMap was previously blocked because doing so caused performance regressions that could be mitigated by the stabilization of drain_filter for FxIndexMap (#104212). However, the only use of drain_filter can be replaced with a retain, so I made the modification and put in a PR to see if this causes a performance regression as well.
This PR is part of a broader effort (#84447) of removing iteration through FxHashMaps, as the iteration order is unstable and can cause issues in incremental compilation.
This may be potentially useful for
- avoiding uses of `hir::ItemKind::Use`
- preserving documentation comments on all reexports
- preserving and checking stability/deprecation info on reexports
- all kinds of diagnostics
Temporarily remove myself from reviewers list
I'm going to be unable to review for the next few weeks, so I'm removing myself from the review queue. Once I'm back and able to review again, I'll add myself back to the list.
r? ``@wesleywiser``
rustdoc: clean up JS
* Stop checking `func` in `onEach`. It's always hard-coded right at the call site, so there's no point.
* Use the ternary operator in a few spots where it makes sense.
* No point in making `onEach` store `arr.length` in a variable if it's only used once anyway.
