| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
rustc_scalar_valid_range_{start,end}.
|
|
|
|
|
|
names
|
|
|
|
|
|
(Update: Fixed test; revision is meant to introduce compile-failure, w/o ICE.)
|
|
rustc: Implement incremental "fat" LTO
Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!
This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.
cc #57968
cc rust-lang/cargo#6643
|
|
Fix #54242
r? @michaelwoerister
|
|
Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!
This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.
cc #57968
cc rust-lang/cargo#6643
|
|
|
|
|
|
|
|
|
|
|
|
This commit moves well-formedness check for the
`UserTypeAnnotation::Ty(..)` case from always running to only when the
code is reachable. This solves the ICE that resulted from
`src/test/ui/issue-54943-1.rs` (a minimal repro of `dropck-eyepatch`
run-pass tests that failed).
The main well-formedness check that was intended to be run despite
unreachable code still is, that being the
`UserTypeAnnotation::TypeOf(..)` case. Before this PR, the other case
wasn't being checked at all.
It is possible to fix this ICE while still always checking
well-formedness for the `UserTypeAnnotation::Ty(..)` case but that
solution will ICE in unreachable code for that case, the diff for
that change [can be found here](0).
[0]: https://gist.github.com/davidtwco/f9751ffd9c0508f7251c0f17adc3af53
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
This commit adds an `ImplicitSelfKind` to the HIR and the MIR that keeps
track of whether a implicit self argument is immutable by-value, mutable
by-value, immutable reference or mutable reference so that the addition
of the `mut` keyword can be suggested for the immutable by-value case.
|
|
test incremental ThinLTO.
|
|
stabilize outlives requirements
https://github.com/rust-lang/rust/issues/44493
r? @nikomatsakis
|
|
Co-authored-by: nikomatsakis
|
|
We are now carrying the user-given type through MIR, so it makes sense
that this would change the hash.
|
|
|
|
|
|
|
|
|
|
This commit transitions definitions of custom sections on the wasm target from
the unstable `#[wasm_custom_section]` attribute to the
already-stable-for-other-targets `#[link_section]` attribute. Mostly the same
restrictions apply as before, except that this now applies only to statics.
Closes #51088
|
|
This reverts commit 2c5cd9ce53d2d25041db0cb02b40ba460ffa8908.
|
|
|
|
|
|
Add existential type definitions
Note: this does not allow creating named existential types, it just desugars `impl Trait` to a less (but still very) hacky version of actual `existential type` items.
r? @nikomatsakis
|
|
|
|
|
|
Make the `const_err` lint `deny`-by-default
At best these things are runtime panics (debug mode) or overflows (release mode). More likely they are public constants that are unused in the crate declaring them.
This is not a breaking change, as dependencies won't break and root crates can `#![warn(const_err)]`, though I don't know why anyone would do that.
|
|
|
|
|
|
|
|
|
