| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add a tidy check for files with over 3,000 lines
Files with a large number of lines can cause issues in GitHub (e.g. https://github.com/rust-lang/rust/issues/60015) and also tend to be indicative of opportunities to refactor into less monolithic structures.
This adds a new check to tidy to warn against files that have more than 3,000 lines, as suggested in https://github.com/rust-lang/rust/issues/60015#issuecomment-483868594. (This number was chosen fairly arbitrarily as a reasonable indicator of size.) This check can be ignored with `// ignore-tidy-filelength`.
Existing files with greater than 3,000 lines currently ignore the check, but this helps us spot when files are getting too large. (We might try to split up all files larger than this in the future, as in https://github.com/rust-lang/rust/issues/60015).
|
|
Chalkify: Add builtin Copy/Clone
r? @nikomatsakis
|
|
|
|
|
|
Fixes an ICE for the following code:
fn foo(_ : &()) {}
static X: fn(&'static ()) = foo;
|
|
|
|
Warn when ignore-tidy-linelength is present, but no lines are too long
It's easy for a `// ignore-tidy-linelength` to be added when there is a genuine need to ignore a file's line length, but then after refactoring the need is gone, but the tidy directive is not removed. This means that in the future, further editing may accidentally add unnecessarily long lines. This change forces `// ignore-tidy-linelength` to be used exactly when necessary, to make sure such changes are intentional.
|
|
Warn on unused results for operation methods on nums
From a suggestion by @llogiq
Adds a `#[must_use]` attribute to operation methods on integers that take self by value as the first operand and another value as the second. It makes it clear that these methods return the result of the operation instead of mutating `self`, which is the source of a rather embarrassing bug I had in a codebase of mine recently...
As an example:
```rust
struct Int {
value: i64,
}
impl Int {
fn add(&mut self, other: i64) {
self.value.wrapping_add(other);
}
}
```
Will produce a warning like:
```
warning: unused return value of `core::num::<impl i64>::wrapping_add` that must be used
--> src/main.rs:7:7
|
7 | self.value.wrapping_add(other);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(unused_must_use)] on by default
= note: this returns the result of the operation, without modifying the original
```
If this is something we're on board with, we could do something similar for `f32` and `f64` too. There are probably other methods on integers that make sense.
|
|
[wg-async-await] Drop `async fn` arguments in async block
Fixes #54716.
This PR modifies the HIR lowering (and some other places to make this work) so that unused arguments to a async function are always dropped inside the async move block and not at the end of the function body.
```
async fn foo(<pattern>: <type>) {
async move {
}
} // <-- dropped as you "exit" the fn
// ...becomes...
fn foo(__arg0: <ty>) {
async move {
let <pattern>: <ty> = __arg0;
} // <-- dropped as you "exit" the async block
}
```
However, the exact ordering of drops is not the same as a regular function, [as visible in this playground example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=be39af1a58e5d430be1eb3c722cb1ec3) - I believe this to be an unrelated issue. There is a [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/187312-t-compiler.2Fwg-async-await/topic/.2354716.20drop.20order) for this.
r? @cramertj
cc @nikomatsakis
|
|
This commit introduces a `assert_drop_order_after_poll` helper function
to the test case for this case to reduce repetitive noise and documents
what each function aims to test.
|
|
|
|
Disallow double trailing newlines in tidy
This wasn't done previously in https://github.com/rust-lang/rust/pull/47064#issuecomment-354533010 as it affected too many files, but I think it's best to fix it now so that the number of files with double trailing newlines doesn't keep increasing.
r? kennytm
|
|
|
|
|
|
|
|
This commit extends the previous commit to apply to trait methods as
well as free functions.
|
|
This tests that async functions drop parameters in the same order as
regular functions.
|
|
compiletest normalization: preserve non-JSON lines such as ICEs
Currently, every non-JSON line from stderr gets normalized away when compiletest normalizes the output. In particular, ICEs get normalized to the empty output. That does not seem desirable, so this changes normalization to preserve non-JSON lines instead.
Also see https://github.com/laumann/compiletest-rs/issues/169: because of that bug, Miri currently *looks* green in the toolstate, but some tests ICE. That same bug is likely no longer present in latest compiletest because the error code gets checked separately, but it still seems like a good idea to also make sure that ICEs are considered stderr output:
This change found an accidental user-visible `error!` in CTFE validation (fixed), and a non-deterministic panic when there are two `main` symbols (not fixed, no idea where this comes from). Both got missed before because non-JSON output got ignored.
|
|
Add must_use annotations to Result::is_ok and is_err
Discussed in #59610
|
|
|
|
Stabilize the `alloc` crate.
This implements RFC 2480:
* https://github.com/rust-lang/rfcs/pull/2480
* https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md
Closes https://github.com/rust-lang/rust/issues/27783
|
|
This implements RFC 2480:
* https://github.com/rust-lang/rfcs/pull/2480
* https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md
Closes https://github.com/rust-lang/rust/issues/27783
|
|
|
|
|
|
|
|
|
|
Future-proof the Futures API
cc https://github.com/rust-lang/rust/issues/59113, @carllerche, @rust-lang/libs
r? @withoutboats
|
|
|
|
Unsized rvalues: implement boxed closure impls. (2nd try)
This is a rebase of S-blocked-closed PR #55431 to current master. LLVM has moved forward since then, so maybe we can check whether the new LLVM 8.0 version unblocked this work.
|
|
|
|
|
|
This commit removes usage of `Once` from the internal implementation of
time utilities on OSX and Windows. It turns out that we accidentally hit
a deadlock today (#59020) via events that look like:
* A thread invokes `park_timeout`
* Internally, only on OSX, `park_timeout` calls `Instant::elapsed`
* Inside of `Instant::elapsed` on OSX we enter a `Once` to initialize
global timer data
* Inside of `Once`, it attempts to `park`
This means on the same stack frame, when there's contention, we're
calling `park` from inside `park_timeout`, causing a deadlock!
The solution implemented in this commit was to remove usage of `Once`
and instead just do a small dance with atomics. There's no real need we
need to guarantee that the global information is only learned once, only
that it's only *stored* once. This implementation may have multiple
threads invoke `mach_timebase_info`, but only one will store the global
information which will amortize the cost for all other threads.
A similar fix has been applied to windows to be uniform across our
implementations, but looking at the code on Windows no deadlock was
possible. This is purely just a consistency update for Windows and in
theory a slightly leaner implementation.
Closes #59020
|
|
Fix stack overflow when generating debuginfo for 'recursive' type
By using 'impl trait', it's possible to create a self-referential
type as follows:
fn foo() -> impl Copy { foo }
This is a function which returns itself.
Normally, the signature of this function would be impossible
to write - it would look like 'fn foo() -> fn() -> fn() ...'
e.g. a function which returns a function, which returns a function...
Using 'impl trait' allows us to avoid writing this infinitely long
type. While it's useless for practical purposes, it does compile and run
However, issues arise when we try to generate llvm debuginfo for such a
type. All 'impl trait' types (e.g. ty::Opaque) are resolved when we
generate debuginfo, which can lead to us recursing back to the original
'fn' type when we try to process its return type.
To resolve this, I've modified debuginfo generation to account for these
kinds of weird types. Unfortunately, there's no 'correct' debuginfo that
we can generate - 'impl trait' does not exist in debuginfo, and this
kind of recursive type is impossible to directly represent.
To ensure that we emit *something*, this commit emits dummy
debuginfo/type names whenever it encounters a self-reference. In
practice, this should never happen - it's just to ensure that we can
emit some kind of debuginfo, even if it's not particularly meaningful
Fixes #58463
|
|
resolve: collect trait aliases along with traits
It seems trait aliases weren't being collected as `TraitCandidates` in resolve, this should change that. (I can't compile the full compiler locally, so relying on CI...)
Fixes https://github.com/rust-lang/rust/issues/56485
r? @alexreg
|
|
async fn now lowers directly to an existential type declaration
rather than reusing the `impl Trait` return type lowering.
As part of this, it lowers all argument-position elided lifetimes
using the in-band-lifetimes machinery, creating fresh parameter
names for each of them, using each lifetime parameter as a generic
argument to the generated existential type.
This doesn't currently successfully allow multiple
argument-position elided lifetimes since `existential type`
doesn't yet support multiple lifetimes where neither outlive
the other. This requires a separate fix.
|
|
|
|
By using 'impl trait', it's possible to create a self-referential
type as follows:
fn foo() -> impl Copy { foo }
This is a function which returns itself.
Normally, the signature of this function would be impossible
to write - it would look like 'fn foo() -> fn() -> fn() ...'
e.g. a function which returns a function, which returns a function...
Using 'impl trait' allows us to avoid writing this infinitely long
type. While it's useless for practical purposes, it does compile and run
However, issues arise when we try to generate llvm debuginfo for such a
type. All 'impl trait' types (e.g. ty::Opaque) are resolved when we
generate debuginfo, which can lead to us recursing back to the original
'fn' type when we try to process its return type.
To resolve this, I've modified debuginfo generation to account for these
kinds of weird types. Unfortunately, there's no 'correct' debuginfo that
we can generate - 'impl trait' does not exist in debuginfo, and this
kind of recursive type is impossible to directly represent.
To ensure that we emit *something*, this commit emits dummy
debuginfo/type names whenever it encounters a self-reference. In
practice, this should never happen - it's just to ensure that we can
emit some kind of debuginfo, even if it's not particularly meaningful
Fixes #58463
|
|
match match match match match
|
|
Allow closure to unsafe fn coercion
Closes #57883
|
|
|
|
|
|
|
|
|
|
r=petrochenkov,QuietMisdreavus
RFC 2008: Enum Variants
Part of #44109. See [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rfc-2008/near/132663140) for previous discussion.
r? @petrochenkov
cc @nikomatsakis
|
|
Fix error in Rust 2018 + no_core environment
Minimized reproduction: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=5b9f6c3026ec9d856699fa6dbd4361f0
This is a fix for the error that occurred in #58702.
r? @Centril
|
|
This commit removes the check that disallows the `#[non_exhaustive]`
attribute from being placed on enum variants and removes the associated
tests.
Further, this commit lowers the visibility of enum variant constructors
when the variant is marked as non-exhaustive.
|
|
fs::copy() unix: set file mode early
A convenience method like fs::copy() should try to prevent pitfalls a
normal user doesn't think about.
In case of an empty umask, setting the file mode early prevents
temporarily world readable or even writeable files,
because the default mode is 0o666.
In case the target is a named pipe or special device node, setting the
file mode can lead to unwanted side effects, like setting permissons on
`/dev/stdout` or for root setting permissions on `/dev/null`.
copy_file_range() returns EINVAL, if the destination is a FIFO/pipe or
a device like "/dev/null", so fallback to io::copy, too.
Fixes: https://github.com/rust-lang/rust/issues/26933
Fixed: https://github.com/rust-lang/rust/issues/37885
|
|
adjust MaybeUninit API to discussions
uninitialized -> uninit
into_initialized -> assume_init
read_initialized -> read
set -> write
|
|
syntax: Remove warning for unnecessary path disambiguators
`rustfmt` is now stable and it removes unnecessary turbofishes, so removing the warning as discussed in https://github.com/rust-lang/rust/pull/43540 (where it was introduced).
One hardcoded warning less.
Closes https://github.com/rust-lang/rust/issues/58055
r? @nikomatsakis
|
|
|
