rustdoc: handle assoc const equalities in cross-crate impl-Trait-in-arg-pos
Fixes FIXME (the added test previously lead to an ICE).
`@rustbot` label A-cross-crate-reexports
Test the cargo args generated by bootstrap.py
I recommend reviewing this commit-by-commit using the instructions in https://rustc-dev-guide.rust-lang.org/git.html#moving-large-sections-of-code.
- Test cargo arguments passed by bootstrap.py
This moves a lot of code around, but the logic itself is not too terribly complicated.
- Move almost all logic in `def bootstrap` to the `RustBuild` class, to avoid mixing setting configuration with running commands
- Update various doctests to the new (more complete) RustBuild config. In particular, don't pretend that `bin_root` supports `build` being unset.
- Change `parse_args` not to use a global, to allow testing it
- Set BUILD_DIR appropriately so bootstrap.py doesn't panic because cargo isn't found
- Allow passing arguments to `bootstrap_test.py`
Previous, it used the built-in test runner, which doesn't support options unless they're manually passed in the script.
- Fix progress messages for configure in bootstrap_test.py
Before it would unconditionally print `configure-args = []`.
r? `@albertlarsan68` cc https://github.com/rust-lang/rust/pull/112089https://github.com/rust-lang/rust/pull/111979#issuecomment-1568525699
Move windows-sys arm32 shim to c.rs
This moves the arm32 shim in to c.rs instead of appending to the generated file itself.
This makes it simpler to change these workarounds if/when needed. The downside is we need to exclude a couple of functions from being generated (see the comment). A metadata solution could help here but they'll be easy enough to add back if that happens.
rustdoc: Align search results horizontally for easy scanning
The recent PR #110688 added info about an item's kind before its name in
search results. However, because the kind and name are inline with no
alignment, it's now hard to visually scan downward through the search
results, looking at item names. This PR fixes that by horizontally
aligning search results such that there are now two columns of
information.
r? `@GuillaumeGomez`
bootstrap: Backup `settings.json` to the correct filename
The old code actually replaced `.json` with `.bak` (so, `settings.bak`),
rather than appending `.bak` as claimed (`settings.json.bak`).
`Path::set_extension` can instead be used with dots:
> The new extension may contain dots and will be used in its entirety,
> but only the part after the final dot will be reflected in
> `self.extension`.
r? ``@jyn514``
style-guide: Rewrite let-else section for clarity, without changing formatting
The section as written did not cover all cases, and left some of them
implicit. Rewrite it to systematically cover all cases. Place examples
immediately following the corresponding case.
In the process, reorder to move the simplest cases first: start with
single-line and add progressively more line breaks.
This does not change the meaning of the section at all, and in
particular does not change the defined style for let-else statements.
The old code actually replaced `.json` with `.bak` (so, `settings.bak`),
rather than appending `.bak` as claimed (`settings.json.bak`).
`Path::set_extension` can instead be used with dots:
> The new extension may contain dots and will be used in its entirety,
> but only the part after the final dot will be reflected in
> self.extension.
This moves a lot of code around, but the logic itself is not too terribly complicated.
- Move almost all logic in `def bootstrap` to the `RustBuild` class, to avoid mixing setting configuration with running commands
- Update various doctests to the new (more complete) RustBuild config. In particular, don't pretend that `bin_root` supports `build` being unset.
- Change `parse_args` not to use a global, to allow testing it
- Set BUILD_DIR appropriately so bootstrap.py doesn't panic because cargo isn't found
This makes "existential type" look slightly cramped (though still
readable), but it makes all other typenames look better. Existential
types are currently very rare, and we can always tweak this later if
necessary.
Fix rustdoc gui tester
Problem was that the `main` was always exiting with `0`, whether or not there was an error. It led to failing GUI tests being ignored in the CI since no one saw them.
r? ````@klensy````
[tests/rustdoc] Add @files command
The ``````@!has`````` checks is very problematic as it wouldn't catch if the file scheme is updated and the file is generated again. ``````@files`````` allows to ensure that the given folder contains exactly the provided entries (files and folders).
I'm wondering if we should forbid the ``````@!has`````` for files. To be discussed after this PR I suppose.
r? `````@notriddle`````
Migrate `item_bounds` to `ty::Clause`
Should be simpler than the next PR that's coming up. Last three commits are the relevant ones.
r? ``@oli-obk`` or ``@lcnr``
style-guide: Add language disclaiming any effects on non-default Rust styles
Make it clear that the style guide saying "must" doesn't forbid
developers from doing differently (as though any power on this Earth
could do that) and doesn't forbid tools from allowing any particular
configuration options.
Otherwise, people might wonder (for instance) if there's a semantic difference
between "must" and "should" in the style guide, and whether tools are "allowed"
to offer configurability of something that says "must".
style-guide: Organizational and editing tweaks (no semantic changes)
I'd recommend reviewing this PR commit-by-commit; each commit is self-contained
and should be easy to review at a glance.
- style-guide: Move text about block vs visual indent to indentation section
- style-guide: Move and expand text about trailing commas
- style-guide: s/right-ward/rightward/
- style-guide: Consistently refer to rustfmt as `rustfmt`
- style-guide: Remove inaccurate statement about rustfmt
- style-guide: Define (and capitalize) "ASCIIbetically"
- style-guide: Update cargo.md for authors being optional and not recommended
- style-guide: Avoid normative recommendations for formatting tool configurability
- style-guide: Clarify advice on names matching keywords
- style-guide: Reword an awkwardly phrased recommendation (and fix a typo)
- style-guide: Rephrase a confusingly ordered, ambiguous sentence (and fix a typo)
- style-guide: Avoid hyphenating "semicolon"
- style-guide: Make link text in SUMMARY.md match the headings in the linked pages
- style-guide: Define what an item is
- style-guide: Avoid referring to the style team in the past tense
Make it clear that the style guide saying "must" doesn't forbid
developers from doing differently (as though any power on this Earth
could do that) and doesn't forbid tools from allowing any particular
configuration options.
This sentence had a parenthetical without a closing parenthesis, and had
the phrase "which doesn't require special formatting" ambiguously at the
end of a list when it only applied to the last item of the list.
