| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fix a layout possible miscalculation in `alloc::RawVec`
A layout miscalculation could happen in `RawVec` when used with a type whose size isn't a multiple of its alignment. I don't know if such type can exist in Rust, but the Layout API provides ways to manipulate such types. Anyway, it is better to calculate memory size in a consistent way.
|
|
Rollup of 7 pull requests
Successful merges:
- #94169 (Fix several asm! related issues)
- #94178 (tidy: fire less "ignoring file length unneccessarily" warnings)
- #94179 (solarish current_exe using libc call directly)
- #94196 (compiletest: Print process output info with less whitespace)
- #94208 (Add the let else tests found missing in the stabilization report)
- #94237 (Do not suggest wrapping an item if it has ambiguous un-imported methods)
- #94246 (ScalarMaybeUninit is explicitly hexadecimal in its formatting)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Do not suggest wrapping an item if it has ambiguous un-imported methods
If the method is defined for the receiver we have, but is ambiguous during probe, then it probably comes from one of several traits that just weren't `use`d. Don't suggest wrapping the receiver in `Box`/etc., even if that makes the method probe unambiguous.
Fixes #94218
|
|
Add the let else tests found missing in the stabilization report
In the stabilization report of `let else`, in #93628, I found various cases which weren't tested. This PR adds them.
|
|
compiletest: Print process output info with less whitespace
Before:
```
error: jsondocck failed!
status: exit status: 1
command: "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/jsondocck" "--doc-dir" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait" "--template" "/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"
stdout:
------------------------------------------
------------------------------------------
stderr:
------------------------------------------
Invalid command: Tried to use the previous path in the first command on line 10
Error: "Jsondocck failed for /data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"
------------------------------------------
Rustdoc Output:
status: exit status: 0
command: "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc" "-L" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait/auxiliary" "-o" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait" "--deny" "warnings" "/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs" "--output-format" "json" "-Zunstable-options"
stdout:
------------------------------------------
------------------------------------------
stderr:
------------------------------------------
------------------------------------------
```
After:
```
error: jsondocck failed!
status: exit status: 1
command: "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/jsondocck" "--doc-dir" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait" "--template" "/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"
stdout: none
--- stderr -------------------------------
Invalid command: Tried to use the previous path in the first command on line 10
Error: "Jsondocck failed for /data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"
------------------------------------------
Rustdoc Output:
status: exit status: 0
command: "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc" "-L" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait/auxiliary" "-o" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait" "--deny" "warnings" "/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs" "--output-format" "json" "-Zunstable-options"
stdout: none
stderr: none
```
|
|
tidy: fire less "ignoring file length unneccessarily" warnings
This avoids a situation where a file is at the border of the limit,
and alternates between hitting the limit and not hitting it, causing
a back and forth of addition of the ignore-tidy-linelength directive.
As an example, consider the ignore-tidy-filelength of compiler/rustc_typeck/src/collect.rs.
It was added in 2ca4964db5d263a8f9222846bd70a7f26cf414cf, removed in
37354ebc9794b0eb14b08c02177e3094c8fe91cd (a revert of the earlier commit), added again in 448d07683a6defd567996114793a09c9a8aef5df,
removed in 3171bd5bf54fb91f7f7df7c40df5adc7d8bd5dea, added in 438826fd1a9a119d00992ede948cdd479431ecbb,
and removed in bb0a2f985cb6e980cc026ea952733d53bb868f87.
To avoid this back and forth, we exempt files from the unneccessary
ignoring warning that have length of at least 70% of the limit.
|
|
Fix several asm! related issues
This is a combination of several fixes, each split into a separate commit. Splitting these into PRs is not practical since they conflict with each other.
Fixes #92378
Fixes #85247
r? ``@nagisa``
|
|
change `mir::Constant` in mir dumps
this removes duplicate information and avoids printing the `stable_crate_id` in mir dumps which broke CI in #94059
r? `@oli-obk` cc `@b-naber`
|
|
|
|
r=nnethercote
Simplify rustc_serialize by dropping support for decoding into JSON
This PR currently bundles two (somewhat separate) tasks.
First, it removes the JSON Decoder trait impl, which permitted going from JSON to Rust structs. For now, we keep supporting JSON deserialization, but only to `Json` (an equivalent of serde_json::Value). The primary hard to remove user there is for custom targets -- which need some form of JSON deserialization -- but they already have a custom ad-hoc pass for moving from Json to a Rust struct.
A [comment](https://github.com/rust-lang/rust/blob/e7aca895980f25f6d2d3c48e10fd04656764d1e4/compiler/rustc_target/src/spec/mod.rs#L1653) there suggests that it would be impractical to move them to a Decodable-based impl, at least without backwards compatibility concerns. I suspect that if we were widely breaking compat there, it would make sense to use serde_json at this point which would produce better error messages; the types in rustc_target are relatively isolated so we would not particularly suffer from using serde_derive.
The second part of the PR (all but the first commit) is to simplify the Decoder API by removing the non-primitive `read_*` functions. These primarily add indirection (through a closure), which doesn't directly cause a performance issue (the unique closure types essentially guarantee monomorphization), but does increase the amount of work rustc and LLVM need to do. This could be split out to a separate PR, but is included here in part to help motivate the first part.
Future work might consist of:
* Specializing enum discriminant encoding to avoid leb128 for small enums (since we know the variant count, we can directly use read/write u8 in almost all cases)
* Adding new methods to support faster deserialization (e.g., access to the underlying byte stream)
* Currently these are somewhat ad-hoc supported by specializations for e.g. `Vec<u8>`, but other types which could benefit don't today.
* Removing the Decoder trait entirely in favor of a concrete type -- today, we only really have one impl of it modulo wrappers used for specialization-based dispatch.
Highly recommend review with whitespace changes off, as the removal of closures frequently causes things to be de-indented.
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #91192 (Some improvements to the async docs)
- #94143 (rustc_const_eval: adopt let else in more places)
- #94156 (Gracefully handle non-UTF-8 string slices when pretty printing)
- #94186 (Update pin_static_ref stabilization version.)
- #94189 (Implement LowerHex on Scalar to clean up their display in rustdoc)
- #94190 (Use Metadata::modified instead of FileTime::from_last_modification_ti…)
- #94203 (CTFE engine: Scalar: expose size-generic to_(u)int methods)
- #94211 (Better error if the user tries to do assignment ... else)
- #94215 (trait system: comments and small nonfunctional changes)
- #94220 (Correctly handle miniz_oxide extern crate declaration)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Better error if the user tries to do assignment ... else
If the user tries to do assignment ... else, we now issue a more comprehensible error in the parser.
closes #93995
|
|
Use Metadata::modified instead of FileTime::from_last_modification_ti…
…me in run_cargo
Metadata::modified works in all platforms supported by the filetime
crate. This changes brings rustbuild a tiny bit closer towards dropping
the filetime dependency.
|
|
Implement LowerHex on Scalar to clean up their display in rustdoc
Follow-up of https://github.com/rust-lang/rust/pull/94091.
r? ````@RalfJung````
|
|
Gracefully handle non-UTF-8 string slices when pretty printing
Fixes #78520.
|
|
|
|
Checking of asm! register operands now properly takes function
attributes such as #[target_feature] and #[instruction_set] into
account.
|
|
safely `transmute<&List<Ty<'tcx>>, &List<GenericArg<'tcx>>>`
This PR has 3 relevant steps which are is split in distinct commits.
The first commit now interns `List<Ty<'tcx>>` and `List<GenericArg<'tcx>>` together, potentially reusing memory while allowing free conversions between these two using `List<Ty<'tcx>>::as_substs()` and `SubstsRef<'tcx>::try_as_type_list()`.
Using this, we then use `&'tcx List<Ty<'tcx>>` instead of a `SubstsRef<'tcx>` for tuple fields, simplifying a bunch of code.
Finally, as tuple fields and other generic arguments now use a different `TypeFoldable<'tcx>` impl, we optimize the impl for `List<Ty<'tcx>>` improving perf by slightly less than 1% in tuple heavy benchmarks.
|
|
Revert #93800, fixing CI time regression
This reverts commit a240ccd81c74c105b6f5fe84c46f8d36edb7e306 (merge commit of #93800), reversing
changes made to 393fdc10483da930cdbb00eabc3635030d2e776f.
This PR was likely responsible for a relatively large regression in
dist-x86_64-msvc-alt builder times, from approximately 1.7 to 2.8 hours,
bringing that builder into the pool of the slowest builders we currently have.
This seems to be limited to the alt builder due to needing parallel-compiler
enabled, likely leading to slow LLVM compilation for some reason. See some
investigation in [this Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/msvc.28.3F.29.20builders.20running.20much.20slower).
cc `@lcnr` `@oli-obk` `@b-naber` (per original PRs review/author)
We can re-apply this PR once the regression is fixed, but it is sufficiently large that I don't think keeping this on master is viable in the meantime unless there's a very strong case to be made for it. Alternatively, we can disable that builder (it's not critical since it's an alt build), but that obviously carries its own costs.
|
|
r=jackh726
Normalize obligation and expected trait_refs in confirm_poly_trait_refs
Consolidate normalization the obligation and expected trait refs in `confirm_poly_trait_refs`. Also, _always_ normalize these trait refs -- we were already normalizing the obligation trait ref when confirming closure and generator candidates, but this does it for fn pointer confirmation as well.
This presumably does more work in the case that the obligation's trait ref is already normalized, but we can see from the perf runs in #94070, it actually (paradoxically, perhaps) improves performance when paired with logic that normalizes projections in fulfillment loop.
|
|
|
|
|
|
|
|
|
|
The #[allow(...)] directive was tested for the body and the pattern,
but non-presence of it wasn't tested. Furthermore, it wasn't tested
for the expression. We add expression tests as well as ones checking
the non-presence of the directive.
|
|
This reverts commit a240ccd81c74c105b6f5fe84c46f8d36edb7e306, reversing
changes made to 393fdc10483da930cdbb00eabc3635030d2e776f.
This PR was likely responsible for a relatively large regression in
dist-x86_64-msvc-alt builder times, from approximately 1.7 to 2.8 hours,
bringing that builder into the pool of the slowest builders we currently have.
This seems to be limited to the alt builder due to needing parallel-compiler
enabled, likely leading to slow LLVM compilation for some reason.
|
|
This is no longer used by the compiler itself, and removing this support opens
the door to massively simplifying the Decodable/Decoder API by dropping the
self-describing deserialization support (necessary for JSON).
|
|
Before:
```
error: jsondocck failed!
status: exit status: 1
command: "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/jsondocck" "--doc-dir" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait" "--template" "/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"
stdout:
------------------------------------------
------------------------------------------
stderr:
------------------------------------------
Invalid command: Tried to use the previous path in the first command on line 10
Error: "Jsondocck failed for /data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"
------------------------------------------
Rustdoc Output:
status: exit status: 0
command: "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc" "-L" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait/auxiliary" "-o" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait" "--deny" "warnings" "/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs" "--output-format" "json" "-Zunstable-options"
stdout:
------------------------------------------
------------------------------------------
stderr:
------------------------------------------
------------------------------------------
```
After:
```
error: jsondocck failed!
status: exit status: 1
command: "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/jsondocck" "--doc-dir" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait" "--template" "/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"
stdout: none
--- stderr -------------------------------
Invalid command: Tried to use the previous path in the first command on line 10
Error: "Jsondocck failed for /data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"
------------------------------------------
Rustdoc Output:
status: exit status: 0
command: "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc" "-L" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait/auxiliary" "-o" "/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait" "--deny" "warnings" "/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs" "--output-format" "json" "-Zunstable-options"
stdout: none
stderr: none
```
|
|
Main motivation: Fixes some issues with the current behavior. This PR is
more-or-less completely re-implementing the unused_unsafe lint; it’s also only
done in the MIR-version of the lint, the set of tests for the `-Zthir-unsafeck`
version no longer succeeds (and is thus disabled, see `lint-unused-unsafe.rs`).
On current nightly,
```rs
unsafe fn unsf() {}
fn inner_ignored() {
unsafe {
#[allow(unused_unsafe)]
unsafe {
unsf()
}
}
}
```
doesn’t create any warnings. This situation is not unrealistic to come by, the
inner `unsafe` block could e.g. come from a macro. Actually, this PR even
includes removal of one unused `unsafe` in the standard library that was missed
in a similar situation. (The inner `unsafe` coming from an external macro hides
the warning, too.)
The reason behind this problem is how the check currently works:
* While generating MIR, it already skips nested unsafe blocks (i.e. unsafe
nested in other unsafe) so that the inner one is always the one considered
unused
* To differentiate the cases of no unsafe operations inside the `unsafe` vs.
a surrounding `unsafe` block, there’s some ad-hoc magic walking up the HIR to
look for surrounding used `unsafe` blocks.
There’s a lot of problems with this approach besides the one presented above.
E.g. the MIR-building uses checks for `unsafe_op_in_unsafe_fn` lint to decide
early whether or not `unsafe` blocks in an `unsafe fn` are redundant and ought
to be removed.
```rs
unsafe fn granular_disallow_op_in_unsafe_fn() {
unsafe {
#[deny(unsafe_op_in_unsafe_fn)]
{
unsf();
}
}
}
```
```
error: call to unsafe function is unsafe and requires unsafe block (error E0133)
--> src/main.rs:13:13
|
13 | unsf();
| ^^^^^^ call to unsafe function
|
note: the lint level is defined here
--> src/main.rs:11:16
|
11 | #[deny(unsafe_op_in_unsafe_fn)]
| ^^^^^^^^^^^^^^^^^^^^^^
= note: consult the function's documentation for information on how to avoid undefined behavior
warning: unnecessary `unsafe` block
--> src/main.rs:10:5
|
9 | unsafe fn granular_disallow_op_in_unsafe_fn() {
| --------------------------------------------- because it's nested under this `unsafe` fn
10 | unsafe {
| ^^^^^^ unnecessary `unsafe` block
|
= note: `#[warn(unused_unsafe)]` on by default
```
Here, the intermediate `unsafe` was ignored, even though it contains a unsafe
operation that is not allowed to happen in an `unsafe fn` without an additional `unsafe` block.
Also closures were problematic and the workaround/algorithms used on current
nightly didn’t work properly. (I skipped trying to fully understand what it was
supposed to do, because this PR uses a completely different approach.)
```rs
fn nested() {
unsafe {
unsafe { unsf() }
}
}
```
```
warning: unnecessary `unsafe` block
--> src/main.rs:10:9
|
9 | unsafe {
| ------ because it's nested under this `unsafe` block
10 | unsafe { unsf() }
| ^^^^^^ unnecessary `unsafe` block
|
= note: `#[warn(unused_unsafe)]` on by default
```
vs
```rs
fn nested() {
let _ = || unsafe {
let _ = || unsafe { unsf() };
};
}
```
```
warning: unnecessary `unsafe` block
--> src/main.rs:9:16
|
9 | let _ = || unsafe {
| ^^^^^^ unnecessary `unsafe` block
|
= note: `#[warn(unused_unsafe)]` on by default
warning: unnecessary `unsafe` block
--> src/main.rs:10:20
|
10 | let _ = || unsafe { unsf() };
| ^^^^^^ unnecessary `unsafe` block
```
*note that this warning kind-of suggests that **both** unsafe blocks are redundant*
--------------------------------------------------------------------------------
I also dislike the fact that it always suggests keeping the outermost `unsafe`.
E.g. for
```rs
fn granularity() {
unsafe {
unsafe { unsf() }
unsafe { unsf() }
unsafe { unsf() }
}
}
```
I prefer if `rustc` suggests removing the more-course outer-level `unsafe`
instead of the fine-grained inner `unsafe` blocks, which it currently does on nightly:
```
warning: unnecessary `unsafe` block
--> src/main.rs:10:9
|
9 | unsafe {
| ------ because it's nested under this `unsafe` block
10 | unsafe { unsf() }
| ^^^^^^ unnecessary `unsafe` block
|
= note: `#[warn(unused_unsafe)]` on by default
warning: unnecessary `unsafe` block
--> src/main.rs:11:9
|
9 | unsafe {
| ------ because it's nested under this `unsafe` block
10 | unsafe { unsf() }
11 | unsafe { unsf() }
| ^^^^^^ unnecessary `unsafe` block
warning: unnecessary `unsafe` block
--> src/main.rs:12:9
|
9 | unsafe {
| ------ because it's nested under this `unsafe` block
...
12 | unsafe { unsf() }
| ^^^^^^ unnecessary `unsafe` block
```
--------------------------------------------------------------------------------
Needless to say, this PR addresses all these points. For context, as far as my
understanding goes, the main advantage of skipping inner unsafe blocks was that
a test case like
```rs
fn top_level_used() {
unsafe {
unsf();
unsafe { unsf() }
unsafe { unsf() }
unsafe { unsf() }
}
}
```
should generate some warning because there’s redundant nested `unsafe`, however
every single `unsafe` block _does_ contain some statement that uses it. Of course
this PR doesn’t aim change the warnings on this kind of code example, because
the current behavior, warning on all the inner `unsafe` blocks, makes sense in this case.
As mentioned, during MIR building all the unsafe blocks *are* kept now, and usage
is attributed to them. The way to still generate a warning like
```
warning: unnecessary `unsafe` block
--> src/main.rs:11:9
|
9 | unsafe {
| ------ because it's nested under this `unsafe` block
10 | unsf();
11 | unsafe { unsf() }
| ^^^^^^ unnecessary `unsafe` block
|
= note: `#[warn(unused_unsafe)]` on by default
warning: unnecessary `unsafe` block
--> src/main.rs:12:9
|
9 | unsafe {
| ------ because it's nested under this `unsafe` block
...
12 | unsafe { unsf() }
| ^^^^^^ unnecessary `unsafe` block
warning: unnecessary `unsafe` block
--> src/main.rs:13:9
|
9 | unsafe {
| ------ because it's nested under this `unsafe` block
...
13 | unsafe { unsf() }
| ^^^^^^ unnecessary `unsafe` block
```
in this case is by emitting a `unused_unsafe` warning for all of the `unsafe`
blocks that are _within a **used** unsafe block_.
The previous code had a little HIR traversal already anyways to collect a set of
all the unsafe blocks (in order to afterwards determine which ones are unused
afterwards). This PR uses such a traversal to do additional things including logic
like _always_ warn for an `unsafe` block that’s inside of another **used**
unsafe block. The traversal is expanded to include nested closures in the same go,
this simplifies a lot of things.
The whole logic around `unsafe_op_in_unsafe_fn` is a little complicated, there’s
some test cases of corner-cases in this PR. (The implementation involves
differentiating between whether a used unsafe block was used exclusively by
operations where `allow(unsafe_op_in_unsafe_fn)` was active.) The main goal was
to make sure that code should compile successfully if all the `unused_unsafe`-warnings
are addressed _simultaneously_ (by removing the respective `unsafe` blocks)
no matter how complicated the patterns of `unsafe_op_in_unsafe_fn` being
disallowed and allowed throughout the function are.
--------------------------------------------------------------------------------
One noteworthy design decision I took here: An `unsafe` block
with `allow(unused_unsafe)` **is considered used** for the purposes of
linting about redundant contained unsafe blocks. So while
```rs
fn granularity() {
unsafe { //~ ERROR: unnecessary `unsafe` block
unsafe { unsf() }
unsafe { unsf() }
unsafe { unsf() }
}
}
```
warns for the outer `unsafe` block,
```rs
fn top_level_ignored() {
#[allow(unused_unsafe)]
unsafe {
#[deny(unused_unsafe)]
{
unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
}
}
}
```
warns on the inner ones.
|
|
run_cargo
Metadata::modified works in all platforms supported by the filetime
crate. This changes brings rustbuild a tiny bit closer towards dropping
the filetime dependency.
|
|
|
|
r=GuillaumeGomez
rustdoc: resolve intra-doc links when checking HTML
Similar to #86451
CC #67799
Given this test case:
```rust
#![warn(rustdoc::invalid_html_tags)]
#![warn(rustdoc::broken_intra_doc_links)]
pub struct ExistentStruct<T>(T);
/// This [test][ExistentStruct<i32>] thing!
pub struct NoError;
```
This pull request silences the following, spurious warning:
```text
warning: unclosed HTML tag `i32`
--> test.rs:6:31
|
6 | /// This [test][ExistentStruct<i32>] thing!
| ^^^^^
|
note: the lint level is defined here
--> test.rs:1:9
|
1 | #![warn(rustdoc::invalid_html_tags)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
help: try marking as source code
|
6 | /// This [test][`ExistentStruct<i32>`] thing!
| + +
warning: 1 warning emitted
```
|
|
|
|
Extend uninhabited enum variant branch elimination to also affect fallthrough
The `uninhabited_enum_branching` mir opt eliminates branches on variants where the data is uninhabited. This change extends this pass to also ensure that the `otherwise` case points to a trivially unreachable bb if all inhabited variants are present in the non-otherwise branches.
I believe it was `@scottmcm` who said that LLVM eliminates some of this information in its SimplifyCFG pass. This is unfortunate, but this change should still be at least a small improvement in principle (I don't think it will show up on any benchmarks)
|
|
This avoids a situation where a file is at the border of the limit,
and alternates between hitting the limit and not hitting it, causing
a back and forth of addition of the ignore-tidy-linelength directive.
As an example, consider the ignore-tidy-filelength of compiler/rustc_typeck/src/collect.rs.
It was added in 2ca4964db5d263a8f9222846bd70a7f26cf414cf, removed in
37354ebc9794b0eb14b08c02177e3094c8fe91cd, added again in 448d07683a6defd567996114793a09c9a8aef5df,
removed in 3171bd5bf54fb91f7f7df7c40df5adc7d8bd5dea, added in 438826fd1a9a119d00992ede948cdd479431ecbb,
and #94142 is going to remove it again.
To avoid this back and forth, we exempt files from the unneccessary
ignoring warning that have length of at least 70% of the limit.
|
|
Rollup of 14 pull requests
Successful merges:
- #93580 (Stabilize pin_static_ref.)
- #93639 (Release notes for 1.59)
- #93686 (core: Implement ASCII trim functions on byte slices)
- #94002 (rustdoc: Avoid duplicating macros in sidebar)
- #94019 (removing architecture requirements for RustyHermit)
- #94023 (adapt static-nobundle test to use llvm-nm)
- #94091 (Fix rustdoc const computed value)
- #94093 (Fix pretty printing of enums without variants)
- #94097 (Add module-level docs for `rustc_middle::query`)
- #94112 (Optimize char_try_from_u32)
- #94113 (document rustc_middle::mir::Field)
- #94122 (Fix miniz_oxide types showing up in std docs)
- #94142 (rustc_typeck: adopt let else in more places)
- #94146 (Adopt let else in more places)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix pretty printing of enums without variants
92d20c4aaddea9507f8ad37fe37c551219153bbf removed no-variants special case from `try_destructure_const` with expectation that this case would be handled gracefully when `read_discriminant` returns an error.
Alas in that case `read_discriminant` succeeds while returning a non-existing variant, so the special case is still necessary.
Fixes #94073.
r? ````@oli-obk````
|
|
Fix rustdoc const computed value
Fixes #85088.
It looks like this now (instead of hexadecimal):
r? ````@oli-obk````
|
|
adapt static-nobundle test to use llvm-nm
No functional changes intended.
This updates the test case to use llvm-nm instead of the system nm.
This fixes an instance over at the experimental build of rustc with HEAD LLVM:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/8380#ef6f41b5-8595-49a6-be37-0eff80e0ccb5
It is related to https://github.com/rust-lang/rust/pull/94001.
The issue is that this test uses the system nm, which may not be recent
enough to understand the update to uwtable. This replaces the test to
use the llvm-nm that should be recent enough (consistent with the LLVM
sources we use to build rustc).
|
|
rustdoc: Avoid duplicating macros in sidebar
Fixes #93912.
cc ``````@jsha`````` (for the GUI test)
r? ``````@camelid``````
|
|
Guard against unwinding in cleanup code
Currently the only safe guard we have against double unwind is the panic count (which is local to Rust). When double unwinds indeed happen (e.g. C++ exception + Rust panic, or two C++ exceptions), then the second unwind actually goes through and the first unwind is leaked. This can cause UB. cc rust-lang/project-ffi-unwind#6
E.g. given the following C++ code:
```c++
extern "C" void foo() {
throw "A";
}
extern "C" void execute(void (*fn)()) {
try {
fn();
} catch(...) {
}
}
```
This program is well-defined to terminate:
```c++
struct dtor {
~dtor() noexcept(false) {
foo();
}
};
void a() {
dtor a;
dtor b;
}
int main() {
execute(a);
return 0;
}
```
But this Rust code doesn't catch the double unwind:
```rust
extern "C-unwind" {
fn foo();
fn execute(f: unsafe extern "C-unwind" fn());
}
struct Dtor;
impl Drop for Dtor {
fn drop(&mut self) {
unsafe { foo(); }
}
}
extern "C-unwind" fn a() {
let _a = Dtor;
let _b = Dtor;
}
fn main() {
unsafe { execute(a) };
}
```
To address this issue, this PR adds an unwind edge to an abort block, so that the Rust example aborts. This is similar to how clang guards against double unwind (except clang calls terminate per C++ spec and we abort).
The cost should be very small; it's an additional trap instruction (well, two for now, since we use TrapUnreachable, but that's a different issue) for each function with landing pads; if LLVM gains support to encode "abort/terminate" info directly in LSDA like GCC does, then it'll be free. It's an additional basic block though so compile time may be worse, so I'd like a perf run.
r? `@ghost`
`@rustbot` label: F-c_unwind
|
|
|
|
|
|
|
|
92d20c4aaddea9507f8ad37fe37c551219153bbf removed no-variants special
case from try_destructure_const with expectation that this case would be
handled gracefully when read_discriminant returns an error.
Alas in that case read_discriminant succeeds while returning a
non-existing variant, so the special case is still necessary.
|
|
|
|
|
|
Fix ScalarInt to char conversion
to avoid panic for invalid Unicode scalar values
|
