| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Require stable/unstable annotations for the constness of all stable fns with a const modifier
r? @RalfJung @Centril
Every `#[stable]` const fn now needs either a `#[rustc_const_unstable]` attribute or a `#[rustc_const_stable]` attribute. You can't silently stabilize the constness of a function anymore.
|
|
|
|
functions with a `const` modifier
|
|
This commit builds on #65501 continue to simplify the build system and
compiler now that we no longer have multiple LLVM backends to ship by
default. Here this switches the compiler back to what it once was long
long ago, which is linking LLVM directly to the compiler rather than
dynamically loading it at runtime. The `codegen-backends` directory of
the sysroot no longer exists and all relevant support in the build
system is removed. Note that `rustc` still supports a dynamically loaded
codegen backend as it did previously, it just no longer supports
dynamically loaded codegen backends in its own sysroot.
Additionally as part of this the `librustc_codegen_llvm` crate now once
again explicitly depends on all of its crates instead of implicitly
loading them through the sysroot. This involved filling out its
`Cargo.toml` and deleting all the now-unnecessary `extern crate`
annotations in the header of the crate. (this in turn required adding a
number of imports for names of macros too).
The end results of this change are:
* Rustbuild's build process for the compiler as all the "oh don't forget
the codegen backend" checks can be easily removed.
* Building `rustc_codegen_llvm` is much simpler since it's simply
another compiler crate.
* Managing the dependencies of `rustc_codegen_llvm` is much simpler since
it's "just another `Cargo.toml` to edit"
* The build process should be a smidge faster because there's more
parallelism in the main rustc build step rather than splitting
`librustc_codegen_llvm` out to its own step.
* The compiler is expected to be slightly faster by default because the
codegen backend does not need to be dynamically loaded.
* Disabling LLVM as part of rustbuild is still supported, supporting
multiple codegen backends is still supported, and dynamic loading of a
codegen backend is still supported.
|
|
|
|
Put back tidy check on error codes
I just realized that the tidy checks were not run anymore on the error code long explanations. This add it back.
cc @Dylan-DPC
r? @Mark-Simulacrum
|
|
|
|
tidy: Accommodate rustfmt's preferred layout of stability attributes
Previously tidy would require that the `feature = "name_of_feature"` part of the stability attribute was on the same line as the `#[stable(` / `#[unstable(` opening part of the attribute, and that `)]` was on the same line as the last key-value pair.
That didn't work with rustfmt's preferred layout of long attributes, which is like:
```rust
#[unstable(
feature = "c_variadic",
reason = "the `c_variadic` feature has not been properly tested on \
all supported platforms",
issue = "44930"
)]
```
|
|
Rollup of 7 pull requests
Successful merges:
- #65613 (Preserve whitespace inside one-backtick codeblocks)
- #66512 (Add unix::process::CommandExt::arg0)
- #66569 (GitHub Actions: preparations, part 1)
- #66678 (Remove useless line for error index generation)
- #66684 (Drive-by cleanup in region naming)
- #66694 (Add some comments to panic runtime)
- #66698 (tidy: Remove unused import)
Failed merges:
r? @ghost
|
|
|
|
Previously tidy would require that the `feature = "name_of_feature"`
part of the stability attribute was on the same line as the `#[stable(`
/ `#[unstable(` opening part of the attribute, and that `)]` was on the
same line as the last key-value pair.
That didn't work with rustfmt's preferred layout of long attributes,
which is like:
#[unstable(
feature = "c_variadic",
reason = "the `c_variadic` feature has not been properly tested on \
all supported platforms",
issue = "44930"
)]
|
|
|
|
|
|
|
|
|
|
It remains as a comment in `error_codes.rs` for consistency with
other unused errors.
|
|
|
|
With #65251 landed there's no need to build two LLVM backends and ship
them with rustc, every target we have now uses the same LLVM backend!
This removes the `src/llvm-emscripten` submodule and additionally
removes all support from rustbuild for building the emscripten LLVM
backend. Multiple codegen backend support is left in place for now, and
this is intended to be an easy 10-15 minute win on CI times by avoiding
having to build LLVM twice.
|
|
|
|
|
|
This attribute causes DOT files to be generated in the top-level
directory. It is intended to be used only temporarily and should never
appear on master.
This will prevent #65071 from occurring again.
|
|
Add check for missing tests for error codes
Fixes #64811.
r? @Mark-Simulacrum
|
|
|
|
|
|
|
|
Add E0734 and its long explanation
Part of https://github.com/rust-lang/rust/issues/61137
|
|
|
|
|
|
|
|
Migrate internal diagnostic registration to macro_rules
Review is best done commit-by-commit.
Fixes #64132.
|
|
Use wasi crate for Core API
Blocked by: CraneStation/rust-wasi#5
Blocks: rust-lang/libc#1461
cc @sunfishcode @alexcrichton
|
|
The global restriction is 100, but since error codes are printed out via
--explain we want to restrict them to just 80 columns.
|
|
|
|
Strip code to the left and right in diagnostics for long lines
Fix #62999.
|
|
|
|
|
|
Feature gate definitions were split into multiple files in #63824 but
tidy kept reporting the hard-coded path. Now, it shows the full path
to the correct file.
|
|
bootstrap: Merge the libtest build step with libstd
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
|
|
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
|
|
|
|
|
|
Unconfigure compiler unit test files during normal build
I haven't touched libstd though, it had a lot of tests and I'm not sure the people maintaining it want this.
Closes https://github.com/rust-lang/rust/issues/61097
r? @Mark-Simulacrum
|
|
Remove additional libcore-like restrictions from liballoc, turns out the testing works ok if the tests are a part of liballoc itself.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
