| Age | Commit message (Collapse) | Author | Lines |
|
Add flag to configure `large_assignments` lint
The `large_assignments` lints detects moves over specified limit. The
limit is configured through `move_size_limit = "N"` attribute placed at
the root of a crate. When attribute is absent, the lint is disabled.
Make it possible to enable the lint without making any changes to the
source code, through a new flag `-Zmove-size-limit=N`. For example, to
detect moves exceeding 1023 bytes in a cargo crate, including all
dependencies one could use:
```
$ env RUSTFLAGS=-Zmove-size-limit=1024 cargo build -vv
```
Lint tracking issue #83518.
|
|
r=petrochenkov
Remove nondeterminism in multiple-definitions test
Compare all fields in `DllImport` when sorting to avoid nondeterminism in the error for multiple inconsistent definitions of an extern function. Restore the multiple-definitions test.
Resolves #87084.
|
|
|
|
|
|
multiple-definitions test
|
|
|
|
shrinking the deprecated span
ref: https://github.com/rust-lang/rust/pull/85617#issuecomment-854947988
part of #85403
r? `@estebank`
The reason is that if we use method_span directly, it will cause the in_derive_expansion judgment to fail.
|
|
Reduce the amount of untracked state in TyCtxt -- Take 2
Main part of #85153
The offending line (https://github.com/rust-lang/rust/pull/85153#discussion_r642866298) is replaced by a FIXME until the possible bug and the perf concern are both resolved.
r? `@Aaron1011`
|
|
i686-pc-windows-msvc.
|
|
Refactor the generation of the metadata for linking
|
|
|
|
|
|
The `large_assignments` lints detects moves over specified limit. The
limit is configured through `move_size_limit = "N"` attribute placed at
the root of a crate. When attribute is absent, the lint is disabled.
Make it possible to enable the lint without making any changes to the
source code, through a new flag `-Zmove-size-limit=N`. For example, to
detect moves exceeding 1023 bytes in a cargo crate, including all
dependencies one could use:
```
$ env RUSTFLAGS=-Zmove-size-limit=1024 cargo build -vv
```
|
|
This reverts commit 8176ab8bc18fdd7d3c2cf7f720c51166364c33a3.
|
|
Remove LibSource
The information is stored in used_crate_source too anyway.
Split out of #86105
r? `@petrochenkov`
|
|
The information is stored in used_crate_source too anyway
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Drop metadata_encoding_version.
Part of #85153
r? `@Aaron1011`
|
|
This reverts commit d0ec85d3fb6d322496cb8f4bc1c21e19f23284ad.
|
|
"raw-dylib")].
This does not yet support #[link_name] attributes on functions, the #[link_ordinal]
attribute, #[link(kind = "raw-dylib")] on extern blocks in bin crates, or
stdcall functions on 32-bit x86.
|
|
Also remove original_crate_name, which had the exact same implementation
|
|
|
|
|
|
|
|
|
|
|
|
Also remove original_crate_name, which had the exact same implementation
|
|
|
|
|
|
|
|
shrinking the deprecated method span
close https://github.com/rust-lang/rust/issues/84637
|
|
|
|
|
|
|
|
This commit implements both the native linking modifiers infrastructure
as well as an initial attempt at the individual modifiers from the RFC.
It also introduces a feature flag for the general syntax along with
individual feature flags for each modifier.
|
|
The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.
Fixes: #83601
The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).
While testing, I also noticed two other issues:
* spanview debug file output ICEd on a function with no body. The
workaround for this is included in this PR.
* `assert_*!()` macro coverage can appear covered if followed by another
`assert_*!()` macro. Normally they appear uncovered. I submitted a new
Issue #84561, and added a coverage test to demonstrate this issue.
|
|
Implement a lint that highlights all moves larger than a configured limit
Tracking issue: #83518
[MCP 420](https://github.com/rust-lang/compiler-team/issues/420) still ~blazing~ in progress
r? ```@pnkfelix```
The main open issue I see with this minimal impl of the feature is that the lint is immediately "stable" (so it can be named on stable), even if it is never executed on stable. I don't think we have the concept of unstable lint names or hiding lint names without an active feature gate, so that would be a bigger change.
|
|
|
|
|
|
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`.
|
|
|
|
|
|
|
|
|
|
Found with https://github.com/est31/warnalyzer.
Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
wants to use it in the future?
- Don't change rustc_serialize
I plan to scrap most of the json module in the near future (see
https://github.com/rust-lang/compiler-team/issues/418) and fixing the
tests needed more work than I expected.
TODO: check if any of the comments on the deleted code should be kept.
|