| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Adds --bless support to test/run-make-fulldeps
The ability to "bless" output for some of these tests is critical to
making it practical to adapt tests to unrelated changes.
This is needed for new coverage tests, as shown in PR #76004 .
r? @tmandry
FYI: @wesleywiser
|
|
The ability to "bless" output for some of these tests is critical to
making it practical to adapt tests to unrelated changes.
This is needed for new coverage tests, as shown in PR #75828 (or its
derivative).
|
|
In 2e6f2e885506ee4, we added a main function to the publish_toolstate.py script.
Unfortunately, we missed that the Python program implicitly declares global
variables in that code, which means that adding a function changes variable
scoping and breaks other code.
This commit avoids introducing that function and adds a warning to future
editors of the code.
|
|
Introduce expect snapshot testing library into rustc
Snapshot testing is a technique for writing maintainable unit tests.
Unlike usual `assert_eq!` tests, snapshot tests allow
to *automatically* upgrade expected values on test failure.
In a sense, snapshot tests are inline-version of our beloved
UI-tests.
Example:
A particular library we use, `expect_test` provides an `expect!`
macro, which creates a sort of self-updating string literal (by using
`file!` macro). Self-update is triggered by setting `UPDATE_EXPECT`
environmental variable (this info is printed during the test failure).
This library was extracted from rust-analyzer, where we use it for
most of our tests.
There are some other, more popular snapshot testing libraries:
* https://github.com/mitsuhiko/insta
* https://github.com/aaronabramov/k9
The main differences of `expect` are:
* first-class snapshot objects (so, tests can be written as functions,
rather than as macros)
* focus on inline-snapshots (but file snapshots are also supported)
* restricted feature set (only `assert_eq` and `assert_debug_eq`)
* no extra runtime (ie, no `cargo insta`)
See rust-analyzer/rust-analyzer#5101 for a
an extended comparison.
It is unclear if this testing style will stick with rustc in the long
run. At the moment, rustc is mainly tested via integrated UI tests.
But in the library-ified world, unit-tests will become somewhat more
important (that's why use use `rustc_lexer` library-ified library as
an example in this PR). Given that the cost of removal shouldn't be
too high, it probably makes sense to just see if this flies!
|
|
Stabilize Range[Inclusive]::is_empty
I would like to propose these two simple methods for stabilization:
- Knowing that a range is exhausted isn't otherwise trivial
- Clippy would like to suggest them, but had to do extra work to disable that path <https://github.com/rust-lang/rust-clippy/issues/3807> because they're unstable
- These work on `PartialOrd`, consistently with the stable `contains` method, and are thus more general than iterator-based approaches that need `Step`
- They've been unchanged for some time, and have picked up uses in the compiler
- Stabilizing them doesn't block any future iterator-based `is_empty` plans, as these inherent ones are preferred in name resolution
https://doc.rust-lang.org/nightly/std/ops/struct.Range.html#method.is_empty
https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html#method.is_empty
Closes #48111
|
|
bump tidy to cargo_metadata 0.11
Updates cargo_metadata in tidy's Cargo.toml from 0.9.1 to 0.11
Real version change 0.9.11 -> 0.11.1
https://github.com/oli-obk/cargo_metadata/compare/v0.9.1...v0.11.1
|
|
|
|
Snapshot testing is a technique for writing maintainable unit tests.
Unlike usual `assert_eq!` tests, snapshot tests allow
to *automatically* upgrade expected values on test failure.
In a sense, snapshot tests are inline-version of our beloved
UI-tests.
Example:
A particular library we use, `expect_test` provides an `expect!`
macro, which creates a sort of self-updating string literal (by using
`file!` macro). Self-update is triggered by setting `UPDATE_EXPECT`
environmental variable (this info is printed during the test failure).
This library was extracted from rust-analyzer, where we use it for
most of our tests.
There are some other, more popular snapshot testing libraries:
* https://github.com/mitsuhiko/insta
* https://github.com/aaronabramov/k9
The main differences of `expect` are:
* first-class snapshot objects (so, tests can be written as functions,
rather than as macros)
* focus on inline-snapshots (but file snapshots are also supported)
* restricted feature set (only `assert_eq` and `assert_debug_eq`)
* no extra runtime (ie, no `cargo insta`)
See https://github.com/rust-analyzer/rust-analyzer/pull/5101 for a
an extended comparison.
It is unclear if this testing style will stick with rustc in the long
run. At the moment, rustc is mainly tested via integrated UI tests.
But in the library-ified world, unit-tests will become somewhat more
important (that's why use use `rustc_lexer` library-ified library as
an example in this PR). Given that the cost of removal shouldn't be
too high, it probably makes sense to just see if this flies!
|
|
|
|
more tool clippy fixes
r? @Dylan-DPC
|
|
|
|
clippy::useless_format, clippy:::for_kv_map
|
|
|
|
clippy::single_char_pattern
|
|
|
|
|
|
compiletest: fix a couple clippy lint findings
|
|
|
|
Fixes clippy::redundant_static_lifetimes and clippy::toplevel_ref_arg
I also replaced some .expect("") calls with .unwrap()s since there was no message passed by the .expect() anyway.
|
|
Updates cargo_metadata in tidy's Cargo.toml from 0.9.1 to 0.11
Real version change 0.9.11 -> 0.11.1
https://github.com/oli-obk/cargo_metadata/compare/v0.9.1...v0.11.1
|
|
Capture tokens for Pat used in macro_rules! argument
This extends PR #73293 to handle patterns (Pat). Unlike expressions,
patterns do not support custom attributes, so we only need to capture
tokens during macro_rules! argument parsing.
|
|
Check that we don't use `Rvalue::Aggregate` after the deaggregator
fixes #75481
r? @wesleywiser
cc @RalfJung (modified the validator)
|
|
This extends PR #73293 to handle patterns (Pat). Unlike expressions,
patterns do not support custom attributes, so we only need to capture
tokens during macro_rules! argument parsing.
|
|
|
|
Cargo update (almost) all the things!
This runs `cargo update` on our dependency tree, bumping numerous crates. See details in the first commit of this PR.
Several updates were held back intentionally; version_check in particular landed a change in behavior in 0.9.2 (arguably a bug fix, but still will be split into a separate PR).
|
|
Promote missing_fragment_specifier to hard error
It has been deny_by_default since 2017 (and warned for some time
before that), so it seems reasonable to promote it.
The specific technical motivation to do this now is to remove a field
from `ParseSess` -- it is a global state, and global state makes
extracting libraries annoying.
Closes #40107
|
|
Per https://github.com/rust-lang/rust/pull/75555#issuecomment-675090858
Zlib license might be OK. "OR Apache-2.0 OR MIT" definitely is.
unicode-normalization depends on this and rustc_parse, clippy,
and many other things depend on unicode-normalization.
|
|
|
|
update miri
Fixes https://github.com/rust-lang/rust/issues/75630
Cc @rust-lang/miri r? @ghost
|
|
Use git for Rustfmt dependency of RLS
Closes #75442
r? @Mark-Simulacrum
cc @calebcartwright for changed rustfmt dep kind
|
|
treeify depends on an outdated version of clap, which will fail to compile
when we promote missing_fragment_specifier future compat lint to
error (ie, old clap contains code that shouldn't have compiled in the
first place).
Additionally, this crate seem tiny relative to other crates we are
testing here, so it seems like it doesn't provide that much additional
confidence.
The same happens with tokei project, but it is an actively maintained
one, so we can just upgrade it to a version from 2018, where clap was
upgraded.
|
|
|
|
|
|
:arrow_up: rust-analyzer
r? @ghost
|
|
|
|
rust_ast::ast => rustc_ast
Rework of #71199 which is a rework #70621
Still working on this but just made the PR to track progress
r? @Dylan-DPC
|
|
|
|
|
|
This commit updates clippy with the introduction of `QPath::LangItem` so
that it still compiles.
Signed-off-by: David Wood <david@davidtw.co>
|
|
Replaced `log` with `tracing`
## Description
Replaced `log` with `tracing` in the following crates:
- [x] librustc_ast
- [x] librustc_driver
- [x] librustc_errors
- [x] librustc_expand
- [x] librustc_hir
- [x] librustc_incremental
- [x] librustc_infer
- [x] librustc_interface
- [x] librustc_lint
- [x] librustc_metadata
- [x] librustc_middle
- [x] librustc_mir
- [x] librustc_mir_build
- [x] librustc_parse
- [x] librustc_passes
- [x] librustc_privacy
- [x] librustc_query_system
- [x] librustc_resolve
- [x] librustc_save_analysis
- [x] librustc_session
- [x] librustc_span
- [x] librustc_symbol_mangling
- [x] librustc_target
- [x] librustc_trait_selection
- [x] librustc_traits
- [x] librustc_ty
- [x] librustc_typeck
- [x] compiletest
Fixes: #74747
## Checklist:
- [x] Code compiles / builds
- [x] run tidy
- [x] Cleanup any clippy warnings
- [x] Update/add docs
|
|
|
|
Add rustc-docs as a component
Previously it was listed as a package but wasn't available in the component
lists in rustup, so wasn't actually installable.
rustc-docs is also only present for x86_64-unknown-linux-gnu. Eventually it'll
also be shipped for aarch64-gnu with current CI configuration, but that builder
isn't quite up and running yet.
We probably want to ship compiler docs for other platforms as well, though, but
this commit doesn't enable that quite yet. A future PR may do so by adding
--enable-compiler-docs to the relevant builders (but it would also need to
decide the set of builders which we'd ship on).
r? @matthiaskrgr
|
|
Add sanitizer support on FreeBSD
Restarting #47337. Everything is better now, no more weird llvm problems, well not everything:
Unfortunately, the sanitizers don't have proper support for versioned symbols (https://github.com/google/sanitizers/issues/628), so `libc`'s usage of `stat@FBSD_1.0` and so on explodes, e.g. in calling `std::fs::metadata`.
Building std (now easy thanks to cargo `-Zbuild-std`) and libc with `freebsd12/13` config via the `LIBC_CI=1` env variable is a good workaround…
```
LIBC_CI=1 RUSTFLAGS="-Z sanitizer=address" cargo +san-test -Zbuild-std run --target x86_64-unknown-freebsd --verbose
```
…*except* std won't build because there's no `st_lspare` in the ino64 version of the struct, so an std patch is required:
```diff
--- i/src/libstd/os/freebsd/fs.rs
+++ w/src/libstd/os/freebsd/fs.rs
@@ -66,8 +66,6 @@ pub trait MetadataExt {
fn st_flags(&self) -> u32;
#[stable(feature = "metadata_ext2", since = "1.8.0")]
fn st_gen(&self) -> u32;
- #[stable(feature = "metadata_ext2", since = "1.8.0")]
- fn st_lspare(&self) -> u32;
}
#[stable(feature = "metadata_ext", since = "1.1.0")]
@@ -136,7 +134,4 @@ impl MetadataExt for Metadata {
fn st_flags(&self) -> u32 {
self.as_inner().as_inner().st_flags as u32
}
- fn st_lspare(&self) -> u32 {
- self.as_inner().as_inner().st_lspare as u32
- }
}
```
I guess std could like.. detect that `libc` isn't built for the old ABI, and replace the implementation of `st_lspare` with a panic?
|
|
Previously it was listed as a package but wasn't available in the component
lists in rustup, so wasn't actually installable.
rustc-docs is also only present for x86_64-unknown-linux-gnu. Eventually it'll
also be shipped for aarch64-gnu with current CI configuration, but that builder
isn't quite up and running yet.
We probably want to ship compiler docs for other platforms as well, though, but
this commit doesn't enable that quite yet. A future PR may do so by adding
--enable-compiler-docs to the relevant builders (but it would also need to
decide the set of builders which we'd ship on).
|
|
merge `as_local_hir_id` with `local_def_id_to_hir_id`
`as_local_hir_id` was defined as just calling `local_def_id_to_hir_id` and I think that having two different ways to call the same method is somewhat confusing.
Don't really care about which of these 2 methods we want to keep.
Does this require an MCP, considering that these methods are fairly frequently used?
|
|
make rustc-docs component available to rustup
The `rustc-docs` component was generated but not selectable via rustup.
Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/rustc.20nightly.20docs.20as.20component.3F
r? @Mark-Simulacrum
|
|
|
|
|
|
update miri
Fixes https://github.com/rust-lang/rust/issues/75441
|
