| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add migration lint for 2024 prelude additions
This adds the migration lint for the newly ambiguous methods `poll` and `into_future`. When these methods are used on types implementing the respective traits, it will be ambiguous in the future, which can lead to hard errors or behavior changes depending on the exact circumstances.
tracked by #121042
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
r? compiler-errors as the method prober
|
|
This adds the migration lint for the newly ambiguous methods `poll` and
`into_future`. When these methods are used on types implementing the
respective traits, it will be ambiguous in the future, which can lead to
hard errors or behavior changes depending on the exact circumstances.
|
|
Rollup of 5 pull requests
Successful merges:
- #127853 (`#[naked]`: report incompatible attributes)
- #128276 (Add a README to rustbook to explain its purpose)
- #128279 (Stabilize `is_sorted`)
- #128282 (bitwise and bytewise methods on `NonZero`)
- #128285 (rustc book: document how the RUST_TARGET_PATH variable is used)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustc book: document how the RUST_TARGET_PATH variable is used
based on the module comment in
rust/compiler/rustc_target/src/spec/mod.rs
Fixes #128280
|
|
bitwise and bytewise methods on `NonZero`
Implementation for `nonzero_bitwise`
Tracking issue #128281
ACP https://github.com/rust-lang/libs-team/issues/413
|
|
Stabilize `is_sorted`
Closes: https://github.com/rust-lang/rust/issues/53485.
~~Question: does~~ https://github.com/rust-lang/rust/blob/8fe0c753f23e7050b87a444b6622caf4d2272d5d/compiler/rustc_lint_defs/src/builtin.rs#L1986-L1994 ~~need a new example?~~
edit: It causes a test failure and needs to be changed anyway.
``@rustbot`` label: +T-libs-api
r? libs-api
|
|
Add a README to rustbook to explain its purpose
This adds a README to the rustbook tool to help explain what it is for and how to use it.
|
|
`#[naked]`: report incompatible attributes
tracking issue: https://github.com/rust-lang/rust/issues/90957
this is a re-implementation of https://github.com/rust-lang/rust/pull/93809 by ``@bstrie`` which was closed 2 years ago due to inactivity.
This PR takes some of the final comments into account, specifically providing a little more context in error messages, and using an allow list to determine which attributes are compatible with `#[naked]`.
Notable attributes that are incompatible with `#[naked]` are:
* `#[inline]`
* `#[track_caller]`
* ~~`#[target_feature]`~~ (this is now allowed, see PR discussion)
* `#[test]`, `#[ignore]`, `#[should_panic]`
These attributes just directly conflict with what `#[naked]` should do.
Naked functions are still important for systems programming, embedded, and operating systems, so I'd like to move them forward.
|
|
r=Noratrieb
trans her gender
CC https://github.com/rust-lang/team/pull/1511
r? `@Noratrieb`
|
|
Migrate `static-dylib-by-default`, `sanitizer-dylib-link`, `sanitizer-cdylib-link` and `sanitizer-staticlib-link` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: x86_64-msvc
try-job: armhf-gnu
try-job: test-various
try-job: i686-msvc
try-job: x86_64-mingw
try-job: x86_64-gnu-llvm-18
|
|
based on the module comment in
rust/compiler/rustc_target/src/spec/mod.rs
Fixes #128280
|
|
CC https://github.com/rust-lang/team/pull/1511
|
|
Update cargo
14 commits in 5f6b9a92201d78af75dc24f14662c3e2dacbbbe1..b5d44db1daf0469b227a6211b987162a39a54730
2024-07-19 18:09:17 +0000 to 2024-07-26 21:27:12 +0000
- Package workspaces (rust-lang/cargo#13947)
- test: migrate messages to snapbox (rust-lang/cargo#14242)
- chore: Update dependencies (rust-lang/cargo#14299)
- fix: remove rustc probe for `--check-cfg` support (rust-lang/cargo#14302)
- Misc test clean up (rust-lang/cargo#14297)
- Don't downgrade on prerelease `VersionReq` when update with --breaking. (rust-lang/cargo#14250)
- test: Migrate some json tests to snapbox (rust-lang/cargo#14293)
- Revert "fix: Ensure dep/feature activates the dependency on 2024" (rust-lang/cargo#14295)
- chore: bump cargo-test-support to 0.4.0 (rust-lang/cargo#14286)
- Bump to 0.83.0; update changelog (rust-lang/cargo#14285)
- Improved error message when `update --breaking` invalid spec. (rust-lang/cargo#14279)
- docs(test): Expand documentation of cargo-test-support (rust-lang/cargo#14272)
- test: Fix some test based on rustc version (rust-lang/cargo#14282)
- Use `Rc` instead of `Arc` for storing rustflags (rust-lang/cargo#14273)
r? ghost
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #125897 (from_ref, from_mut: clarify documentation)
- #128207 (improve error message when `global_asm!` uses `asm!` options)
- #128241 (Remove logic to suggest clone of function output)
- #128259 ([illumos/solaris] set MSG_NOSIGNAL while writing to sockets)
- #128262 (Delete `SimplifyArmIdentity` and `SimplifyBranchSame` tests)
- #128266 (update `rust.channel` default value documentation)
- #128267 (Add rustdoc GUI test to check title with and without search)
- #128271 (Disable jump threading of float equality)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Nilstrieb:jump-into-a-can-of-worms-called-float-equality, r=compiler-errors
Disable jump threading of float equality
Jump threading stores values as `u128` (`ScalarInt`) and does its comparisons for equality as integer comparisons.
This works great for integers. Sadly, not everything is an integer.
Floats famously have wonky equality semantcs, with `NaN!=NaN` and `0.0 == -0.0`. This does not match our beautiful integer bitpattern equality and therefore causes things to go horribly wrong.
While jump threading could be extended to support floats by remembering that they're floats in the value state and handling them properly, it's signficantly easier to just disable it for now.
fixes #128243
|
|
Add rustdoc GUI test to check title with and without search
Follow-up of https://github.com/rust-lang/rust/pull/128210.
r? `@notriddle`
|
|
update `rust.channel` default value documentation
self-explanatory
Resolves #128258
r? dtolnay
|
|
Delete `SimplifyArmIdentity` and `SimplifyBranchSame` tests
These two passes have already been deleted in #107256. I'm not sure why tidy didn't catch it.
As regression tests, I didn't delete `tests/ui/mir/issue-66851.rs` and `tests/ui/mir/simplify-branch-same.rs`.
r? compiler
|
|
[illumos/solaris] set MSG_NOSIGNAL while writing to sockets
Both these platforms have MSG_NOSIGNAL available, and we should set it for socket writes in the event that the SIGPIPE handler has been reset to SIG_DFL (i.e. terminate the process).
I've verified via a quick program at
https://github.com/sunshowers/msg-nosignal-test/ that even when the SIGPIPE handler is reset to SIG_DFL, writes to closed TCP sockets now error out with EPIPE. (Under ordinary circumstances UDP writes won't cause MSG_NOSIGNAL.)
However, I couldn't find any existing tests which verified the MSG_NOSIGNAL behavior.
|
|
Remove logic to suggest clone of function output
I can't exactly tell, but I believe that this suggestion is operating off of a heuristic that the lifetime of a function's input is correlated with the lifetime of a function's output in such a way that cloning would fix an error. I don't think that actually manages to hit the bar of "actually provides useful suggestions" most of the time.
Specifically, I've hit false-positives due to this suggestion *twice* when fixing ICEs in the compiler, so I don't think it's worthwhile having this logic around. Neither of the two affected UI tests are actually fixed by the suggestion.
|
|
improve error message when `global_asm!` uses `asm!` options
specifically, what was
error: expected one of `)`, `att_syntax`, or `raw`, found `preserves_flags`
--> $DIR/bad-options.rs:45:25
|
LL | global_asm!("", options(preserves_flags));
| ^^^^^^^^^^^^^^^ expected one of `)`, `att_syntax`, or `raw`
is now
error: the `preserves_flags` option cannot be used with `global_asm!`
--> $DIR/bad-options.rs:45:25
|
LL | global_asm!("", options(preserves_flags));
| ^^^^^^^^^^^^^^^ the `preserves_flags` option is not meaningful for global-scoped inline assembly
mirroring the phrasing of the [reference](https://doc.rust-lang.org/reference/inline-assembly.html#options).
This is also a bit of a refactor for a future `naked_asm!` macro (for use in `#[naked]` functions). Currently this sort of error can come up when switching from inline to global asm, or when a user just isn't that experienced with assembly. With `naked_asm!` added to the mix hitting this error is more likely.
|
|
from_ref, from_mut: clarify documentation
This was brought up [here](https://github.com/rust-lang/rust/issues/56604#issuecomment-2143193486). The domain of quantification is generally always constrained by the type in the type signature, and I am not sure it's always worth spelling that out explicitly as that makes things exceedingly verbose. But since this was explicitly brought up, let's clarify.
|
|
|
|
|
|
|
|
build-manifest: Allow building manifests for formats that only have xz compression
|
|
|
|
Jump threading stores values as `u128` (`ScalarInt`) and does its
comparisons for equality as integer comparisons.
This works great for integers. Sadly, not everything is an integer.
Floats famously have wonky equality semantcs, with `NaN!=NaN` and
`0.0 == -0.0`. This does not match our beautiful integer bitpattern
equality and therefore causes things to go horribly wrong.
While jump threading could be extended to support floats by remembering
that they're floats in the value state and handling them properly,
it's signficantly easier to just disable it for now.
|
|
|
|
r=petrochenkov
Make `missing_fragment_specifier` an error in edition 2024
`missing_fragment_specifier` has been a future compatibility warning since 2017. Uplifting it to an unconditional hard error was attempted in 2020, but eventually reverted due to fallout.
Make it an error only in edition >= 2024, leaving the lint for older editions. This change will make it easier to support more macro syntax that relies on usage of `$`.
Fixes <https://github.com/rust-lang/rust/issues/40107>
---
It is rather late for the edition but since this change is relatively small, it seems worth at least bringing up. This follows a brief [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/268952-edition/topic/.60.20DBD.20-.3E.20hard.20error) (cc `@tmandry).`
Making this an edition-dependent lint has come up before but there was not a strong motivation. I am proposing it at this time because this would simplify the [named macro capture groups](https://github.com/rust-lang/rfcs/pull/3649) RFC, which has had mildly positive response, and makes use of new `$` syntax in the matcher. The proposed syntax currently parses as metavariables without a fragment specifier; this warning is raised, but there are no errors.
It is obviously not known that this specific RFC will eventually be accepted, but forbidding `missing_fragment_specifier` should make it easier to support any new syntax in the future that makes use of `$` in different ways. The syntax conflict is also not impossible to overcome, but making it clear that unnamed metavariables are rejected makes things more straightforward and should allow for better diagnostics.
`@Mark-Simulacrum` suggested making this forbid-by-default instead of an error at https://github.com/rust-lang/rust/issues/40107#issuecomment-761727885, but I don't think this would allow the same level of syntax flexibility.
It is also possible to reconsider making this an unconditional error since four years have elapsed since the previous attempt, but this seems likely to hit the same pitfalls. (Possibly worth a crater run?)
Tracking:
- https://github.com/rust-lang/rust/issues/128143
|
|
|
|
- merge error codes
- use attribute name that is incompatible in error message
- add test for conditional incompatible attribute
- add `linkage` to the allowlist
|
|
|
|
Allow optimizing `u32::from::<char>`.
Extracted from https://github.com/rust-lang/rust/pull/124307.
This allows optimizing the panicking branch in the `escape_unicode` function, see https://rust.godbolt.org/z/61YhKrhvP.
|
|
`missing_fragment_specifier` has been a future compatibility warning
since 2017. Uplifting it to an unconditional hard error was attempted in
2020, but eventually reverted due to fallout.
Make it an error only in edition >= 2024, leaving the lint for older
editions. This change will make it easier to support more macro syntax
that relies on usage of `$`.
Fixes <https://github.com/rust-lang/rust/issues/40107>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Document 0x10.checked_shl(BITS - 1) does not overflow
Not obvious.
|
|
|
|
Always set `result` during `finish()` in debug builders
Most functions for format builders set `self.result` after writing strings. This ensures that any further writing fails immediately rather than trying to write again.
A few `.finish()` methods and the `.finish_non_exhaustive` did have this same behavior, so update the remaining `.finish()` methods to make it consistent here.
|
|
Both these platforms have MSG_NOSIGNAL available, and we should set it for
socket writes in the event that the SIGPIPE handler has been reset to SIG_DFL
(i.e. terminate the process).
I've verified via a quick program at
https://github.com/sunshowers/msg-nosignal-test/ that even when the SIGPIPE
handler is reset to SIG_DFL, writes to closed sockets now error out with EPIPE.
(Under ordinary circumstances UDP writes won't cause MSG_NOSIGNAL.)
|
|
Rollup of 9 pull requests
Successful merges:
- #124941 (Stabilize const `{integer}::from_str_radix` i.e. `const_int_from_str`)
- #128201 (Implement `Copy`/`Clone` for async closures)
- #128210 (rustdoc: change title of search results)
- #128223 (Refactor complex conditions in `collect_tokens_trailing_token`)
- #128224 (Remove unnecessary range replacements)
- #128226 (Remove redundant option that was just encoding that a slice was empty)
- #128227 (CI: do not respect custom try jobs for unrolled perf builds)
- #128229 (Improve `extern "<abi>" unsafe fn()` error message)
- #128235 (Fix `Iterator::filter` docs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Not obvious.
|
|
Fix `Iterator::filter` docs
Small fix to add code formatting around `Iterator::filter` `true` return type
|
|
Improve `extern "<abi>" unsafe fn()` error message
These errors were already reported in #87217, and fixed by #87235 but missed the case of an explicit ABI.
This PR does not cover multiple keywords like `extern "C" pub const unsafe fn()`, but I don't know what a good way to cover this would be. It also seems rarer than `extern "C" unsafe` which I saw happen a few times in workshops.
|
|
CI: do not respect custom try jobs for unrolled perf builds
Before this PR, if a pull request merged in a rollup had some `try-job` annotations, the unrolled perf builds were running the custom try jobs instead of the default job, which was wrong.
Found out [here](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/try-perf.20jobs.20respect.20try-job.20annotations).
|
|
Remove redundant option that was just encoding that a slice was empty
There is already a sanity check ensuring we don't put empty attribute lists into the HIR:
https://github.com/rust-lang/rust/blob/6ef11b81c2c02c3c4b7556d1991a98572fe9af87/compiler/rustc_ast_lowering/src/lib.rs#L661-L667
|
|
Remove unnecessary range replacements
This PR removes an unnecessary range replacement in `collect_tokens_trailing_token`, and does a couple of other small cleanups.
r? ````@petrochenkov````
|
