| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix invalid lint_node_id being put on a removed stmt
This pull-request remove a invalid `assign_id!` being put on an stmt node.
The problem is that this node is being removed away by a cfg making it unreachable when triggering a buffered lint.
The comment in the other match arm already tell to not assign a id because it could have a `#[cfg()]` so this is just respecting the comment.
Fixes https://github.com/rust-lang/rust/issues/94523
r? ```````@petrochenkov```````
|
|
rustdoc: Add test for higher kinded functions generated by macros
Fixes #75564.
The problem has been solved apparently so adding a test to prevent a regression.
r? ```@notriddle```
|
|
|
|
r=wesleywiser
Implementation of the `expect` attribute (RFC 2383)
This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute.
### Example
#### input
```rs
// required feature flag
#![feature(lint_reasons)]
#[expect(unused_mut)] // Will warn about an unfulfilled expectation
#[expect(unused_variables)] // Will be fulfilled by x
fn main() {
let x = 0;
}
```
#### output
```txt
warning: this lint expectation is unfulfilled
--> $DIR/trigger_lint.rs:3:1
|
LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation
| ^^^^^^^^^^
|
= note: `#[warn(unfulfilled_lint_expectations)]` on by default
```
### Implementation
This implementation introduces `Expect` as a new lint level for diagnostics, which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query.
The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission, while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise, a new lint message will be emitted.
The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage, it's not possible to create a stable identifier. The level instead stores an unstable identifier, which is later converted to a stable `LintExpectationId`.
### Followup TO-DOs
All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them:
* [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute.
* This should be easily possible, but I wanted to get some feedback before putting more work into this.
* This could also be done in a new PR to not add to much more code to this one
* [ ] Update unstable documentation to reflect this change.
* [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics)
### Open questions
I also have a few open questions where I would like to get feedback on:
1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091), suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion, or was this discarded with the merge of the RFC?
2. How should the expect attribute deal with the new `force-warn` lint level?
---
This approach was inspired by a discussion with `@LeSeulArtichaut.`
RFC tracking issue: #54503
Mentoring/Implementation issue: #85549
[`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html
[`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html
[`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels
[`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html
[`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html
|
|
Co-authored-by: Scott McMurray <scottmcm@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
First, this reverts the `CFLAGS`/`CXXFLAGS` of #93918. Those flags are
already read by `cc` and populated into `Build` earlier on in the
process. We shouldn't be overriding that based on `CFLAGS`, since `cc`
also respects overrides like `CFLAGS_{TARGET}` and `HOST_CFLAGS`, which
we want to take into account.
Second, this adds the same capability to specify target-specific
versions of `LDFLAGS` as we have through `cc` for the `C*` flags:
https://github.com/alexcrichton/cc-rs#external-configuration-via-environment-variables
Note that this also necessitated an update to compiletest to treat
CXXFLAGS separately from CFLAGS.
|
|
It isn't used anymore by rustdoc
|
|
|
|
|
|
Miri/CTFE: properly treat overflow in (signed) division/rem as UB
To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.
r? `@oli-obk`
|
|
|
|
|
|
|
|
Use ? operator in one instance instead of manual match
As suggested [here](https://github.com/rust-lang/rust/pull/94139#discussion_r818102403).
r? `@notriddle`
|
|
Move transmute_undefined_repr back to nursery again
This PR reapplies #94014, which was reverted unintentionally I think by #94329. The combination of https://github.com/rust-lang/rust-clippy/pull/8432 + https://github.com/rust-lang/rust-clippy/pull/8497 in clippy should prevent this from happening again.
r? `@Manishearth`
|
|
rustdoc: add test cases for hidden enum variants
|
|
|
|
|
|
Unused doc comments blocks
Fixes #77030.
|
|
r=michaelwoerister,davidtwco
Restore the local filter on mono item sorting
In `CodegenUnit::items_in_deterministic_order`, there's a comment that
only local HirIds should be taken into account, but #90408 removed the
`as_local` call that sets others to None. Restoring that check fixes the
s390x hangs seen in [RHBZ 2058803].
[RHBZ 2058803]: https://bugzilla.redhat.com/show_bug.cgi?id=2058803
|
|
Documentation was missed when demoting Windows XP to no_std only
After a quick discussion on #81250 which removed special casing for mutexes added [here](https://github.com/rust-lang/rust/commit/10b103af48368c5df644fa61dc417a36083922c8) to support Windows XP, we can't say that the standard library can build for it.
This change modifies the tier 3 non-ARM targets to show the standard library will no longer build for these and there is no work being done to change that.
|
|
Improve allowness of the unexpected_cfgs lint
This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.
Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.
Found while working on https://github.com/rust-lang/rust/pull/94298.
r? ````````@petrochenkov````````
|
|
Adt copy suggestions
Previously we've only suggested adding `Copy` bounds when the type being moved/copied is a type parameter (generic). With this PR we also suggest adding bounds when a type
- Can be copy
- All predicates that need to be satisfied for that are based on type params
i.e. we will suggest `T: Copy` for `Option<T>`, but won't suggest anything for `Option<String>`.
An example:
```rust
fn duplicate<T>(t: Option<T>) -> (Option<T>, Option<T>) {
(t, t)
}
```
New error (current compiler doesn't provide `help`:):
```text
error[E0382]: use of moved value: `t`
--> t.rs:2:9
|
1 | fn duplicate<T>(t: Option<T>) -> (Option<T>, Option<T>) {
| - move occurs because `t` has type `Option<T>`, which does not implement the `Copy` trait
2 | (t, t)
| - ^ value used here after move
| |
| value moved here
|
help: consider restricting type parameter `T`
|
1 | fn duplicate<T: Copy>(t: Option<T>) -> (Option<T>, Option<T>) {
| ++++++
```
Fixes #93623
r? ``````````@estebank``````````
``````````@rustbot`````````` label +A-diagnostics +A-suggestion-diagnostics +C-enhancement
----
I'm not at all sure if this is the right implementation for this kind of suggestion, but it seems to work :')
|
|
m-ou-se:compatible-variants-suggestion-with-desugaring, r=estebank
Compatible variants suggestion with desugaring
This fixes #90553 for `for` loops and other desugarings.
r? ```@estebank```
|
|
|
|
|
|
There's still open discussion if this lint is ready to be enabled by
default. We want to give us more time to figure this out and prevent
this lint from getting to stable as an enabled-by-default lint.
|
|
Error if submodule fetch fails.
In CI, if fetching a submodule fails, the script would exit successfully. Later parts of the build will fail due to the missing files, but it is a bit confusing, and I think it would be better to error out earlier.
The reason is that in bash, `wait` without arguments will exit 0 even if a background job exits with an error. The solution here is to wait on each individual job, which will return the exit code of the job.
This was encountered in #92177.
|
|
|
|
|
|
|
|
|
|
* Add test to expect and the forbid a lint (RFC 2383)
|
|
|
|
* Add UI tests with macros for the `expect` attribute (RFC-2383)
* Addressed review comments - mostly UI test updates (RFC-2383)
* Documented lint level attribute on macro not working bug (RFC-2383)
See `rust#87391`
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #94464 (Suggest adding a new lifetime parameter when two elided lifetimes should match up for traits and impls.)
- #94476 (7 - Make more use of `let_chains`)
- #94478 (Fix panic when handling intra doc links generated from macro)
- #94482 (compiler: fix some typos)
- #94490 (Update books)
- #94496 (tests: accept llvm intrinsic in align-checking test)
- #94498 (9 - Make more use of `let_chains`)
- #94503 (Provide C FFI types via core::ffi, not just in std)
- #94513 (update Miri)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
update Miri
Fixes https://github.com/rust-lang/rust/issues/94474
r? `@ghost`
|
|
Provide C FFI types via core::ffi, not just in std
Tracking issue: https://github.com/rust-lang/rust/issues/94501
The ability to interoperate with C code via FFI is not limited to crates
using std; this allows using these types without std.
The existing types in `std::os::raw` become type aliases for the ones in
`core::ffi`. This uses type aliases rather than re-exports, to allow the
std types to remain stable while the core types are unstable.
This also moves the currently unstable `NonZero_` variants and
`c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi`, while leaving
them unstable.
Historically, we didn't do this because these types are target-dependent.
However, `core` itself is also target-dependent. `core` should not call
any OS services, but it knows the target and the target's ABI.
|
|
tests: accept llvm intrinsic in align-checking test
This changed in upstream change https://reviews.llvm.org/D98152 (aka
https://github.com/llvm/llvm-project/commit/a266af721153fab6452094207b09ed265ab0be7b)
wherein LLVM got smarter about using intrinsics. As best I can tell the
change I've made here preserves the intent of the test on LLVM 14 and
before while also passing on LLVM 15 and later.
|
|
Update books
## nomicon
1 commits in 90993eeac93dbf9388992de92965f99cf6f29a03..f6d6126fc96ecf4a7f7d22da330df9506293b0d0
2022-02-13 12:44:12 +0900 to 2022-02-26 02:21:21 +0900
- ffi: explicitly declare hello_from_rust for C99 (rust-lang/nomicon#343)
## reference
20 commits in 70fc73a6b908e08e66aa0306856c5211312f6c05..9d289c05fce7254b99c6a0d354d84abb7fd7a032
2022-02-14 19:33:01 -0800 to 2022-02-23 08:58:20 -0800
- Fix typo in `functions.md` (rust-lang/reference#1173)
- Fix CI
- Unify global_asm/asm directive list
- Update src/inline-assembly.md
- Update src/inline-assembly.md
- Fix changes unintentional reverted in d5d3d80
- Add note about operand interpolations
- Sort lists, add syntax control directives
- Add another missed batch suggestion
- Add missed batch suggestion
- Apply suggestions from code review
- Add .type, .size, and .p2align
- Reformat directive lists
- Add `.inst` directive
- Add missing directives
- Add additional directives in use
- Add `.fill` directive
- Style fixes
- Fix code block
- Add supported Directives list
## book
13 commits in 67b768c0b660a069a45f0e5d8ae2f679df1022ab..3f255ed40b8c82a0434088568fbed270dc31bf00
2022-02-09 21:52:41 -0500 to 2022-02-27 21:26:12 -0500
- Add a back reference about enum variant initializer fns. Fixes rust-lang/book#800.
- Update ch01-03-hello-cargo.md
- ch03-05: Add definite article for the block of code
- Change variable names from "slice" to "values"
- Remove reference to advanced lifetime section that no longer exists
- Fix link to go to the right newtype section
- Remove confusing and redundant part of a sentence about newtypes
- Make transition less repetitive
- Correct wording about associated functions.
- Remove unnecessary extern crate proc_macro
- Clarify that this code is defining, not using a procedural macro
- Add manual regeneration steps for cargo new test
- Update Listing 11-1 to reflect current contents
## rust-by-example
11 commits in 18c0055b8aea49391e8f758a4400097999c9cf1e..2a928483a20bb306a7399c0468234db90d89afb5
2022-01-19 08:51:55 -0300 to 2022-02-28 11:36:59 -0300
- Update destructure_slice.md (rust-lang/rust-by-example#1513)
- Update iter_find.md (rust-lang/rust-by-example#1512)
- Add an example of collecting errors while iterating successes (rust-lang/rust-by-example#1509)
- Fix broken link on asm (rust-lang/rust-by-example#1508)
- Update abort_unwind.md (rust-lang/rust-by-example#1505)
- Remove duplicate text in asm.md (rust-lang/rust-by-example#1506)
- Improve asm clobber example (rust-lang/rust-by-example#1504)
- Add +1 to next_age (rust-lang/rust-by-example#1503)
- fix comment on into_iter() for arrays (rust-lang/rust-by-example#1502)
- Added new Rust 1.58 direct format args (rust-lang/rust-by-example#1501)
- documentation for cfg_panic (rust-lang/rust-by-example#1500)
## rustc-dev-guide
13 commits in 62f58394ba7b203f55ac35ddcc4c0b79578f5706..32f2a5b4e7545318846185198542230170dd8a42
2022-02-11 08:42:50 -0500 to 2022-03-01 10:45:24 -0600
- Add architecture suggestion for Apple silicon (rust-lang/rustc-dev-guide#1320)
- cargo timings has been stabilized (rust-lang/rustc-dev-guide#1319)
- Add known-bug header. (rust-lang/rustc-dev-guide#1311)
- Fix typo (rust-lang/rustc-dev-guide#1315)
- Typo (rust-lang/rustc-dev-guide#1313)
- instrument-coverage has been stabilized.
- symbol-mangling-version has been stabilized
- Fix `Ty` link (rust-lang/rustc-dev-guide#1308)
- Edit glossary (rust-lang/rustc-dev-guide#1302)
- Fix heading levels in the query chapter (rust-lang/rustc-dev-guide#1305)
- Fix link
- Edit "Queries" chapter (rust-lang/rustc-dev-guide#1301)
- Link to The Rust Performance Book (rust-lang/rustc-dev-guide#1300)
## edition-guide
1 commits in beea0a3cdc3885375342fd010f9ad658e6a5e09a..c55611dd6c58bdeb52423b5c52fd0f3c93615ba8
2021-12-05 07:06:45 -0800 to 2022-02-21 14:21:39 +0100
- Remove `+nightly` for `cargo new` (rust-lang/edition-guide#276)
|
|
r=notriddle
Fix panic when handling intra doc links generated from macro
Fixes #78591.
Fixes #92789.
r? ``@notriddle``
|
|
r=estebank
Suggest adding a new lifetime parameter when two elided lifetimes should match up for traits and impls.
Suggest adding a new lifetime parameter when two elided lifetimes should match up for functions in traits and impls.
Issue #94462
|
