| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
attributes manually
|
|
MIR-build: No longer emit assumes in enum-as casting
This just uses the `valid_range` from the backend, so it's duplicating the range metadata that now we include on parameters and loads, and thus no longer seems to be useful -- notably there's no codegen test failures from removing it.
(Because it's using data from the same source as the backend annotations, it doesn't do anything to mitigate things like rust-lang/rust#144388 where the range in the layout is more permissive than the actual possible discriminants. A variant of this that actually checked the discriminants more specifically might be useful, so could potentially be added in future, but I don't think the *current* checks are actually providing value.)
r? mir
Randomly turns out that this
Fixes https://github.com/rust-lang/rust/issues/121097
|
|
|
|
|
|
|
|
|
|
This just uses the `valid_range` from the backend, so it's duplicating the range metadata that now we include on parameters and loads.
|
|
Rollup of 15 pull requests
Successful merges:
- rust-lang/rust#143374 (Unquerify extern_mod_stmt_cnum.)
- rust-lang/rust#143838 (std: net: uefi: Add support to query connection data)
- rust-lang/rust#144014 (don't link to the nightly version of the Edition Guide in stable lints)
- rust-lang/rust#144094 (Ensure we codegen the main fn)
- rust-lang/rust#144218 (Use serde for target spec json deserialize)
- rust-lang/rust#144221 (generate elf symbol version in raw-dylib)
- rust-lang/rust#144240 (Add more test case to check if the false note related to sealed trait suppressed)
- rust-lang/rust#144247 (coretests/num: use ldexp instead of hard-coding a power of 2)
- rust-lang/rust#144276 (Use less HIR in check_private_in_public.)
- rust-lang/rust#144278 (add Rev::into_inner)
- rust-lang/rust#144317 (pass build.npm from bootstrap to tidy and use it for npm install)
- rust-lang/rust#144320 (rustdoc: avoid allocating a temp String for aliases in search index)
- rust-lang/rust#144334 (rustc_resolve: get rid of unused rustdoc::span_of_fragments_with_expansion)
- rust-lang/rust#144335 (Don't suggest assoc ty bound on non-angle-bracketed problematic assoc ty binding)
- rust-lang/rust#144358 (Stop using the old `validate_attr` logic for stability attributes)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Since we don't build std for these and don't provide any support for
them, these can trivially be changed to link dynamically by default.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Update josh sync documentation
|
|
Stop using the old `validate_attr` logic for stability attributes
I think this was accidentally missed when implementing the stability attributes?
r? `````@oli-obk`````
cc `````@jdonszelmann`````
|
|
Don't suggest assoc ty bound on non-angle-bracketed problematic assoc ty binding
Fixes https://github.com/rust-lang/rust/issues/140543.
|
|
r=GuillaumeGomez
rustc_resolve: get rid of unused rustdoc::span_of_fragments_with_expansion
This function can cause false negatives if used incorrectly (usually "do any of the doc fragments come from a macro" is the wrong question to ask), and thus it is unused.
r? `````@GuillaumeGomez`````
|
|
r=GuillaumeGomez
rustdoc: avoid allocating a temp String for aliases in search index
Here's the optimization I talked about in https://github.com/rust-lang/rust/pull/143988#discussion_r2208524163
I got around the Serialize issue using the newtype pattern. The wrapper type could be factored out into a helper that would work with anything that impls `AsRef<&str>`, but I'm not sure if that would be helpful anywhere else.
r? ``````@GuillaumeGomez``````
|
|
pass build.npm from bootstrap to tidy and use it for npm install
followup to rust-lang/rust#142924
r? ```@Kobzol```
|
|
add Rev::into_inner
Tracking issue: rust-lang/rust#144277
|
|
Use less HIR in check_private_in_public.
r? ````````@petrochenkov````````
|
|
coretests/num: use ldexp instead of hard-coding a power of 2
r? `````@tgross35`````
|
|
yuk1ty:false-sealed-traits-note-reported-in-another-issue, r=fee1-dead
Add more test case to check if the false note related to sealed trait suppressed
Closes rust-lang/rust#143121
I started to fix the issue but I found that this one has already been addressed in this PR (https://github.com/rust-lang/rust/pull/143431). I added an additional test to prove the reported thing has been resolved just in case.
I think we can discard this pull request if there's no need to add such kind of tests👍🏻
|
|
generate elf symbol version in raw-dylib
For link names like `aaa@bbb`, it generates a symbol named `aaa` and a version named `bbb`.
For link names like `aaa\0bbb`, `aaa@`@bbb`` or `aa@bb@cc`, it emits errors.
It adds a test that the executable is linked with glibc using raw-dylib.
cc rust-lang/rust#135694
|
|
Use serde for target spec json deserialize
The previous manual parsing of `serde_json::Value` was a lot of complicated code and extremely error-prone. It was full of janky behavior like sometimes ignoring type errors, sometimes erroring for type errors, sometimes warning for type errors, and sometimes just ICEing for type errors (the icing on the top).
Additionally, many of the error messages about allowed values were out of date because they were in a completely different place than the FromStr impls. Overall, the system caused confusion for users.
I also found the old deserialization code annoying to read. Whenever a `key!` invocation was found, one had to first look for the right macro arm, and no go to definition could help.
This PR replaces all this manual parsing with a 2-step process involving serde.
First, the string is parsed into a `TargetSpecJson` struct. This struct is a 1:1 representation of the spec JSON. It already parses all the enums and is very simple to read and write.
Then, the fields from this struct are copied into the actual `Target`. The reason for this two-step process instead of just serializing into a `Target` is because of a few reasons
1. There are a few transformations performed between the two formats
2. The default logic is implemented this way. Otherwise all the default field values would have to be spelled out again, which is suboptimal. With this logic, they fall out naturally, because everything in the json struct is an `Option`.
Overall, the mapping is pretty simple, with the vast majority of fields just doing a 1:1 mapping that is captured by two macros. I have deliberately avoided making the macros generic to keep them simple.
All the `FromStr` impls now have the error message right inside them, which increases the chance of it being up to date. Some "`from_str`" impls were turned into proper `FromStr` impls to support this.
The new code is much less involved, delegating all the JSON parsing logic to serde, without any manual type matching.
This change introduces a few breaking changes for consumers. While it is possible to use this format on stable, it is very much subject to change, so breaking changes are expected. The hope is also that because of the way stricter behavior, breaking changes are easier to deal with, as they come with clearer error messages.
1. Invalid types now always error, everywhere. Previously, they would sometimes error, and sometimes just be ignored (which meant the users JSON was still broken, just silently!)
2. This now makes use of `deny_unknown_fields` instead of just warning on unused fields, which was done previously. Serde doesn't make it easy to get such warning behavior, which was the primary reason that this now changed. But I think error behavior is very reasonable too. If someone has random stale fields in their JSON, it is likely because these fields did something at some point but no longer do, and the user likely wants to be informed of this so they can figure out what to do.
This is also relevant for the future. If we remove a field but someone has it set, it probably makes sense for them to take a look whether they need this and should look for alternatives, or whether they can just delete it. Overall, the JSON is made more explicit.
This is the only expected breakage, but there could also be small breakage from small mistakes. All targets roundtrip though, so it can't be anything too major.
fixes rust-lang/rust#144153
|
|
don't link to the nightly version of the Edition Guide in stable lints
As reported in rust-lang/rust#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.
This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang/rust#144006.
|
|
Ensure we codegen the main fn
This fixes two bugs. The one that was identified in the linked issue is that when we have a `main` function, mono collection didn't consider it as an extra collection root.
The other is that since CGU partitioning doesn't know about the call edges between the entrypoint functions, naively it can put them in different CGUs and mark them all as internal. Which would result in LLVM just deleting all of them. There was an existing hack to exclude `lang = "start"` from internalization, which I've extended to include `main`.
Fixes https://github.com/rust-lang/rust/issues/144052
|
|
don't link to the nightly version of the Edition Guide in stable lints
As reported in rust-lang/rust#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.
This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang/rust#144006.
|
|
std: net: uefi: Add support to query connection data
- Use EFI_TCP4_GET_MODE_DATA to be able to query for ttl, nodelay, peer_addr and socket_addr.
- peer_addr is needed for implementation of `accept`.
- cc `````@nicholasbishop`````
- Also a heads up. The UEFI spec seems to be wrong or something for [EFI_TCP4_CONFIG_DATA](https://uefi.org/specs/UEFI/2.11/28_Network_Protocols_TCP_IP_and_Configuration.html#efi-tcp4-protocol-getmodedata). `ControlOption` should be a pointer as seen in [edk2](https://github.com/tianocore/edk2/blob/a1b509c1a453815acbc6c8b0fc5882fd03a6f2c0/MdePkg/Include/Protocol/Tcp4.h#L97).
|
|
Unquerify extern_mod_stmt_cnum.
Based on https://github.com/rust-lang/rust/pull/143247
r? `````@ghost````` for perf
|
|
* Fix riscv testing. Previously the mod tests; would be looking for
src/detect/os/tests.rs.
* Replace a test with an unnamed const item. It is testing that no
warnings are emitted. It doesn't contain any checks that need to run
at runtime. Replacing the test allows removing the tidy:skip directive
for test locations.
|
|
Use `Scope::Module` with the crate root module inside instead, which should be identical.
|
|
Various refactors to the LTO handling code (part 2)
Continuing from https://github.com/rust-lang/rust/pull/143388 this removes a bit of dead code and moves the LTO symbol export calculation from individual backends to cg_ssa.
|
|
make the missing-MIR message more clear
|
|
|
|
|
|
|
|
Small typo fix for the `arc_with_non_send_sync` lint.
changelog: none
|
|
|
|
We lost the following comment during refactorings:
The current code for niche-filling relies on variant indices instead of actual discriminants, so enums with explicit discriminants (RFC 2363) would misbehave.
|
|
|
|
resolve: Make disambiguators for underscore bindings module-local (take 2)
The difference with https://github.com/rust-lang/rust/pull/144013 can be seen in the second commit.
Now we just keep a separate disambiguator counter in every `Module`, instead of a global counter in `Resolver`.
This will be ok for parallel import resolution because we'll need to lock the module anyway when updating `resolutions` and other fields in it.
And for external modules the disabmiguator could be just passed as an argument to `define_extern`, without using any cells or locks, once https://github.com/rust-lang/rust/pull/143884 lands.
Unblocks https://github.com/rust-lang/rust/pull/143884.
|
|
Fix generate_trait_from_impl whitespace after vis
|
|
|
|
Make it clearer where unit tests are allowed and restrict standard
library unit tests inside the same package to std_detect, std and test.
|
|
|
|
|
|
|
|
Input:
```rust
struct Foo;
impl F$0oo {
pub fn a_func() -> Option<()> {
Some(())
}
}
```
Old:
```rust
struct Foo;
trait NewTrait {
fn a_func() -> Option<()>;
}
impl NewTrait for Foo {
fn a_func() -> Option<()> {
Some(())
}
}
```
This PR fixed:
```rust
struct Foo;
trait NewTrait {
fn a_func() -> Option<()>;
}
impl NewTrait for Foo {
fn a_func() -> Option<()> {
Some(())
}
}
```
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: efd420c770bb179537c01063e98cb6990c439654
Filtered ref: d11dbbb02905535a89393e80c24274bee81fa928
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to efd420c770bb179537c01063e98cb6990c439654.
|
|
Create an `AllocId` for `ConstValue::Slice`.
This PR modifies `ConstValue::Slice` to use an `AllocId` instead of directly manipulating the allocation. This was originally proposed by https://github.com/rust-lang/rust/pull/115764 but was a perf regression.
Almost 2 years later, enough code has changed to make this a perf improvement: https://github.com/rust-lang/rust/pull/116707#issuecomment-3067158777
|
