| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Make copy/copy_nonoverlapping fn's again
Make copy/copy_nonoverlapping fn's again, rather than intrinsics.
This a short-term change to address issue #84297.
It effectively reverts PRs #81167 #81238 (and part of #82967), #83091, and parts of #79684.
|
|
Create different inference variables for different defining uses of TAITs
Fixes #73481
r? `@nikomatsakis`
cc `@oli-obk`
|
|
Peephole optimize `x == false` and `x != true`
This adds peephole optimizations to make `x == false`, `false == x`, `x != true`, and `true != x` get optimized to `!x` in the `instcombine` MIR pass. That pass currently handles `x == true` -> `x` already.
|
|
Include macro name in 'local ambiguity' error
Currently, we only point at the span of the macro argument. When the
macro call is itself generated by another macro, this can make it
difficult or impossible to determine which macro is responsible for
producing the error.
|
|
Enable rustdoc to document safe wasm intrinsics
This commit fixes an issue not found during #84988 where rustdoc is used
to document cross-platform intrinsics but it was requiring that
functions which use `#[target_feature]` are `unsafe` erroneously, even
if they're WebAssembly specific. Rustdoc today, for example, already has
a special case where it enables annotations like
`#[target_feature(enable = "simd128")]` on platforms other than
WebAssembly. The purpose of this commit is to relax the "require all
`#[target_feature]` functions are `unsafe`" requirement for all targets
whenever rustdoc is running, enabling all targets to fully document
other targets, such as WebAssembly, where intrinsics functions aren't
always `unsafe`.
|
|
Display defaults on const params- rustdoc
previously rustdoc would render this struct declaration:
`pub struct Foo<const N: usize = 10>;`
as:
`pub struct Foo<const N: usize>;`
this PR changes it to render correctly
|
|
Comment out unused error codes and add description for E0316
I have added an extended description of `E0316` and commented out a bunch of unused error codes to make clear the fact that they are no longer in use. You can check for yourself with
```shell
for ec in \
E0314 E0315 E0473 E0474 E0475 E0479 E0480 E0481 \
E0483 E0484 E0485 E0486 E0487 E0488 E0489
do
if [ ! -z "`grep -r $ec compiler/* --exclude-dir=rustc_error_codes`" ]
then
echo $ec
false
fi
done
```
i.e. these error codes appear nowhere in the compiler code and thus cannot be emitted.
r? ```@GuillaumeGomez```
|
|
Search description codeblock
The codeblocks are not displayed correctly:
This PR interprets the HTML correctly (and still prevent invalid HTML because of how it inserts it):
r? ```@jsha```
|
|
Type page font weight
Fixes https://github.com/rust-lang/rust/issues/86069.
r? ```@jsha```
|
|
Default panic message should print Box<dyn Any>
Closes #86039
Prior to this patch, the panic message from running the following code would be `thread 'main' panicked at 'Box<Any>'...`
```rust
use std::panic::panic_any;
fn main() {
panic_any(42);
}
```
This patch updates the phrasing to be more consistent. It now instead shows the following panic message:
```
thread 'main' panicked at 'Box<dyn Any>', ...
```
It's a very small fix 😄
|
|
Currently, we only point at the span of the macro argument. When the
macro call is itself generated by another macro, this can make it
difficult or impossible to determine which macro is responsible for
producing the error.
|
|
This commit fixes an issue not found during #84988 where rustdoc is used
to document cross-platform intrinsics but it was requiring that
functions which use `#[target_feature]` are `unsafe` erroneously, even
if they're WebAssembly specific. Rustdoc today, for example, already has
a special case where it enables annotations like
`#[target_feature(enable = "simd128")]` on platforms other than
WebAssembly. The purpose of this commit is to relax the "require all
`#[target_feature]` functions are `unsafe`" requirement for all targets
whenever rustdoc is running, enabling all targets to fully document
other targets, such as WebAssembly, where intrinsics functions aren't
always `unsafe`.
|
|
|
|
generic parameters
|
|
|
|
|
|
r=Mark-Simulacrum
Revert "Merge CrateDisambiguator into StableCrateId"
This reverts https://github.com/rust-lang/rust/pull/85804
|
|
|
|
This reverts commit c76b1b031753fc08a18a3906d828683476c1e595.
|
|
This reverts commit e0e0cfa6492292d0b905b07a4ed727f4e1aefc80.
|
|
Fix ICE during type layout when there's a `[type error]`
Fixes #84108.
Based on estebank's [comment], except I used `delay_span_bug` because it
should work in more cases, and I think it expresses its intent more
clearly.
r? `@estebank`
[comment]: https://github.com/rust-lang/rust/issues/84108#issuecomment-818916848
|
|
Driver improvements
This PR contains a couple of cleanups for the driver and a few small improvements for the custom codegen backend interface. It also implements `--version` and `-Cpasses=list` support for custom codegen backends.
|
|
This patch fixes tests from failing that were matching on `Box<Any>`,
which was the old panic message. Since the new panic message is `Box<dyn
Any>`, the tests have been updated to match against this instead.
|
|
Remove `_` from E0121 diagnostic suggestions
Fixes #86021.
|
|
Fix two ICEs in the parser
This pull request fixes #84104 and fixes #84148. The latter is caused by an invalid `assert_ne!()` in the parser, which I have simply removed because the error is then caught in another part of the parser.
#84104 is somewhat more subtle and has to do with a suggestion to remove extraneous `<` characters; for instance:
```rust
fn main() {
foo::<Ty<<<i32>();
}
```
currently leads to
```
error: unmatched angle brackets
--> unmatched-langle.rs:2:10
|
2 | foo::<Ty<<<i32>();
| ^^^ help: remove extra angle brackets
```
which is obviously wrong and stems from the fact that the code for issuing the above suggestion does not consider the possibility that there might be other tokens in between the opening angle brackets. In #84104, this has led to a span being generated that ends in the middle of a multi-byte character (because the code issuing the suggestion thought that it was only skipping over `<`, which are single-byte), causing an ICE.
|
|
|
|
|
|
parser: Ensure that all nonterminals have tokens after parsing
`parse_nonterminal` should always result in something with tokens.
This requirement wasn't satisfied in two cases:
- `stmt` nonterminal with expression statements (e.g. `0`, or `{}`, or `path + 1`) because `fn parse_stmt_without_recovery` forgot to propagate `force_collect` in some cases.
- `expr` nonterminal with expressions with built-in attributes (e.g. `#[allow(warnings)] 0`) due to an incorrect optimization in `fn parse_expr_force_collect`, it assumed that all expressions starting with `#` have their tokens collected during parsing, but that's not true if all the attributes on that expression are built-in and inert.
(Discovered when trying to implement eager `cfg` expansion for all attributes https://github.com/rust-lang/rust/pull/83824#issuecomment-817317170.)
r? `@Aaron1011`
|
|
Rollup of 8 pull requests
Successful merges:
- #85436 (Avoid cloning cache key)
- #85772 (Preserve metadata w/ Solaris-like linkers.)
- #85920 (Tweak wasm_base target spec to indicate linker is not GNU and update linker inferring logic for wasm-ld.)
- #85930 (Update standard library for IntoIterator implementation of arrays )
- #85972 (Rustdoc html fixes)
- #86028 (Drop an `if let` that will always succeed)
- #86043 (don't clone attrs)
- #86047 (Don't fire `invalid_doc_attributes` on `extern crate` items)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Don't fire `invalid_doc_attributes` on `extern crate` items
Fixes https://github.com/rust-lang/rust/issues/86046.
|
|
Update standard library for IntoIterator implementation of arrays
This PR partially resolves issue #84513 of updating the standard library part.
I haven't found any remaining doctest examples which are using iterators over e.g. &i32 instead of just i32 in the standard library. Can anyone point me to them if there's remaining any?
Thanks!
r? ```@m-ou-se```
|
|
Show test type during prints
Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run.
During #83857 I got the feedback that test output can be confusing.
For the moment test output is
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) ... ok
test $DIR/test-type.rs - f (line 21) ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
I propose to change output by indicating the test type as
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) - compile ... ok
test $DIR/test-type.rs - f (line 21) - compile fail ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the "...".
------------
Note: this is a proof of concept, the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior, maybe `TestType::DocTest` could have fields
|
|
Partial support for raw-dylib linkage
First cut of functionality for issue #58713: add support for `#[link(kind = "raw-dylib")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions, or the `#[link_ordinal]` attribute, or `#[link(kind = "raw-dylib")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern "stdcall"` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR.
This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.
|
|
|
|
BPF target support
This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker.
I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
|
|
Fix `deny(invalid_doc_attributes)`
Fixes https://github.com/rust-lang/rust/issues/85497.
|
|
|
|
r=Mark-Simulacrum
Revert "shrinking the deprecated method span"
Reverts rust-lang/rust#85617
Fixes: #86000
r? `@Mark-Simulacrum`
|
|
Allow raw pointers in SIMD types
Closes #85915 by loosening the strictness in typechecking and adding a test to guarantee it passes.
This still might be too strict, as references currently do pass monomorphization, but my understanding is that they are not guaranteed to be "scalar" in the same way.
|
|
Remove `doc(include)`
This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539, but technically it was for deprecating, not removing the feature altogether.
This should not be merged before #83366.
cc `@petrochenkov`
|
|
"raw-dylib")].
This does not yet support #[link_name] attributes on functions, the #[link_ordinal]
attribute, #[link(kind = "raw-dylib")] on extern blocks in bin crates, or
stdcall functions on 32-bit x86.
|
|
|
|
Note, the `Debug` impl is required.
|
|
don't suggest unsized indirection in where-clauses
Skip where-clauses when suggesting using indirection in combination with
`?Sized` bounds on type parameters.
Fixes #85943.
`@estebank` I think this doesn't conflict with your work in #85947; please let me know if you'd like me to cherry pick it to a new branch based on yours instead.
|
|
wasm: Make simd types passed via indirection again
This commit updates wasm target specs to use `simd_types_indirect: true`
again. Long ago this was added since wasm simd types were always
translated to `v128` under-the-hood in LLVM, meaning that it didn't
matter whether that target feature was enabled or not. Now, however,
`v128` is conditionally used in codegen depending on target features
enabled, meaning that it's possible to get linker errors about different
signatures in code that correctly uses simd types. The fix is the same
as for all other platforms, which is to pass the type indirectly.
|
|
Fix suggestion for removing &mut from &mut macro!().
Fixes #85933
Before: (Note the suggestions.)
```
error[E0308]: mismatched types
--> src/main.rs:2:21
|
2 | let _: String = &mut format!("");
| ------ ^^^^^^^^^^^^^^^^
| | |
| | expected struct `String`, found `&mut String`
| | help: consider removing the borrow: `mut format!("")`
| expected due to this
error[E0308]: mismatched types
--> src/main.rs:3:21
|
3 | let _: String = &mut (format!(""));
| ------ ^^^^^^^^^^^^^^^^^^
| | |
| | expected struct `String`, found `&mut String`
| | help: consider removing the borrow: `mut (format!(""))`
| expected due to this
```
After:
```
error[E0308]: mismatched types
--> src/main.rs:2:21
|
2 | let _: String = &mut format!("");
| ------ ^^^^^^^^^^^^^^^^
| | |
| | expected struct `String`, found `&mut String`
| | help: consider removing the borrow: `format!("")`
| expected due to this
error[E0308]: mismatched types
--> src/main.rs:3:21
|
3 | let _: String = &mut (format!(""));
| ------ ^^^^^^^^^^^^^^^^^^
| | |
| | expected struct `String`, found `&mut String`
| | help: consider removing the borrow: `format!("")`
| expected due to this
```
|
|
r=petrochenkov
Warn against boxed DST in `improper_ctypes_definitions` lint
Fixes #85714
|
|
rustdoc: link to stable/beta docs consistently in documentation
This is an alternative to https://github.com/rust-lang/rust/pull/84941 which fixes the problem consistently by linking to stable/beta for *all* items, not just for primitives.
## User-facing changes
- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.
Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.
## Implementation changes
- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel
This avoids linking to nightly docs on stable.
- Update rustdoc to use channel-dependent links for primitives from an
unknown crate
- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
cc Mark-Simulacrum - I know [you were dubious about this in the past](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Rustdoc.20unconditionally.20links.20to.20nightly.20libstd.20docs/near/231223124), but I'm not quite sure why? I see this as "just a bugfix", I don't know why rustdoc should unconditionally link to nightly.
cc dtolnay who commented in https://github.com/rust-lang/rust/issues/30693:
> I would welcome a PR to solve this permanently if anyone has ideas for how. I don't believe we need an RFC.
Fixes https://github.com/rust-lang/rust/issues/30693 (note that issue is marked as feature-accepted, although I don't see where it was discussed).
|
