Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 8 pull requests #124642

Closed
wants to merge 25 commits into from
Closed

Rollup of 8 pull requests #124642

wants to merge 25 commits into from

Conversation

fmease
Copy link
Member

@fmease fmease commented May 3, 2024

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

GKFX and others added 25 commits May 1, 2024 19:59
library/backtrace also declares a feature called `gimli-symbolize` which
appear used, but the feature in std with the same name is unused, so
remove it.
`ConstKind::Value` is the only variant where control flow leaves the
first match on `impl_ct.kind()`, so there is no need for a second match
on the same expression later on.
Sort them, and remove the unused ones (`lint_reasons` and
`proc_macro_span`).
They each have a single call site.
Control flow never gets past the end of the `ExpandResult::Retry` match
arm, due to the `span_bug` and the `continue`. Therefore, the code after
the match can only be reached from the `ExpandResult::Ready` arm.

This commit moves that code after the match into the
`ExpandResult::Ready` arm, avoiding the need for the `continue` in the
`ExpandResult::Retry` arm.
Too clever by half, IMO.
Alongside the existing `Invocation::span`.
Because the type is not obvious, and this clarifies things.
It is currently an enum and the `tts` and `idx` fields are repeated
across the two variants.

This commit splits it into a struct `Frame` and an enum `FrameKind`, to
factor out the duplication. The commit also renames `Frame::new` as
`Frame::new_delimited` and adds `Frame::new_sequence`. I.e. both
variants now have a constructor.
…workingjubilee

Describe and use CStr literals in CStr and CString docs

Mention CStr literals in the description of both types, and use them in some of the code samples for CStr. This is intended to make C string literals more discoverable.

Additionally, I don't think the orange "This example is not tested" warnings are very encouraging, so I have made the examples on `CStr` build.
run-make-support: preserve tooks.mk behavior for EXTRACXXFLAGS

In rust-lang#123149 when trying to add a command wrapper for `cc`, I didn't preserve the behavior of tools.mk completely: tools.mk had

```makefile
# Extra flags needed to compile a working executable with the standard library
ifdef IS_WINDOWS
ifdef IS_MSVC
	#EXTRACFLAGS := ws2_32.lib userenv.lib advapi32.lib bcrypt.lib ntdll.lib synchronization.lib
else
	#EXTRACFLAGS := -lws2_32 -luserenv -lbcrypt -lntdll -lsynchronization
	EXTRACXXFLAGS := -lstdc++
	#EXTRARSCXXFLAGS := -l static:-bundle=stdc++
endif
else
ifeq ($(UNAME),Darwin)
	#EXTRACFLAGS := -lresolv
	EXTRACXXFLAGS := -lc++
	#EXTRARSCXXFLAGS := -lc++
else
ifeq ($(UNAME),FreeBSD)
	#EXTRACFLAGS := -lm -lpthread -lgcc_s
else
ifeq ($(UNAME),SunOS)
	#EXTRACFLAGS := -lm -lpthread -lposix4 -lsocket -lresolv
else
ifeq ($(UNAME),OpenBSD)
	#EXTRACFLAGS := -lm -lpthread -lc++abi
	#RUSTC := $(RUSTC) -C linker="$(word 1,$(CC:ccache=))"
else
	#EXTRACFLAGS := -lm -lrt -ldl -lpthread
	EXTRACXXFLAGS := -lstdc++
	#EXTRARSCXXFLAGS := -lstdc++
endif
endif
endif
endif
endif
```

Note that for {`FreeBSD`, `SunOs`, `OpenBSD`} the `-lstdc++` flag is *not* passed, so `EXTRACXXFLAGS` for those platforms should be an empty `vec![]`.

r? ghost (testing this with PR CI)
…kingjubilee

library/std: Remove unused `gimli-symbolize` feature

library/backtrace also declares a feature called `gimli-symbolize` which appear used, but the feature in std with the same name is unused, so remove it.
… r=compiler-errors

`rustc_expand` cleanups

Some cleanups I made while looking through this code. Nothing that requires any real domain-specific knowledge about this crate.

r? `@michaelwoerister`
variable-precision float operations can differ depending on optimization levels

Follow-up to rust-lang#121793 and rust-lang#118217 that accounts for optimizations changing the precision of these functions.

Fixes rust-lang#109118
Fixes rust-lang#71355
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels May 3, 2024
@fmease fmease closed this May 3, 2024
@fmease fmease deleted the rollup-6xobka1 branch May 3, 2024 01:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants