| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #103460
|
|
|
|
|
|
|
|
|
|
Check representability in adt_sized_constraint
Now that representability is a query, we can use it to preemptively avoid a cycle in `adt_sized_constraint`.
I moved the representability check into `check_mod_type_wf` to avoid a scenario where rustc quits before checking all the types for representability. This also removes the check from rustdoc, which is alright AFAIK.
r? ``@cjgillot``
|
|
|
|
|
|
|
|
Remove `-Ztime`
Because it has a lot of overlap with `-Ztime-passes` but is generally less useful. Plus some related cleanups.
Best reviewed one commit at a time.
r? `@davidtwco`
|
|
The compiler currently has `-Ztime` and `-Ztime-passes`. I've used
`-Ztime-passes` for years but only recently learned about `-Ztime`.
What's the difference? Let's look at the `-Zhelp` output:
```
-Z time=val -- measure time of rustc processes (default: no)
-Z time-passes=val -- measure time of each rustc pass (default: no)
```
The `-Ztime-passes` description is clear, but the `-Ztime` one is less so.
Sounds like it measures the time for the entire process?
No. The real difference is that `-Ztime-passes` prints out info about passes,
and `-Ztime` does the same, but only for a subset of those passes. More
specifically, there is a distinction in the profiling code between a "verbose
generic activity" and an "extra verbose generic activity". `-Ztime-passes`
prints both kinds, while `-Ztime` only prints the first one. (It took me
a close reading of the source code to determine this difference.)
In practice this distinction has low value. Perhaps in the past the "extra
verbose" output was more voluminous, but now that we only print stats for a
pass if it exceeds 5ms or alters the RSS, `-Ztime-passes` is less spammy. Also,
a lot of the "extra verbose" cases are for individual lint passes, and you need
to also use `-Zno-interleave-lints` to see those anyway.
Therefore, this commit removes `-Ztime` and the associated machinery. One thing
to note is that the existing "extra verbose" activities all have an extra
string argument, so the commit adds the ability to accept an extra argument to
the "verbose" activities.
|
|
The diagnostic message extraction code didn't handle translations yet.
|
|
|
|
Remove support for legacy PM
This removes support for optimizing with LLVM's legacy pass manager, as well as the unstable `-Znew-llvm-pass-manager` option. We have been defaulting to the new PM since LLVM 13 (except for s390x that waited for 14), and LLVM 15 removed support altogether. The only place we still use the legacy PM is for writing the output file, just like `llc` does.
cc #74705
r? ``@nikic``
|
|
|
|
Make cycle errors recoverable
In particular, this allows rustdoc to recover from cycle errors when normalizing associated types for documentation.
In the past, ```@jackh726``` has said we need to be careful about overflow errors: https://github.com/rust-lang/rust/pull/91430#issuecomment-983997013
> Off the top of my head, we definitely should be careful about treating overflow errors the same as
"not implemented for some reason" errors. Otherwise, you could end up with behavior that is
different depending on recursion depth. But, that might be context-dependent.
But cycle errors should be safe to unconditionally report; they don't depend on the recursion depth, they will always be an error whenever they're encountered.
Helps with https://github.com/rust-lang/rust/issues/81091.
r? ```@lcnr``` cc ```@matthewjasper```
|
|
Since https://github.com/rust-lang/rust/pull/88679, rustdoc doesn't load crates eagerly.
Add an explicit `extern crate` item to make sure the crate is loaded and the bug reproduces.
You can verify this fix by adding `// compile-flags: -Znormalizing-docs` and running the test.
|
|
In particular, this allows rustdoc to recover from cycle errors when normalizing associated types for documentation.
In the past, `@jackh726` has said we need to be careful about overflow errors:
> Off the top of my head, we definitely should be careful about treating overflow errors the same as
"not implemented for some reason" errors. Otherwise, you could end up with behavior that is
different depending on recursion depth. But, that might be context-dependent.
But cycle errors should be safe to unconditionally report; they don't depend on the recursion depth, they will always be an error whenever they're encountered.
|
|
|
|
|
|
change rlib format to distinguish native dependencies
Another one method to solve problem mentioned in #99429.
Changed .rlib format, it contains all bundled native libraries as archieves.
At link time rlib is unpacked and native dependencies linked separately.
New behavior hidden under separate_native_rlib_dependencies flag.
|
|
r=GuillaumeGomez
rustdoc: fix treatment of backslash-escaped HTML
Try generating HTML for this markup:
\<a href="https://example.com">example</a>
It will produce text, not HTML, in both rustdoc's real HTML output and in the commonmark reference implementation:
https://spec.commonmark.org/dingus/?text=%5C%3Ca%20href%3D%22https%3A%2F%2Fexample.com%22%3Eexample%3C%2Fa%3E
|
|
r=GuillaumeGomez
Feature gate the `rustdoc::missing_doc_code_examples` lint
Moves the lint from being implicitly active on nightly `rustdoc` to requiring a feature to activate, like other unstable lints.
Uses the new tracking issue https://github.com/rust-lang/rust/issues/101730
|
|
r=GuillaumeGomez
rustdoc: improve rustdoc HTML suggestions handling of nested generics
Based on some poor suggestions produced when stablizing this lint and running it on `manformed-generics.rs` in #101720
|
|
Try generating HTML for this markup:
\<a href="https://example.com">example</a>
It will produce text, not HTML, in both rustdoc's real HTML output and in
the commonmark reference implementation:
https://spec.commonmark.org/dingus/?text=%5C%3Ca%20href%3D%22https%3A%2F%2Fexample.com%22%3Eexample%3C%2Fa%3E
|
|
|
|
Based on some poor suggestions produced when stablizing this lint and running
it on `manformed-generics.rs`
|
|
|
|
|
|
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
|
|
|
|
add -Zextra-const-ub-checks to enable more UB checking in const-eval
Cc https://github.com/rust-lang/rust/issues/99923
r? `@oli-obk`
|
|
|
|
Prior work, notably 6550021124451628b1efc60c59284465b109e3aa from #88316
has removed box syntax from most of the testsuite. However,
some tests were left out.
This commit removes box_syntax uses from more locations in src/test.
Some tests that are very box syntax specific are not being migrated.
|
|
Prevent ICE for `doc_alias` on match arm, statement, expression
Fixes #99777.
This is a pretty minimal fix that should be safe, since rustdoc doesn't generate documentation for match arms, statements, or expressions. I mentioned in the linked issue that the `doc_alias` target checking should probably be improved to avoid future ICEs, but as a new contributor, I'm not confident enough with the HIR types to make a larger change.
|
|
- Added `Impl`, `Closure`, ForeignMod` targets
- `Target::name` changed for `Target::Impl`
- Error output for `Target::ForeignMod` changed to "foreign module"
|
|
Make Rustdoc exit with correct error code when scraping examples from invalid files
This PR fixes a small issue with the new Rustdoc scrape-examples feature. If a file that is being scraped has a type error, then currently that error is printed out, but the rustdoc process exits as if it succeeded. This is a problem for Cargo, which needs to track whether scraping succeeded (see rust-lang/cargo#10343).
This PR fixes the issue by checking whether an error is emitted, and aborting if so.
|
|
files
|
|
`-Z location-detail`: provide option to disable all location details
As reported [here](https://github.com/rust-lang/rust/pull/89920#issuecomment-1190598924), when I first implemented the `-Z location-detail` flag there was a bug, where passing an empty list was not correctly supported, and instead rejected by the compiler. This PR fixes that such that passing an empty list results in no location details being tracked, as originally specified in https://github.com/rust-lang/rfcs/pull/2091 .
This PR also adds a test case to verify that this option continues to work as intended.
|
|
notriddle:notriddle/invalid-html-tags-webcomponents, r=GuillaumeGomezp
rustdoc: align invalid-html-tags lint with commonmark spec
|
|
This is done by having the crossbeam dependency inserted into the
proc_macro server code from the server side, to avoid adding a
dependency to proc_macro.
In addition, this introduces a -Z command-line option which will switch
rustc to run proc-macros using this cross-thread executor. With the
changes to the bridge in #98186, #98187, #98188 and #98189, the
performance of the executor should be much closer to same-thread
execution.
In local testing, the crossbeam executor was substantially more
performant than either of the two existing CrossThread strategies, so
they have been removed to keep things simple.
|
|
|
|
Prior to this fix, `-Z location-detail` provided no mechanism for
disabling all location details. This commit also adds a test case
to verify that this option continues to work as intended, and
clarifies the documentation of this option.
|
|
This adds a new option, `-Zmir-pretty-relative-line-numbers`, that
is then used in compiletest for the mir-opt tests.
|
|
|
|
Allow to disable thinLTO buffer to support lto-embed-bitcode lld feature
Hello
This change is to fix issue (https://github.com/rust-lang/rust/issues/84395) in which passing "-lto-embed-bitcode=optimized" to lld when linking rust code via linker-plugin-lto doesn't produce the expected result.
Instead of emitting a single unified module into a llvmbc section of the linked elf, it emits multiple submodules.
This is caused because rustc emits the BC modules after running llvm `createWriteThinLTOBitcodePass` pass.
Which in turn triggers a thinLTO linkage and causes the said issue.
This patch allows via compiler flag (-Cemit-thin-lto=<bool>) to select between running `createWriteThinLTOBitcodePass` and `createBitcodeWriterPass`.
Note this pattern of selecting between those 2 passes is common inside of LLVM code.
The default is to match the old behavior.
|
|
Add flag to configure `noalias` on `Box<T>`
The aliasing rules of `Box<T>` are still not decided, but currently, `Box<T>` is unique and gets `noalias`. To aid making an informed decision about the future of `Box<T>`, this PR adds a flag `-Zbox-noalias` to configure `noalias` for `Box<T>` (for example, for benchmarking). The same flag already exists for `&mut T` `noalias`, where it was added because it was the problem of various miscompilations in LLVM.
For more information, see rust-lang/unsafe-code-guidelines#326
|
|
To aid making an informed decision about the aliasing
rules of box, give users an option to remove `noalias`
from box.
|
|
The attribute is also renamed `fake_variadic`.
|
|
Migrate half of the `rustc_passes::check_attr` diagnostics to using
diagnostic derives and being translatable.
|
