| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Co-authored-by: Stephan Schauerte <stephan.schauerte@gmail.com>
|
|
|
|
Moved issue tests to subdirs and normalised names
Consistency, decluttering, ease of navigation :-)
r? @Centril
|
|
|
|
|
|
|
|
Deny the `overflowing_literals` lint for all editions
The `overflowing_literals` was made deny by default for the 2018 edition by #54507, however I'm not aware of any reason it can't be made deny by default for the 2015 edition as well.
|
|
Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
|
|
specify "upper camel case" in style lint
Also, fix an issue where internal upper case letters were converted to
lower case.
Fixes #57319.
|
|
Also, fix an issue where internal upper case letters were converted to
lower case.
|
|
|
|
|
|
This commit extends existing suggestions to prefix unused variable
bindings in match arms with an underscore so that it applies to all
patterns in a match arm.
|
|
make trait-aliases work across crates
This is rebase of a small part of @alexreg's PR #55994. It focuses just on the changes that integrate trait aliases properly into crate metadata, excluding the stylistic edits and the trait objects.
The stylistic edits I also rebased and can open a separate PR.
The trait object stuff I found challenging and decided it basically needed to be reimplemented. For now I've excluded it.
Since this is really @alexreg's work (I really just rebased) I am going to make it r=me once it is working.
Fixes #56488.
Fixes #57023.
|
|
|
|
Implement basic input validation for built-in attributes
Correct top-level shape (`#[attr]` vs `#[attr(...)]` vs `#[attr = ...]`) is enforced for built-in attributes, built-in attributes must also fit into the "meta-item" syntax (aka the "classic attribute syntax").
For some subset of attributes (found by crater run), errors are lowered to deprecation warnings.
NOTE: This PR previously included https://github.com/rust-lang/rust/pull/57367 as well.
|
|
Implement `check_attribute` to forbid `#[allow_internal_unsafe]`
Fixes #56768.
r? @oli-obk
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Alexander Regueiro <alexreg@me.com>
|
|
Use a structured suggestion and tighten the span to just the identifier.
|
|
Use a structured suggestion and tighten the span to just the identifier.
|
|
Use a structured suggestion and tighten the span to just the identifier.
|
|
|
|
|
|
|
|
|
|
|
|
Clearer error message for dead assign
I'm not that this is the right place for this (if it needs an RFC or not).
I had the problem where I misunderstood the compiler lint message https://github.com/rust-lang/rust/issues/56436 and other people seem to have had the same problem https://www.reddit.com/r/rust/comments/8cy9p4/value_assigned_to_is_never_read/.
I think this new wording might be slightly clearer (and help out beginners like me). I'm very new though, so there might be some nuance I'm missing that would make this more confusing or a bad idea for other reasons.
I thought I would create a PR to make it easy to change the code if the consensus was that it would make sense to make a change.
If this is the wrong place for this sort of thing I'll happily delete/move it.
|
|
r=zackmdavis
Fix private_no_mangle_fns message grammar
Simply changes "an warning" to "a warning" in the `private_no_mangle_fns` warning. I started getting this in some code after upgrading to 1.31.0.
|
|
|
|
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3
|
|
|
|
|
|
|
|
|
|
Rewrite `...` as `..=` as a `MachineApplicable` 2018 idiom lint
Fixes https://github.com/rust-lang/rust/issues/51043.
|
|
pnkfelix:remove-useless-revisions-marker-from-lint-unused-mut-variables, r=davidtwco
Removed unneeded instance of `// revisions` from a lint test
Removed an unneeded instance of `// revisions`; the compare-mode=nll shows the output is identical now.
cc #54528
|
|
Take supertraits into account when calculating associated types
Fixes #24010 and #23856. Applies to trait aliases too.
As a by-product, this PR also makes repeated bindings of the same associated item in the same definition a hard error. This was previously a warning with a note about it becoming a hard error in the future. See #50589 for more info.
I talked about this with @nikomatsakis recently, but only very superficially, so this shouldn't stop anyone from assigning it to themself to review and r+.
N.B. The "WIP" commits represent imperfect attempts to solve the problem just for trait objects, but I've left them in for reference for the sake of whomever is reviewing this.
CC @carllerche @theemathas @durka @mbrubeck
|
|
|
|
|
|
the output is identical now.
|
|
|
|
|
|
`rustc -O`.
(The fact that output differs under `opt-level=0` is an instance of #55757.)
|
