| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This also makes the implementation slightly more efficient by only
compiling the regex once.
See https://github.com/rust-lang/rust/pull/81764#issuecomment-774122759
for why this was removed; essentially the benefit didn't seem great
enough to deserve a lint.
|
|
r=Mark-Simulacrum
Optimize jumps in PartialOrd le
Closes https://github.com/rust-lang/rust/issues/73338
This change stops default implementation of `le()` method of PartialOrd from generating jumps.
|
|
Allow clobbering unsupported registers in asm!
Previously registers could only be marked as clobbered if the target feature for that register was enabled. This restriction is now removed.
cc #81092
r? ``@nagisa``
|
|
Remove attribute `#[link_args]`
Closes https://github.com/rust-lang/rust/issues/29596
The attribute could always be replaced with `-C link-arg`, but cargo didn't provide a reasonable way to pass such flags to rustc.
Now cargo supports `cargo:rustc-link-arg*` directives in build scripts (https://doc.rust-lang.org/cargo/reference/unstable.html#extra-link-arg), so this attribute can be removed.
|
|
r=Mark-Simulacrum
Tests: Remove redundant `ignore-tidy-linelength` annotations
This is step 2 towards fixing #77548.
In the codegen and codegen-units test suites, the `//` comment markers
were kept in order not to affect any source locations. This is because
these tests cannot be automatically `--bless`ed.
|
|
Closes https://github.com/rust-lang/rust/issues/73338
This change stops default implementation of `le()` method from generating jumps.
|
|
2229: Fix diagnostic issue when using FakeReads in closures
This PR fixes a diagnostic issue caused by https://github.com/rust-lang/rust/pull/82536. A temporary work around was used in this merged PR which involved feature gating the addition of FakeReads introduced as a result of pattern matching in closures.
The fix involves adding an optional closure DefId to ForLet and ForMatchedPlace FakeReadCauses. This DefId will only be added if a closure pattern matches a Place starting with an Upvar.
r? ```@nikomatsakis```
|
|
Previously registers could only be marked as clobbered if the target feature for that register was enabled. This restriction is now removed.
|
|
This is step 2 towards fixing #77548.
In the codegen and codegen-units test suites, the `//` comment markers
were kept in order not to affect any source locations. This is because
these tests cannot be automatically `--bless`ed.
|
|
|
|
rustdoc: Don't load all extern crates unconditionally
Instead, only load the crates that are linked to with intra-doc links.
This doesn't help very much with any of rustdoc's fundamental issues
with freezing the resolver, but it at least fixes a stable-to-stable
regression, and makes the crate loading model somewhat more consistent
with rustc's. I tested and it unfortunately does not help at all with https://github.com/rust-lang/rust/pull/82496.
Closes https://github.com/rust-lang/rust/issues/68427. Let me know if you want me to open a separate issue for not freezing the resolver.
r? `@petrochenkov` cc `@eddyb` `@ollie27`
|
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
r? `@tmandry`
FYI: `@wesleywiser`
|
|
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
|
|
Maintain supported sanitizers as a target property
In an effort to remove a hard-coded allow-list for target-sanitizer support correspondence, this PR moves the configuration to the target options.
Perhaps the one notable change made in this PR is this doc-comment:
```rust
/// The sanitizers supported by this target
///
/// Note that the support here is at a codegen level. If the machine code with sanitizer
/// enabled can generated on this target, but the necessary supporting libraries are not
/// distributed with the target, the sanitizer should still appear in this list for the target.
```
Previously the target would typically be added to the allow-list at the same time as the supporting runtime libraries are shipped for the target. However whether we ship the runtime libraries or not needn't be baked into the compiler; and if we don't users will receive a significantly more directed error about library not being found.
Fixes #81802
|
|
|
|
This commit adds an additional target property – `supported_sanitizers`,
and replaces the hardcoded allowlists in argument parsing to use this
new property.
Fixes #81802
|
|
Instead, only load the crates that are linked to with intra-doc links.
This doesn't help very much with any of rustdoc's fundamental issues
with freezing the resolver, but it at least fixes a stable-to-stable
regression, and makes the crate loading model somewhat more consistent
with rustc's.
|
|
Rollup of 7 pull requests
Successful merges:
- #83065 (Rework `std::sys::windows::alloc`)
- #83478 (rustdoc: Add unstable option to only emit shared/crate-specific files)
- #83629 (Fix double-drop in `Vec::from_iter(vec.into_iter())` specialization when items drop during panic)
- #83673 (give full path of constraint in suggest_constraining_type_param)
- #83755 (Simplify coverage tests)
- #83757 (2229: Support migration via rustfix)
- #83771 (Fix stack overflow detection on FreeBSD 11.1+)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
2229: Support migration via rustfix
- Adds support of machine applicable suggestions for `disjoint_capture_drop_reorder`.
- Doesn't migrate in the case of pre-existing bugs in user code
r? ``@nikomatsakis``
|
|
Simplify coverage tests
This change reduces the risk of impacting coverage tests on unrelated
changes (such as MIR and Span changes), and reduces the burden when
blessing coverage changes in case it is necessary.
* Remove all spanview tests. The spanview tests were useful during
development, but they can be generated as needed, via compiler command
line flags. They aren't critical to confirming coverage results. (The
coverage report tests are sufficient.)
When spanview regeneration was necessary, the diffs were way too hard
to read to be useful anyway. So I'm removing them to reduce friction
from a feature that is no longer useful.
* Remove the requirement for `llvm-cov show --debug` when blessing
tests. The `--debug` flag is, unfortunately, only available if LLVM is
built with `optimize = false` (in Rust's config.toml). This adds
significant time and resource burdens to the contributor's build. As
it turns out, for other reasons in the past, I wasn't actually using
the debug output (counter info) to validate coverage anymore either,
so it was required for no reason, I now realize.
|
|
give full path of constraint in suggest_constraining_type_param
close https://github.com/rust-lang/rust/issues/83513
|
|
rustdoc: Add unstable option to only emit shared/crate-specific files
The intended use case is for docs.rs, which can now copy exactly the
files it cares about, rather than having to guess based on whether they
have a resource suffix or not. In particular, some files have a resource
suffix but cannot be shared between crates: https://github.com/rust-lang/docs.rs/pull/1312#issuecomment-798783688
The end goal is to fix rust-lang/docs.rs#1327 by reverting rust-lang/docs.rs#1324.
This obsoletes `--print=unversioned-files`, which I plan to remove as
soon as docs.rs stops using it.
I recommend reviewing this one commit at a time.
r? ``@GuillaumeGomez`` cc ``@Nemo157`` ``@pietroalbini``
|
|
Add allocation information to undefined behaviour errors.
So far I'm looking on information on whether the error messages are suitable.
Fixes #53325.
|
|
add OR_PATTERNS_BACK_COMPAT lint
close https://github.com/rust-lang/rust/issues/83318
|
|
Rollup of 5 pull requests
Successful merges:
- #83535 (Break when there is a mismatch in the type count)
- #83721 (Add a button to copy the "use statement")
- #83740 (Fix comment typo in once.rs)
- #83745 (Add my new email address to .mailmap)
- #83754 (Add test to ensure search tabs behaviour)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add test to ensure search tabs behaviour
It adds a GUI test for https://github.com/rust-lang/rust/pull/80382.
r? ```@jyn514```
|
|
Break when there is a mismatch in the type count
When other errors are generated, there can be a mismatch between the
amount of input types in MIR, and the amount in the function itself.
Break from the comparative loop if this is the case to prevent
out-of-bounds.
Fixes #83499
|
|
normalize mir::Constant differently from ty::Const in preparation for valtrees
Valtrees are unable to represent many kind of constant values (this is on purpose). For constants that are used at runtime, we do not need a valtree representation and can thus use a different form of evaluation. In order to make this explicit and less fragile, I added a `fold_constant` method to `TypeFolder` and implemented it for normalization. Normalization can now, when it wants to eagerly evaluate a constant, normalize `mir::Constant` directly into a `mir::ConstantKind::Val` instead of relying on the `ty::Const` evaluation.
In the future we can get rid of the `ty::Const` in there entirely and add our own `Unevaluated` variant to `mir::ConstantKind`. This would allow us to remove the `promoted` field from `ty::ConstKind::Unevaluated`, as promoteds can never occur in the type system.
cc `@rust-lang/wg-const-eval`
r? `@lcnr`
|
|
This change reduces the risk of impacting coverage tests on unrelated
changes (such as MIR and Span changes), and reduces the burden when
blessing coverage changes in case it is necessary.
* Remove all spanview tests. The spanview tests were useful during
development, but they can be generated as needed, via compiler command
line flags. They aren't critical to confirming coverage results. (The
coverage report tests are sufficient.)
When spanview regeneration was necessary, the diffs were way too hard
to read to be useful anyway. So I'm removing them to reduce friction
from a feature that is no longer useful.
* Remove the requirement for `llvm-cov show --debug` when blessing
tests. The `--debug` flag is, unfortunately, only available if LLVM is
built with `optimize = false` (in Rust's config.toml). This adds
significant time and resource burdens to the contributor's build. As
it turns out, for other reasons in the past, I wasn't actually using
the debug output (counter info) to validate coverage anymore either,
so it was required for no reason, I now realize.
|
|
Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
Fixes #80936.
"spotlight" is not a very specific or self-explaining name.
Additionally, the dialog that it triggers is called "Notable traits".
So, "notable trait" is a better name.
* Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
* Rename `#![feature(doc_spotlight)]` to `#![feature(doc_notable_trait)]`
* Update documentation
* Improve documentation
r? `@Manishearth`
|
|
Fix expected/found order on impl trait projection mismatch error
fixes #68561
This PR adds a new `ObligationCauseCode` used when checking the concrete type of an impl trait satisfies its bounds, and checks for that cause code in the existing test to see if a projection's normalized type should be the "expected" or "found" type.
The second commit adds a `peel_derives` to that test, which appears to be necessary in some cases (see projection-mismatch-in-impl-where-clause.rs, which would still give expected/found in the wrong order otherwise). This caused some other changes in diagnostics not involving impl trait, but they look correct to me.
|
|
|
|
|
|
AngelicosPhosphoros:simplify_binary_and_to_get_better_asm, r=nagisa
Simplify logical operations CFG
This is basically same commit as e38e954a0d249f88d0a55504f70d6055e865a931 which was reverted later in 676953fde9120cda62e4ef2f75a804af7481d6af
In both cases, this changes weren't benchmarked.
e38e954a0d249f88d0a55504f70d6055e865a931 leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/62993)
676953fde9120cda62e4ef2f75a804af7481d6af leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/83623)
|
|
|
|
|
|
|
|
Add a test that has the right input to trigger an out-of-bounds
error when in MIR the local_decls and the normalized_input_tys don't
match in amount.
|
|
Stream the dep-graph to a file instead of storing it in-memory.
This is a reimplementation of #60035.
Instead of storing the dep-graph in-memory, the nodes are encoded as they come
into the a temporary file as they come. At the end of a successful the compilation,
this file is renamed to be the persistent dep-graph, to be decoded during the next
compilation session.
This two-files scheme avoids overwriting the dep-graph on unsuccessful or crashing compilations.
The structure of the file is modified to be the sequence of `(DepNode, Fingerprint, EdgesVec)`.
The deserialization is responsible for going to the more compressed representation.
The `node_count` and `edge_count` are stored in the last 16 bytes of the file,
in order to accurately reserve capacity for the vectors.
At the end of the compilation, the encoder is flushed and dropped.
The graph is not usable after this point: any creation of a node will ICE.
I had to retrofit the debugging options, which is not really pretty.
|
|
This is basically same commit as e38e954a0d249f88d0a55504f70d6055e865a931 which was reverted later in 676953fde9120cda62e4ef2f75a804af7481d6af
In both cases, this changes weren't benchmarked.
e38e954a0d249f88d0a55504f70d6055e865a931 leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/62993)
676953fde9120cda62e4ef2f75a804af7481d6af leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/83623)
Also it changes some src/test/run-make-fulldeps/coverage-spanview/expected_mir_dump* files automatically.
|
|
test: add more cases
test: add comments
refine msg
|
|
|
|
Add a regression test for issue-68830
Closes #68830
|
|
Add regression tests for #79825 and #81555
Closes #79825.
Closes #81555.
`@rustbot` label A-proc-macros T-compiler
|
|
invocation specific
|
|
|
|
This also changes custom themes from Toolchain to Crate files.
|
|
|
|
|
