| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.
Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.
However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.
Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.
The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.
In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.
This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
|
|
|
|
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
|
|
rustc_parse: More precise spans for `tuple.0.0`
This should help with https://github.com/rust-lang/rustfmt/issues/4355, but I haven't verified, cc `@calebcartwright.`
|
|
Replace run_compiler with RunCompiler builder pattern
Fixes #77286. Replaces rustc_driver:run_compiler with RunCompiler builder pattern.
|
|
|
|
Provide structured suggestions when finding structs when expecting a trait
When finding an ADT in a trait object definition provide some solutions. Fix #45817.
Given `<Param as Trait>::Assoc: Ty` suggest `Param: Trait<Assoc = Ty>`. Fix #75829.
|
|
Allow generic parameters in intra-doc links
Fixes #62834.
---
The contents of the generics will be mostly ignored (except for warning
if fully-qualified syntax is used, which is currently unsupported in
intra-doc links - see issue #74563).
* Allow links like `Vec<T>`, `Result<T, E>`, and `Option<Box<T>>`
* Allow links like `Vec::<T>::new()`
* Warn on
* Unbalanced angle brackets (e.g. `Vec<T` or `Vec<T>>`)
* Missing type to apply generics to (`<T>` or `<Box<T>>`)
* Use of fully-qualified syntax (`<Vec as IntoIterator>::into_iter`)
* Invalid path separator (`Vec:<T>:new`)
* Too many angle brackets (`Vec<<T>>`)
* Empty angle brackets (`Vec<>`)
Note that this implementation *does* allow some constructs that aren't
valid in the actual Rust syntax, for example `Box::<T>new()`. That may
not be supported in rustdoc in the future; it is an implementation
detail.
|
|
Add asm! support for mips64
- [x] Updated `src/doc/unstable-book/src/library-features/asm.md`.
- [ ] No vector type support. I don't know much about those types.
cc #76839
|
|
Revert "Assume slice len is bounded by allocation size"
https://github.com/rust-lang/rust/pull/77023#issuecomment-703987379
suggests that the original PR introduced a significant perf regression.
This reverts commit e44784b8750016a695361c990024750e037d8f9f / #77023.
cc `@HeroicKatora`
|
|
|
|
|
|
https://github.com/rust-lang/rust/pull/77023#issuecomment-703987379
suggests that the original PR introduced a significant perf regression.
This reverts commit e44784b8750016a695361c990024750e037d8f9f / #77023.
|
|
Fix #75829
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The contents of the generics will be mostly ignored (except for warning
if fully-qualified syntax is used, which is currently unsupported in
intra-doc links - see issue #74563).
* Allow links like `Vec<T>`, `Result<T, E>`, and `Option<Box<T>>`
* Allow links like `Vec::<T>::new()`
* Warn on
* Unbalanced angle brackets (e.g. `Vec<T` or `Vec<T>>`)
* Missing type to apply generics to (`<T>` or `<Box<T>>`)
* Use of fully-qualified syntax (`<Vec as IntoIterator>::into_iter`)
* Invalid path separator (`Vec:<T>:new`)
* Too many angle brackets (`Vec<<T>>`)
* Empty angle brackets (`Vec<>`)
Note that this implementation *does* allow some constructs that aren't
valid in the actual Rust syntax, for example `Box::<T>new()`. That may
not be supported in rustdoc in the future; it is an implementation
detail.
|
|
suggest `MAX` constant if -1 is assigned to unsigned type
Fixes #76413.
Fixes #77416.
|
|
Resolve intra-doc links on additional documentation for re-exports in lexical scope
Fixes https://github.com/rust-lang/rust/issues/77254.
- Preserve the parent module of `DocFragment`s
+ Add `parent_module` to `DocFragment`
+ Require the `parent_module` of the item being inlined
+ Preserve the hir_id for ExternCrates so rustdoc can find the parent module later
+ Take an optional `parent_module` for `build_impl` and `merge_attrs`.
Preserve the difference between parent modules for each doc-comment.
+ Support a single additional re-exports in from_ast. Originally this took a vec but I ended up not using it.
+ Don't require the parent_module for all `impl`s, just inlined items
In particular, this will be `None` whenever the attribute is not on a
re-export.
+ Only store the parent_module, not the HirId
When re-exporting a re-export, the HirId is not available. Fortunately,
`collect_intra_doc_links` doesn't actually need all the info from a
HirId, just the parent module.
- Introduce `Divider`
This distinguishes between documentation on the original from docs on the re-export.
- Use the new module information for intra-doc links
+ Make the parent module conditional on whether the docs are on a re-export
+ Make `resolve_link` take `&Item` instead of `&mut Item`
Previously the borrow checker gave an error about multiple mutable
borrows, because `dox` borrowed from `item`.
+ Fix `crate::` for re-exports
`crate` means something different depending on where the attribute
came from.
+ Make it work for `#[doc]` attributes too
This required combining several attributes as one so they would keep
the links.
r? `@GuillaumeGomez`
|
|
Implementation of RFC2867
https://github.com/rust-lang/rust/issues/74727
So I've started work on this, I think my next steps are to make use of the `instruction_set` value in the llvm codegen but this is the point where I begin to get a bit lost. I'm looking at the code but it would be nice to have some guidance on what I've currently done and what I'm doing next :smile:
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #76750 (Don't discourage implementing `core::fmt::Write`)
- #77449 (BTreeMap: comment why drain_filter's size_hint is somewhat pessimistic)
- #77660 ((docs): make mutex error comment consistent with codebase)
- #77663 (Add compile fail test for issue 27675)
- #77673 (Remove unnecessary lamda on emitter map.)
- #77701 (Make `max_log_info` easily greppable (for figuring out why debug logging is disabled))
- #77702 (Remove not needed lambda.)
- #77710 (Update submodule llvm to get LVI bugfix)
Failed merges:
r? `@ghost`
|
|
|
|
r=Aaron1011
Add compile fail test for issue 27675
A recently merged PR (#73905) strengthened the checks on bounds of associated items. This rejects the attack path of #27675 which consisted of constructing a `dyn Trait<Item=T>` where `T` would not fulfill the bounds required on `Item` of the `Trait` behind the dyn object.
This regression test, extracted from [the weaponized instance](https://github.com/rust-lang/rust/issues/27675#issuecomment-696956878), checks that this is rejected.
|
|
Suggest removing `&mut` from a `&mut borrow`
Modify the code added in #54720.
Closes #75871
|
|
RunCompiler::new takes non-optional params, and optional
params can be set using set_*field_name* method.
finally `run` will forward all fields to `run_compiler`.
|
|
|
|
Fix a typo: minding -> binding
Add test for &mut &mut
|
|
Upgrade to tracing-subscriber 0.2.13
The primary motivation is to get the changes from
https://github.com/tokio-rs/tracing/pull/990. Example output:
```
$ RUSTDOC_LOG=debug rustdoc +rustc2
warning: some trace filter directives would enable traces that are disabled statically
| `debug` would enable the DEBUG level for all targets
= note: the static max level is `info`
= help: to enable DEBUG logging, remove the `max_level_info` feature
```
r? `@Mark-Simulacrum`
cc `@hawkw` ❤️
|
|
|
|
- Make the parent module conditional on whether the docs are on a re-export
- Make `resolve_link` take `&Item` instead of `&mut Item`
Previously the borrow checker gave an error about multiple mutable
borrows, because `dox` borrowed from `item`.
- Fix `crate::` for re-exports
`crate` means something different depending on where the attribute
came from.
- Make it work for `#[doc]` attributes too
This required combining several attributes as one so they would keep
the links.
|
|
Detect blocks that could be struct expr bodies
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:
```rust
fn foo() -> Foo {
bar: Vec::new()
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> src/file.rs:5:5
|
5 | bar: Vec::new()
| ^^^ expecting a type here because of type ascription
error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
--> src/file.rs:5:15
|
5 | bar: Vec::new()
| ^^^^^ only `Fn` traits may use parentheses
error[E0107]: wrong number of type arguments: expected 1, found 0
--> src/file.rs:5:10
|
5 | bar: Vec::new()
| ^^^^^^^^^^ expected 1 type argument
```
If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:
```
error: struct literal body without path
--> file.rs:4:17
|
4 | fn foo() -> Foo {
| _________________^
5 | | bar: Vec::new(),
6 | | }
| |_^
|
help: you might have forgotten to add the struct literal inside the block
|
4 | fn foo() -> Foo { Path {
5 | bar: Vec::new(),
6 | } }
|
```
Partially address last remaining part of #34255.
|
|
The primary motivation is to get the changes from
https://github.com/tokio-rs/tracing/pull/990. Example output:
```
$ RUSTDOC_LOG=debug rustdoc +rustc2
warning: some trace filter directives would enable traces that are disabled statically
| `debug` would enable the DEBUG level for all targets
= note: the static max level is `info`
= help: to enable DEBUG logging, remove the `max_level_info` feature
```
- Remove useless test
This was testing for an ICE when passing `RUST_LOG=rustc_middle`. I
noticed it because it started giving the tracing warning (because tests
are not run with debug-logging enabled). Since this bug seems unlikely
to re-occur, I just removed it altogether.
|
|
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:
```rust
fn foo() -> Foo {
bar: Vec::new()
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> src/file.rs:5:5
|
5 | bar: Vec::new()
| ^^^ expecting a type here because of type ascription
error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
--> src/file.rs:5:15
|
5 | bar: Vec::new()
| ^^^^^ only `Fn` traits may use parentheses
error[E0107]: wrong number of type arguments: expected 1, found 0
--> src/file.rs:5:10
|
5 | bar: Vec::new()
| ^^^^^^^^^^ expected 1 type argument
```
If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:
```
error: struct literal body without path
--> file.rs:4:17
|
4 | fn foo() -> Foo {
| _________________^
5 | | bar: Vec::new(),
6 | | }
| |_^
|
help: you might have forgotten to add the struct literal inside the block
|
4 | fn foo() -> Foo { Path {
5 | bar: Vec::new(),
6 | } }
|
```
Partially address last part of #34255.
|
|
Give `impl Trait` in a `const fn` its own feature gate
...previously it was gated under `#![feature(const_fn)]`.
I think we actually want to do this in all const-contexts? If so, this should be `#![feature(const_impl_trait)]` instead. I don't think there's any way to make use of `impl Trait` within a `const` initializer.
cc #77463
r? `@oli-obk`
|
|
Eliminate bounds checking in slice::Windows
This is how `<core::slice::Windows as Iterator>::next` looks right now:
```rust
fn next(&mut self) -> Option<&'a [T]> {
if self.size > self.v.len() {
None
} else {
let ret = Some(&self.v[..self.size]);
self.v = &self.v[1..];
ret
}
}
```
The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()`, so `self.v` can be empty if `self.size` is zero. In practice, since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero, `self.size` is never zero. However, the compiler doesn't know about this check, so it keeps the code which checks bounds and panics.
Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a, u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
<details>
<summary>Before</summary>
```
example::next:
push rax
mov rcx, qword ptr [rdi + 8]
mov rdx, qword ptr [rdi + 16]
cmp rdx, rcx
jbe .LBB0_2
xor eax, eax
pop rcx
ret
.LBB0_2:
test rcx, rcx
je .LBB0_5
mov rax, qword ptr [rdi]
mov rsi, rax
add rsi, 4
add rcx, -1
mov qword ptr [rdi], rsi
mov qword ptr [rdi + 8], rcx
pop rcx
ret
.LBB0_5:
lea rdx, [rip + .L__unnamed_1]
mov edi, 1
xor esi, esi
call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL]
ud2
.L__unnamed_2:
.ascii "./example.rs"
.L__unnamed_1:
.quad .L__unnamed_2
.asciz "\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"
```
</details>
<details>
<summary>After</summary>
```
example::next:
mov rcx, qword ptr [rdi + 8]
mov rdx, qword ptr [rdi + 16]
cmp rdx, rcx
jbe .LBB0_2
xor eax, eax
ret
.LBB0_2:
mov rax, qword ptr [rdi]
lea rsi, [rax + 4]
add rcx, -1
mov qword ptr [rdi], rsi
mov qword ptr [rdi + 8], rcx
ret
```
</details>
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet.
#### Possible reasons _not_ to merge this PR:
* this changes the error message on panic in `[T]::windows`. However, AFAIK this messages are not covered by backwards compatibility policy.
|
|
r=estebank
resolve: improve "try using the enum's variant"
Fixes #73427.
This PR improves the "try using the enum's variant" suggestion:
- Variants in suggestions would not result in more errors (e.g. use of a struct variant is only suggested if the suggestion can trivially construct that variant). Therefore, suggestions are only emitted for variants that have no fields (since the suggestion can't know what value fields would have).
- Suggestions include the syntax for constructing the variant. If a struct or tuple variant is suggested, then it is constructed in the suggestion - unless in pattern-matching or when arguments are already provided.
- A help message is added which mentions the variants which are no longer suggested.
All of the diagnostic logic introduced by this PR is separated from the normal code path for a successful compilation.
r? `@estebank`
|
|
|
|
builtin_macros: Fix use of interpolated identifiers in `asm!`
Fixes https://github.com/rust-lang/rust/issues/77584
|
|
Unclosed html tag lint
Part of #67799.
I think `@ollie27` will be interested (`@Manishearth` too since they opened the issue ;) ).
r? `@jyn514`
|
|
Fix rustc_def_path to show the full path and not the trimmed one
Follow-up fix for #73996.
|
|
inliner: use caller param_env
We used the callee param env instead of the caller param env by accident in #77430, this PR fixes that and caches it in the `Inliner` struct.
fixes #77564
r? @ecstatic-morse
|
|
compare mode chalk don't finish.
|
|
|
|
|
