| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
doctest compilation
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #126118 (docs: Mention `spare_capacity_mut()` in `Vec::set_len`)
- #132830 (Rename `elem_offset` to `element_offset`)
- #133103 (Pass FnAbi to find_mir_or_eval_fn)
- #134321 (Hide `= _` as associated constant value inside impl blocks)
- #134518 (fix typos in the example code in the doc comments of `Ipv4Addr::from_bits()`, `Ipv6Addr::from_bits()` & `Ipv6Addr::to_bits()`)
- #134521 (Arbitrary self types v2: roll loop.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Arbitrary self types v2: roll loop.
Just for slightly more concise code - no functional changes.
r? `@wesleywiser`
Part of #44874
|
|
fix typos in the example code in the doc comments of `Ipv4Addr::from_bits()`, `Ipv6Addr::from_bits()` & `Ipv6Addr::to_bits()`
|
|
Hide `= _` as associated constant value inside impl blocks
Closes #134320.
### Before:
<img src="https://github.com/user-attachments/assets/19d28811-45d2-4563-9726-f40c6af411c6" width="300"> <img src="https://github.com/user-attachments/assets/1ecf8764-97ce-47f0-87fa-3b174d2fc578" width="300">
### After:
<img src="https://github.com/user-attachments/assets/6408c4ca-b1c4-42e4-884b-248833a4865f" width="300"> <img src="https://github.com/user-attachments/assets/df2f6981-16f6-409f-8abb-73c0a4a71d6b" width="300">
r? `@fmease`
|
|
Pass FnAbi to find_mir_or_eval_fn
https://github.com/rust-lang/miri/issues/4013 needs information from ``FnAbi``, hence it is passed to ``find_mir_or_eval_fn``.
r? `@RalfJung`
|
|
Rename `elem_offset` to `element_offset`
Tracking issue: #126769
Renames `slice::elem_offset` to `slice::element_offset` and improves the documentation of it and its related methods.
The current documentation can be misinterpreted (as explained [here](https://github.com/rust-lang/rust/issues/126769#issuecomment-2453363897)).
|
|
docs: Mention `spare_capacity_mut()` in `Vec::set_len`
I recently went down a small rabbit hole when trying to identify safe use of `Vec::set_len`. The solution was `Vec::spare_capacity_mut`. I think the docs on `Vec::set_len` benefit from mentioning this method.
A possible counter-argument could be that the [clippy lint `uninit_vec`](https://rust-lang.github.io/rust-clippy/master/index.html#/uninit_vec) already nudges people in the right direction. However, I think a working example on `Vec::set_len` is still beneficial.
Happy to hear your thoughts on the matter. :blush:
|
|
Automatic Rustup
|
|
|
|
|
|
Use `MixedBitSet`s in const qualif
These analyses' domains should be very homogeneous, having compressed bitmaps on huge cfgs should make a difference (and doesn’t have an impact on the smaller / regular cfgs in our benchmarks).
This is a >40% walltime reduction on [this stress test](https://github.com/Manishearth/icu4x_compile_sample) extracted from a real world ICU case, and a 10x or so max-rss reduction.
cc `@oli-obk` `@RalfJung`
Should help with (or fix) issue #134404.
|
|
`Ipv4Addr::from_bits()`, `Ipv6Addr::from_bits()` & `Ipv6Addr::to_bits()`
|
|
ci: use ubuntu-22 for large runners
|
|
Rollup of 5 pull requests
Successful merges:
- #134463 (compiletest: don't register predefined `MSVC`/`NONMSVC` FileCheck prefixes)
- #134487 (Add reference annotations for the `coverage` attribute)
- #134497 (coverage: Store coverage source regions as `Span` until codegen (take 2))
- #134502 (Update std libc version to 0.2.169)
- #134506 (Remove a duplicated check that doesn't do anything anymore.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Speed up `Parser::expected_tokens`
The constant pushing/clearing of `Parser::expected_tokens` during parsing is slow. This PR speeds it up greatly.
r? `@estebank`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make sure we handle `backwards_incompatible_lint` drops appropriately in drop elaboration
In #131326, a new kind of scheduled drop (`drop_kind: DropKind::Value` + `backwards_incompatible_lint: true`) was added so that we could insert a new kind of no-op MIR statement (`backward incompatible drop`) for linting purposes.
These drops were intended to have *no side-effects*, but drop elaboration code forgot to handle these drops specially and they were handled otherwise as normal drops in most of the code. This ends up being **unsound** since we insert more than one drop call for some values, which means that `Drop::drop` could be called more than once.
This PR fixes this by splitting out the `DropKind::ForLint` and adjusting the code. I'm not totally certain if all of the places I've adjusted are either reachable or correct, but I'm pretty certain that it's *more* correct than it was previously.
cc `@dingxiangfei2009`
r? nikomatsakis
Fixes #134482
|
|
Just for slightly more concise code - no functional changes.
r? @wesleywiser
|
|
|
|
Remove a duplicated check that doesn't do anything anymore.
fixes #134005
This code didn't actually `lub` the type of the previous expressions, but just the current type over and over again. Changing it to using the actual expression type does not change anything either, so may as well remove the entire loop.
|
|
Update std libc version to 0.2.169
Bumps `libc` to the latest release version [0.2.169](https://github.com/rust-lang/libc/releases/tag/0.2.169) which includes several fixes and additions, including mirroring `c_char` configuration (https://github.com/rust-lang/rust/pull/132975) for many targets.
|
|
coverage: Store coverage source regions as `Span` until codegen (take 2)
This is an attempt to re-land #133418:
> Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
> This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as Span instead.
> In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because Span is smaller than 4x u32.
That PR was reverted by #133608, because in some circumstances not covered by our test suite we were emitting coverage metadata that was causing `llvm-cov` to exit with an error (#133606).
---
The implementation here is *mostly* the same, but adapted for subsequent changes in the relevant code (e.g. #134163).
I believe that the changes in #134163 should be sufficient to prevent the problem that required the original PR to be reverted. But I haven't been able to reproduce the original breakage in a regression test, and the `llvm-cov` error message is extremely unhelpful, so I can't completely rule out the possibility of this breaking again.
r? jieyouxu (reviewer of the original PR)
|
|
Add reference annotations for the `coverage` attribute
This adds reference annotations for the `coverage` attribute.
|
|
compiletest: don't register predefined `MSVC`/`NONMSVC` FileCheck prefixes
This was fragile as it was based on host target passed to compiletest,
but the user could cross-compile and run test for a different target
(e.g. cross from linux to msvc, but msvc won't be set on the target).
Furthermore, it was also very surprising as normally revision names
(other than `CHECK`) was accepted as FileCheck prefixes.
This partially reverts the `MSVC`/`NONMSVC` predefined FileCheck
prefix registration introduced historically for some codegen tests.
This makes some codegen tests more verbose since they now need to
explicitly introduce `MSVC`/`NONMSVC` revisions, but I think that's
less surprising, e.g.:
```rs
//@ revisions: MSVC NONMSVC
//`@[MSVC]` only-msvc
//`@[NONMSVC]` ignore-msvc
```
Note that revisions are not *only* FileCheck prefixes in
FileCheck-based test suites, as they also can be used
to conditionally apply certain compiletest directives.
r? `@Zalathar` (or reroll a `r/? compiletest` reviewer)
try-job: x86_64-msvc
try-job: i686-msvc
try-job: x86_64-mingw-1
try-job: i686-mingw
|
|
|
|
|
|
|
|
This was fragile as it was based on host target passed to compiletest,
but the user could cross-compile and run test for a different target
(e.g. cross from linux to msvc, but msvc won't be set on the target).
Furthermore, it was also very surprising as normally revision names
(other than `CHECK`) was accepted as FileCheck prefixes.
|
|
Rollup of 7 pull requests
Successful merges:
- #133702 (Variants::Single: do not use invalid VariantIdx for uninhabited enums)
- #134427 (ci: remove duplicate task definition)
- #134432 (Fix intra doc links not generated inside footnote definitions)
- #134437 (reduce compiler `Assemble` complexity)
- #134474 (Forbid overwriting types in typeck)
- #134477 (move lint_unused_mut into sub-fn)
- #134491 (Some destructor/drop related tweaks)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
For some reason the memory layout is different on s390x.
|
|
add warning explaining the limitations of the native code mode
|
|
Some destructor/drop related tweaks
Two random tweaks I got from investigating some stuff around drops in edition 2024:
1. Use the `TypingEnv` of the mir builder, rather than making it over again.
2. Rename the `id` field from `Scope` to `local_id`, to reflect that it's a local id, and remove the `item_local_id()` accessor which just returned the id field.
|
