| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Use LocalDefId for closures more
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #99311 (change maybe_body_owned_by to take local def id)
- #99862 (Improve type mismatch w/ function signatures)
- #99895 (don't call type ascription "cast")
- #99900 (remove some manual hash stable impls)
- #99903 (Add diagnostic when using public instead of pub)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
change maybe_body_owned_by to take local def id
Issue https://github.com/rust-lang/rust/issues/96341
r? `@cjgillot`
|
|
Remove `TreeAndSpacing`.
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
r? `@petrochenkov`
|
|
update few deps
Updates few crates:
* openssl-src v111.18.0+1.1.1n -> v111.22.0+1.1.1q: fixes few CVE's (https://www.openssl.org/news/vulnerabilities-1.1.1.html: https://cve.org/CVERecord?id=CVE-2022-1292 https://cve.org/CVERecord?id=CVE-2022-2068 https://cve.org/CVERecord?id=CVE-2022-2097)
* openssl-probe v0.1.2 -> v0.1.5 updates ancient (2017) crate (https://github.com/alexcrichton/openssl-probe/compare/0.1.2...0.1.5). Adds support to search cert for additional platforms.
* indoc v1.0.3 -> v1.0.6 (https://github.com/dtolnay/indoc/compare/1.0.3...1.0.6) Nothing special changed, removes unindent v0.1.7
* bstr v0.2.13 -> v0.2.17 (https://github.com/BurntSushi/bstr/compare/0.2.13...0.2.17) Few speedups (https://github.com/BurntSushi/bstr/commit/8e659921312830b91d2a48aafa36fb1a49cba5bc, https://github.com/BurntSushi/bstr/commit/5fcef919adf1b84a960c87126decb0f3ef8c2e61) and bugfix (https://github.com/BurntSushi/bstr/commit/b2111b6bbf2c9a819fb1338aa81bd099874106a1)
* crc32fast v1.2.0 -> v1.3.2 (https://github.com/srijs/rust-crc32fast/compare/v1.2.0...v1.3.2) Speedup debug (https://github.com/srijs/rust-crc32fast/commit/e61ce6a39bbe9da495198a4037292ec299e8970f)
* diff v0.1.12 -> v0.1.13 (https://github.com/utkarshkukreti/diff.rs/compare/0.1.12...0.1.13) Few optimizations (https://github.com/utkarshkukreti/diff.rs/pull/16, https://github.com/utkarshkukreti/diff.rs/commit/0f0aa580f197af7dab9ab905568f70a2387e23bc)
* ignore v0.4.17 -> v0.4.18 (it's hard to get usable diff, but most notable perf change is https://github.com/BurntSushi/ripgrep/commit/a28e664abd0d8912e4a2d85039fe282b9d37b994)
* globset v0.4.5 -> v0.4.9
* regex v1.5.5 -> v1.5.6 few bugfixes (https://github.com/rust-lang/regex/blob/1.5.6/CHANGELOG.md#156-2022-05-20). There exist 1.6.0 version, but it's too fresh.
|
|
Signed-off-by: Miguel Guarniz <mi9uel9@gmail.com>
|
|
Signed-off-by: Miguel Guarniz <mi9uel9@gmail.com>
|
|
Signed-off-by: Miguel Guarniz <mi9uel9@gmail.com>
|
|
Signed-off-by: Miguel Guarniz <mi9uel9@gmail.com>
|
|
A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
|
|
Generate correct suggestion with named arguments used positionally
Address issue #99265 by checking each positionally used argument
to see if the argument is named and adding a lint to use the name
instead. This way, when named arguments are used positionally in a
different order than their argument order, the suggested lint is
correct.
For example:
```
println!("{b} {}", a=1, b=2);
```
This will now generate the suggestion:
```
println!("{b} {a}", a=1, b=2);
```
Additionally, this check now also correctly replaces or inserts
only where the positional argument is (or would be if implicit).
Also, width and precision are replaced with their argument names
when they exists.
Since the issues were so closely related, this fix for issue #99265
also fixes issue #99266.
Fixes #99265
Fixes #99266
|
|
Update Clippy
r? `@Manishearth`
|
|
|
|
Use line numbers relative to the function in mir-opt tests
As shown in #99770, the line numbers can be a big source of needless and confusing diffs. This PR adds a new flag `-Zmir-pretty-relative-line-numbers` to make them relative to the function declaration, which avoids most needless diffs from attribute changes.
`@JakobDegen` told me that there has been a zulip conversation about disabling line numbers with mixed opinions, so I'd like to get some feedback here, for this hopefully better solution.
r? rust-lang/wg-mir-opt
|
|
|
|
r=Mark-Simulacrum
Sync `rust-analyzer`, add `rust-analyzer-proc-macro-srv` binary to Rustc component
As discussed earlier with `@jyn514` and `@pietroalbini,` I'm also going to use this PR to have `dist::Rustc` build the `rust-analyzer-proc-macro-srv` binary introduced in:
* https://github.com/rust-lang/rust-analyzer/pull/12871
|
|
openssl-src v111.18.0+1.1.1n -> v111.22.0+1.1.1q
openssl-probe v0.1.2 -> v0.1.5
indoc v1.0.3 -> v1.0.6
bstr v0.2.13 -> v0.2.17
crc32fast v1.2.0 -> v1.3.2
diff v0.1.12 -> v0.1.13
ignore v0.4.17 -> v0.4.18
globset v0.4.5 -> v0.4.9
regex v1.5.5 -> v1.5.6
|
|
This adds a new option, `-Zmir-pretty-relative-line-numbers`, that
is then used in compiletest for the mir-opt tests.
|
|
Clean up HIR-based lifetime resolution
Based on https://github.com/rust-lang/rust/pull/97313.
Fixes #98932.
r? `@petrochenkov`
|
|
lint: add bad opt access internal lint
Prompted by [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/sess.2Ecrate_types.28.29.20vs.20sess.2Eopts.2Ecrate_types/near/290682847).
Some command-line options accessible through `sess.opts` are best accessed through wrapper functions on `Session`, `TyCtxt` or otherwise, rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed through a wrapper function so that this is prohibited. Options are annotated with a new attribute `rustc_lint_opt_deny_field_access` which can specify the error message (i.e. "use this other function instead") to be emitted.
A simpler alternative would be to simply rename the options in the option type so that it is clear they should not be used, however this doesn't prevent uses, just discourages them. Another alternative would be to make the option fields private, and adding accessor functions on the option types, however the wrapper functions sometimes rely on additional state from `Session` or `TyCtxt` which wouldn't be available in an function on the option type, so the accessor would simply make the field available and its use would be discouraged too.
**Leave a comment if there's an option I should add this to.**
|
|
Some command-line options accessible through `sess.opts` are best
accessed through wrapper functions on `Session`, `TyCtxt` or otherwise,
rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed
through a wrapper function so that this is prohibited. Options are
annotated with a new attribute `rustc_lint_opt_deny_field_access` which
can specify the error message (i.e. "use this other function instead")
to be emitted.
A simpler alternative would be to simply rename the options in the
option type so that it is clear they should not be used, however this
doesn't prevent uses, just discourages them. Another alternative would
be to make the option fields private, and adding accessor functions on
the option types, however the wrapper functions sometimes rely on
additional state from `Session` or `TyCtxt` which wouldn't be available
in an function on the option type, so the accessor would simply make the
field available and its use would be discouraged too.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Update cargo
5 commits in d8d30a75376f78bb0fabe3d28ee9d87aa8035309..85b500ccad8cd0b63995fd94a03ddd4b83f7905b
2022-07-19 13:59:17 +0000 to 2022-07-24 21:10:46 +0000
- Make the empty rustc-wrapper test more explicit. (rust-lang/cargo#10899)
- expand RUSTC_WRAPPER docs (rust-lang/cargo#10896)
- Stabilize Workspace Inheritance (rust-lang/cargo#10859)
- Fix typo in unstable docs: s/PROGJCT/PROJECT/ (rust-lang/cargo#10890)
- refactor(source): Open query API for adding more types of queries (rust-lang/cargo#10883)
|
|
|
|
|
|
|
|
Fix some broken link fragments.
An exception for link fragments starting with `-` was added in #49590. However, it is not clear what issues were encountered at the time. Perhaps those were fixed in the meantime.
This removes the exception, and fixes a couple of broken links that were skipped due to it.
|
|
ra-sync-and-pms-component
|
|
Sync rustc_codegen_cranelift
This time most of the changes are bugfixes. No exciting new features to report. Thanks `@matthiaskrgr` for reporting a bunch of crashes!
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
|
|
Resolve function lifetime elision on the AST
~Based on https://github.com/rust-lang/rust/pull/97720~
Lifetime elision for functions is purely syntactic in nature, so can be resolved on the AST.
This PR replicates the elision logic and diagnostics on the AST, and replaces HIR-based resolution by a `delay_span_bug`.
This refactor allows for more consistent diagnostics, which don't have to guess the original code from HIR.
r? `@petrochenkov`
|
|
|
|
|
|
|
|
Cranelift started depending on a couple of new crates
|
|
Address issue #99265 by checking each positionally used argument
to see if the argument is named and adding a lint to use the name
instead. This way, when named arguments are used positionally in a
different order than their argument order, the suggested lint is
correct.
For example:
```
println!("{b} {}", a=1, b=2);
```
This will now generate the suggestion:
```
println!("{b} {a}", a=1, b=2);
```
Additionally, this check now also correctly replaces or inserts
only where the positional argument is (or would be if implicit).
Also, width and precision are replaced with their argument names
when they exists.
Since the issues were so closely related, this fix for issue #99265
also fixes issue #99266.
Fixes #99265
Fixes #99266
|
|
|
|
|
|
|
|
order isn't guaranteed
(And, in fact, it failed on i686)
|
|
|
|
- use `path` instead of `paths`
- don't mark rust-analyzer as an optional tool
- print the cargo command that's run in the proc-macro-test build script
this originally was part of a change to fix `test --stage 0 rust-analyzer`,
but I'm going to leave that for a separate PR so it's easier to review.
|
|
|
|
|
|
|
|
'977e12a0bdc3e329af179ef3a9d466af9eb613bb'
git-subtree-dir: src/tools/rust-analyzer
git-subtree-mainline: 3c98486a0cdb6d92f0fca34ffb1fd46c0e498653
git-subtree-split: 977e12a0bdc3e329af179ef3a9d466af9eb613bb
|
|
|
|
Upgrade indexmap and thorin-dwp to use hashbrown 0.12
This removes the last dependencies on hashbrown 0.11.
This also upgrades to hashbrown 0.12.3 to fix a double-free (#99372).
|
|
Add fine-grained LLVM CFI support to the Rust compiler
This PR improves the LLVM Control Flow Integrity (CFI) support in the Rust compiler by providing forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types.
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue https://github.com/rust-lang/rust/issues/89653).
LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).
Thank you again, `@eddyb,` `@nagisa,` `@pcc,` and `@tmiasko` for all the help!
|
|
Rollup of 6 pull requests
Successful merges:
- #99298 (Make `ui-fulldeps/gated-plugins` and `ui-fulldeps/multiple-plugins` tests stage 2 only)
- #99396 (Add some additional double-adjustment regression tests)
- #99449 (Do not resolve associated const when there is no provided value)
- #99595 (Mark atomics as unsupported on thumbv6m)
- #99627 (Lock stdout once when listing tests)
- #99638 (Remove Clean trait implementation for hir::Ty and middle::Ty)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Do not resolve associated const when there is no provided value
Fixes #98629, since now we just delay a bug when we're not able to evaluate a const item due to the value not actually being provided by anything. This means compilation proceeds forward to where the "missing item in impl" error is emitted.
----
The root issue here is that when we're looking for the defining `LeafDef` in `resolve_associated_item`, we end up getting the trait's AssocItem instead of the impl's AssocItem (which does not exist). This resolution "succeeds" even if the trait's item has no default value, and then since this item has no value to evaluate, it turns into a const eval error.
This root issue becomes problematic (as in #98629) when this const eval error happens in wfcheck (for example, due to normalizing the param-env of something that references this const). Since this happens sooner than the check that an impl actually provides all of the items that a trait requires (which happens during later typecheck), we end up aborting compilation early with only this un-informative message.
I'm not exactly sure _why_ this bug arises due to #96591 -- perhaps valtrees are evaluated more eagerly than in the old system?
r? ``@oli-obk`` or ``@lcnr`` since y'all are familiar with const eval and reviewed #96591, though feel free to reassign.
This is a regression from stable to beta, so I would be open to considering this for beta backport. It seems correct to me, especially given the improvements in the other UI tests this PR touches, but may have some side-effects that I'm unaware of...?
|
