| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Change the way that underline positions are calculated by delaying using
the "visual" column position until the last possible moment, instead
using the "file"/byte position in the file, and then calculating visual
positioning as late as possible. This should make the underlines more
resilient to non-1-width unicode chars.
Unfortunately, as part of this change (which fixes some visual bugs)
comes with the loss of some eager tab codepoint handling, but the output
remains legible despite some minor regression on the "margin trimming"
logic.
|
|
When encountering a single line span that is wider than the terminal, we keep context at the start and end of the span but otherwise remove the code from the middle. This is somewhat independent from whether the left and right margins of the output have been trimmed as well.
```
error[E0308]: mismatched types
--> $DIR/long-span.rs:6:15
|
LL | ... = [0, 0, 0, 0, ..., 0, 0];
| ^^^^^^^^^^^^^...^^^^^^^ expected `u8`, found `[{integer}; 1681]`
```
Address part of #137680 (missing handling of the long suggestion). Fix #125581.
|
|
|
|
Properly record metavar spans for other expansions other than TT
This properly records metavar spans for nonterminals other than tokentree. This means that we operations like `span.to(other_span)` work correctly for macros. As you can see, other diagnostics involving metavars have improved as a result.
Fixes #132908
Alternative to #133270
cc `@ehuss`
cc `@petrochenkov`
|
|
|
|
|
|
|
|
span rendering
|
|
Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments.
|
|
|
|
|
|
Compiletest: add proc-macro header
This adds a `proc-macro` header to simplify using proc-macros, and to reduce boilerplate. This header works similar to the `aux-build` header where you pass a path for a proc-macro to be built.
This allows the `force-host`, `no-prefer-dynamic` headers, and `crate_type` attribute to be removed. Additionally it uses `--extern` like `aux_crate` (allows implicit `extern crate` in 2018) and `--extern proc_macro` (to place in the prelude in 2018).
~~This also includes a secondary change which defaults the edition of proc-macros to 2024. This further reduces boilerplate (removing `extern crate proc_macro;`), and allows using modern Rust syntax. I was a little on the fence including this. I personally prefer it, but I can imagine it might be confusing to others.~~ EDIT: Removed
Some tests were changed so that when there is a chain of dependencies A→B→C, that the `@ proc-macro` is placed in `B` instead of `A` so that the `--extern` flag works correctly (previously it depended on `-L` to find `C`). I think this is better to make the dependencies more explicit. None of these tests looked like the were actually testing this behavior.
There is one test that had an unexplained output change: `tests/ui/macros/same-sequence-span.rs`. I do not know why it changed, but it didn't look like it was particularly important. Perhaps there was a normalization issue?
This is currently not compatible with the rustdoc `build-aux-docs` header. It can probably be fixed, I'm just not feeling motivated to do that right now.
### Implementation steps
- [x] Document this new behavior in rustc-dev-guide once we figure out the specifics. https://github.com/rust-lang/rustc-dev-guide/pull/2149
|
|
fix confusing diagnostic for reserved `##`
Closes #131615
|
|
|
|
Use edition of `macro_rules` when compiling the macro
This changes the edition assigned to a macro_rules macro when it is compiled to use the edition of where the macro came from instead of the local crate's edition.
This fixes a problem when a macro_rules macro is created by a proc-macro. Previously that macro would be tagged with the local edition, which would cause problems with using the correct edition behavior inside the macro. For example, the check for unsafe attributes would cause errors in 2024 when using proc-macros from older editions.
This is partially related to https://github.com/rust-lang/rust/issues/132906. Unfortunately this is only a half fix for that issue. It fixes the error that happens in 2024, but does not fix the lint firing in 2021. I'm still trying to think of some way to fix that, but I'm running low on ideas.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stabilize `unsafe_attributes`
# Stabilization report
## Summary
This is a tracking issue for the RFC 3325: unsafe attributes
We are stabilizing `#![feature(unsafe_attributes)]`, which makes certain attributes considered 'unsafe', meaning that they must be surrounded by an `unsafe(...)`, as in `#[unsafe(no_mangle)]`.
RFC: rust-lang/rfcs#3325
Tracking issue: #123757
## What is stabilized
### Summary of stabilization
Certain attributes will now be designated as unsafe attributes, namely, `no_mangle`, `export_name`, and `link_section` (stable only), and these attributes will need to be called by surrounding them in `unsafe(...)` syntax. On editions prior to 2024, this is simply an edition lint, but it will become a hard error in 2024. This also works in `cfg_attr`, but `unsafe` is not allowed for any other attributes, including proc-macros ones.
```rust
#[unsafe(no_mangle)]
fn a() {}
#[cfg_attr(any(), unsafe(export_name = "c"))]
fn b() {}
```
For a table showing the attributes that were considered to be included in the list to require unsafe, and subsequent reasoning about why each such attribute was or was not included, see [this comment here](https://github.com/rust-lang/rust/pull/124214#issuecomment-2124753464)
## Tests
The relevant tests are in `tests/ui/rust-2024/unsafe-attributes` and `tests/ui/attributes/unsafe`.
|
|
|
|
This doesn't work for translated compiler error messages.
|
|
Relevant for the deprecation of `CommandExt::before_exit` in #125970.
|
|
|
|
r=compiler-errors
Stabilize unsafe extern blocks (RFC 3484)
# Stabilization report
## Summary
This is a tracking issue for the RFC 3484: Unsafe Extern Blocks
We are stabilizing `#![feature(unsafe_extern_blocks)]`, as described in [Unsafe Extern Blocks RFC 3484](https://github.com/rust-lang/rfcs/pull/3484). This feature makes explicit that declaring an extern block is unsafe. Starting in Rust 2024, all extern blocks must be marked as unsafe. In all editions, items within unsafe extern blocks may be marked as safe to use.
RFC: https://github.com/rust-lang/rfcs/pull/3484
Tracking issue: #123743
## What is stabilized
### Summary of stabilization
We now need extern blocks to be marked as unsafe and items inside can also have safety modifiers (unsafe or safe), by default items with no modifiers are unsafe to offer easy migration without surprising results.
```rust
unsafe extern {
// sqrt (from libm) may be called with any `f64`
pub safe fn sqrt(x: f64) -> f64;
// strlen (from libc) requires a valid pointer,
// so we mark it as being an unsafe fn
pub unsafe fn strlen(p: *const c_char) -> usize;
// this function doesn't say safe or unsafe, so it defaults to unsafe
pub fn free(p: *mut core::ffi::c_void);
pub safe static IMPORTANT_BYTES: [u8; 256];
pub safe static LINES: SyncUnsafeCell<i32>;
}
```
## Tests
The relevant tests are in `tests/ui/rust-2024/unsafe-extern-blocks`.
## History
- https://github.com/rust-lang/rust/pull/124482
- https://github.com/rust-lang/rust/pull/124455
- https://github.com/rust-lang/rust/pull/125077
- https://github.com/rust-lang/rust/pull/125522
- https://github.com/rust-lang/rust/issues/126738
- https://github.com/rust-lang/rust/issues/126749
- https://github.com/rust-lang/rust/issues/126755
- https://github.com/rust-lang/rust/pull/126757
- https://github.com/rust-lang/rust/pull/126758
- https://github.com/rust-lang/rust/issues/126756
- https://github.com/rust-lang/rust/pull/126973
- https://github.com/rust-lang/rust/pull/127535
- https://github.com/rust-lang/rustfmt/pull/6204
## Unresolved questions
I am not aware of any unresolved questions.
|
|
Add migration lint for 2024 prelude additions
This adds the migration lint for the newly ambiguous methods `poll` and `into_future`. When these methods are used on types implementing the respective traits, it will be ambiguous in the future, which can lead to hard errors or behavior changes depending on the exact circumstances.
tracked by #121042
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
r? compiler-errors as the method prober
|
|
This adds the migration lint for the newly ambiguous methods `poll` and
`into_future`. When these methods are used on types implementing the
respective traits, it will be ambiguous in the future, which can lead to
hard errors or behavior changes depending on the exact circumstances.
|
|
|
|
Rename `deprecated_safe` lint to `deprecated_safe_2024`
Create a lint group `deprecated_safe` that includes `deprecated_safe_2024`.
Addresses https://github.com/rust-lang/rust/issues/124866#issuecomment-2142814375.
r? `@ehuss`
|
|
|
|
Create a lint group `deprecated_safe` that includes
`deprecated_safe_2024`.
Addresses https://github.com/rust-lang/rust/issues/124866#issuecomment-2142814375.
|
|
|
|
chenyukang:yukang-fix-126756-unsafe-suggestion-error, r=spastorino
Fix bad replacement for unsafe extern block suggestion
Fixes #126756
r? ``@spastorino``
link #123743
|
|
|
|
It currently goes one token too far.
Example: line 259 of `tests/ui/abi/compatibility.rs`:
```
test_abi_compatible!(fn_fn, fn(), fn(i32) -> i32);
```
This commit changes the span for the second element from `fn(),` to
`fn()`, i.e. removes the extraneous comma.
|
|
|
|
|
|
Addresses https://github.com/rust-lang/rust/pull/124636#issuecomment-2132119534.
I think that the diff display regresses a little, because it's no longer
showing the `+` to show where the `unsafe {}` is added. I think it's
still fine.
|
|
Unsafe extern blocks
This implements RFC 3484.
Tracking issue #123743 and RFC https://github.com/rust-lang/rfcs/pull/3484
This is better reviewed commit by commit.
|
|
Fixes #125875.
|
