Add a default filter for library/std to build if there are no filters

[jyn514]

• Add an opt-in way to build all tools with x.py build src/tools
• Add an entry in the changelog
• Bump the major version

This implements rust-lang/compiler-team#351.

r? @Mark-Simulacrum on the implementation

[tmiasko]

Could we bump changelog-seen in config.toml.example along with bumps to the major version?

[petrochenkov]

I disagree with this, it's one more change that requires passing extra options in the common case.

• rustdoc often breaks when something in rustc is changed, and needs to be tested (it would be nice to build clippy by default as well, since it's now in the repo), other tools are tiny and build quickly.
• this introduces one more difference between build and test, making the rules more complex and harder to remember.
• if you are working on something specific requiring limited testing, then it's better to build and test specific components instead of building "everything" with x.py build.

[jyn514]

I really wish you would bring this stuff up during the MCP process. All of these are reasonable objections to a decision that happened a month ago.

[petrochenkov]

I haven't seen this specific MCP.

[jyn514]

This was rust-lang/compiler-team#351.

[jyn514]

rustdoc often breaks when something in rustc is changed

Do you often use build to look for breakage? I normally use check if I'm refactoring.

[Mark-Simulacrum]

I don't think this is worth a major change -- it will build strictly less than before, right? People don't need to be notified of changes that likely don't affect their workflow. The host/build change was much more likely to break your build in a confusing way, here you're just going to get less built and can easily opt back in.

[Mark-Simulacrum]

This feels very odd. This seems no different than just removing DEFAULT = true from all of the build-called steps except std; why is that not the approach taken here?

[bors]

☔ The latest upstream changes (presumably #77517) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[petrochenkov]

@jyn514

Do you often use build to look for breakage? I normally use check if I'm refactoring.

• I usually use run specific tests after doing changes to code, e.g ./x.py test --bless --stage 1 src/test/ui --test-args my_test. This use case improved recently because --stage 1 is no longer necessary, but at cost of inconsistencies and more complex rules.
• I run tidy and ./x.py test --bless --stage 1 --pass check src/test/{pretty,compile-fail,ui} or ./x.py test --bless --stage 1 --pass check src/test/{rustdoc*,pretty,compile-fail,ui} before submitting a PR with small-scale compiler changes. This use case improved recently because --stage 1 is no longer necessary, but at cost of inconsistencies and more complex rules.
• I run ./x.py test --bless --stage 2 before submitting a PR with large-scale or risky changes with may have unknown effects (e.g. Expand NtExpr tokens only in key-value attributes #77271 or rustbuild: Build tests with LLD if use-lld = true was passed #76378). This use case regressed recently because I have to explicitly add --stage 2 instead of just running x.py test to "test everything".

I honestly don't know any use cases for running x.py build, but deviating its behavior from x.py test (or x.py check) by introducing a different set of built targets only introduces inconsistencies and more complex rules.

[jyn514]

I don't feel very strongly about this. @jonas-schievink or @tmandry feel free to take this over if you're interested.