Allow specifying alignment for functions
Fixes#75072
This allows the user to specify alignment for functions, which can be useful for low level work where functions need to necessarily be aligned to a specific value.
I believe the error cases not covered in the match are caught earlier based on my testing so I had them just return `None`.
Set dso_local for hidden, private and local items
This should probably have no real effect in most cases, as e.g. `hidden`
visibility already implies `dso_local` (or at least LLVM IR does not
preserve the `dso_local` setting if the item is already `hidden`), but
it should fix `-Crelocation-model=static` and improve codegen in
executables.
Note that this PR does not exhaustively port the logic in [clang], only the
portion that is necessary to fix a regression from LLVM 12 that relates to
`-Crelocation_model=static`.
Fixes#83335
[clang]: 3001d080c8/clang/lib/CodeGen/CodeGenModule.cpp (L945-L1039)
rustdoc: Cleanup handling of associated items for intra-doc links
Helps with https://github.com/rust-lang/rust/issues/83761 (right now the uses of the resolver are all intermingled with uses of the tyctxt). Best reviewed one commit at a time.
r? ```@bugadani``` maybe? Feel free to reassign :)
expand: Do not ICE when a legacy AST-based macro attribute produces and empty expression
Fixes https://github.com/rust-lang/rust/issues/80251
The reported error is the same as for `let _ = #[cfg(FALSE)] EXPR;`
Prevent very long compilation runtimes in LateBoundRegionNameCollector
Fixes https://github.com/rust-lang/rust/issues/83150
On recursive types such as in the example given in https://github.com/rust-lang/rust/issues/83150, the current implementation of `LateBoundRegionNameCollector` has very long compilation runtimes. To prevent those we store the types visited in the `middle::ty::Visitor` implementation of `LateBoundRegionNameCollector` in a `SsoHashSet`.
Give a better error when --theme is not a CSS file
Before:
```
error: invalid argument: "bacon.toml"
```
After:
```
error: invalid argument: "bacon.toml"
|
= help: arguments to --theme must be CSS files
```
cc https://github.com/rust-lang/rust/pull/83478
Previously, the types looked like this:
- None means this is not an associated item (but may be a variant field)
- Some(Err) means this is known to be an error. I think the only way that can happen is if it resolved and but you had your own anchor.
- Some(Ok(_, None)) was impossible.
Now, this returns a nested Option and does the error handling and
fiddling with the side channel in the caller. As a side-effect, it also
removes duplicate error handling.
This has one small change in behavior, which is that
`resolve_primitive_associated_item` now goes through `variant_field` if
it fails to resolve something. This is not ideal, but since it will be
quickly rejected anyway, I think the performance hit is worth the
cleanup.
This also fixes a bug where struct fields would forget to set the side
channel, adds a test for the bug, and ignores `private_intra_doc_links`
in rustc_resolve (since it's always documented with
--document-private-items).
Don't report disambiguator error if link would have been ignored
Fixes#83859.
This prevents us from warning on links such as `<hello@example.com>`.
Note that we still warn on links such as `<hello@localhost>` because
they have no dots in them. However, the links will still work, even
though a warning is reported.
r? ````@jyn514````
Let `#[allow(unstable_name_collisions)]` work for things other than function
Fixes#81522
In addition to the report in #81522, currently `#[allow(unstable_name_collisions)]` doesn't suppress the corresponding diagnostics even if this attribute is appended to an expression statement or a let statement. It seems like this is because the wrong `HirId` is passed to `struct_span_lint_hir`.
It's fixed in this PR, and a regression test for it is also added.
This prevents us from warning on links such as `<hello@example.com>`.
Note that we still warn on links such as `<hello@localhost>` because
they have no dots in them. However, the links will still work, even
though a warning is reported.
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``
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.
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```
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
This should have no real effect in most cases, as e.g. `hidden`
visibility already implies `dso_local` (or at least LLVM IR does not
preserve the `dso_local` setting if the item is already `hidden`), but
it should fix `-Crelocation-model=static` and improve codegen in
executables.
Note that this PR does not exhaustively port the logic in [clang]. Only
the obviously correct portion and what is necessary to fix a regression
from LLVM 12 that relates to `-Crelocation_model=static`.
Fixes#83335
[clang]: 3001d080c8/clang/lib/CodeGen/CodeGenModule.cpp (L945-L1039)
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.
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.
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 fixrust-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``
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
