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

Fix target_vendor in non-IDF Xtensa ESP32 targets #131170

Merged
merged 1 commit into from
Oct 8, 2024

Conversation

madsmtm
Copy link
Contributor

@madsmtm madsmtm commented Oct 2, 2024

rustc's Xtensa ESP32 targets are the following:

  • xtensa-esp32-none-elf
  • xtensa-esp32-espidf
  • xtensa-esp32s2-none-elf
  • xtensa-esp32s2-espidf
  • xtensa-esp32s3-none-elf
  • xtensa-esp32s3-espidf

The ESP-IDF targets already set target_vendor="espressif", however, the ESP32 is, from my understanding, produced by Espressif regardless of whether using the IDF or not, so we should set the target vendor there as well?

CC target maintainers of the affected targets: @MabezDev, @SergioGasquez


Digression: The targets are not really following the usual naming scheme, should probably have been named e.g. xtensa_esp32s2-espressif-none-elf? Or perhaps they should be combined into one target xtensa-espressif-none-elf, and then the user should set -Ctarget-cpu=esp32s2. But that's probably been discussed elsewhere, so I won't belabour the point.

The Xtensa ESP32 targets are the following:
- xtensa-esp32-none-elf
- xtensa-esp32-espidf
- xtensa-esp32s2-none-elf
- xtensa-esp32s2-espidf
- xtensa-esp32s3-none-elf
- xtensa-esp32s3-espidf

The ESP-IDF targets already set `target_vendor="espressif"`, however,
the ESP32 is produced by Espressif regardless of whether using the IDF
or not, so we should set the target vendor there as well.
@rustbot
Copy link
Collaborator

rustbot commented Oct 2, 2024

r? @Nadrieril

rustbot has assigned @Nadrieril.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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. labels Oct 2, 2024
@rustbot
Copy link
Collaborator

rustbot commented Oct 2, 2024

These commits modify compiler targets.
(See the Target Tier Policy.)

@workingjubilee
Copy link
Member

Hm. I don't think I've actually seen any discussion of it.

@Nadrieril
Copy link
Member

r? compiler

@rustbot rustbot assigned wesleywiser and unassigned Nadrieril Oct 2, 2024
Copy link
Contributor

@MabezDev MabezDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR looks fine to me, whilst it's possible this CPU configuration could run on another vendors chip, it's unlikely, so adding Espressif as the vendor makes sense.

Digression: The targets are not really following the usual naming scheme, should probably have been named e.g. xtensa_esp32s2-espressif-none-elf? Or perhaps they should be combined into one target xtensa-espressif-none-elf, and then the user should set -Ctarget-cpu=esp32s2. But that's probably been discussed elsewhere, so I won't belabour the point.

I would tend to agree, but this is also an issue with other targets too, such as riscv, where we have many targets with various CPU features enabled (imc, imac, etc). There hasn't really been a policy in place (that I was aware of) for this. If we go to the effort to changing the Xtensa targets, I believe there should be a policy decision that goes with it to change the riscv or other targets too (note that some of these are tier 2 already, whether that affects anything - I'm not sure the target policy addresses a target rename). Given that Espressif don't plan to make any more Xtensa based MCUs, I don't feel like this is too bad in it's current form.

@workingjubilee
Copy link
Member

The discussion about target vs. target-cpu can be pursued elsewhere. I agree that it should probably be mostly considered as part of making a larger policy change, rather than a burden specifically on the Espressif maintainers.

I am going to take the assent of the maintainer as sufficient for this change. While I am not a compiler team member, formally, I seem to have been baton-passed such authority when it comes to reviewing targets enough times. So:

@bors r+

@bors
Copy link
Contributor

bors commented Oct 7, 2024

📌 Commit 51537c6 has been approved by workingjubilee

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 7, 2024
@workingjubilee
Copy link
Member

@bors rollup=always

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Oct 7, 2024
…r=workingjubilee

Fix `target_vendor` in non-IDF Xtensa ESP32 targets

`rustc`'s Xtensa ESP32 targets are the following:
- `xtensa-esp32-none-elf`
- `xtensa-esp32-espidf`
- `xtensa-esp32s2-none-elf`
- `xtensa-esp32s2-espidf`
- `xtensa-esp32s3-none-elf`
- `xtensa-esp32s3-espidf`

The ESP-IDF targets already set `target_vendor="espressif"`, however, the ESP32 is, from my understanding, produced by Espressif regardless of whether using the IDF or not, so we should set the target vendor there as well?
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 7, 2024
…llaumeGomez

Rollup of 4 pull requests

Successful merges:

 - rust-lang#130824 (Add missing module flags for `-Zfunction-return=thunk-extern`)
 - rust-lang#131170 (Fix `target_vendor` in non-IDF Xtensa ESP32 targets)
 - rust-lang#131369 (Update books)
 - rust-lang#131370 (rustdoc: improve `<wbr>`-insertion for SCREAMING_CAMEL_CASE)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 8, 2024
Rollup of 7 pull requests

Successful merges:

 - rust-lang#130824 (Add missing module flags for `-Zfunction-return=thunk-extern`)
 - rust-lang#131170 (Fix `target_vendor` in non-IDF Xtensa ESP32 targets)
 - rust-lang#131355 (Add tests for some old fixed issues)
 - rust-lang#131369 (Update books)
 - rust-lang#131370 (rustdoc: improve `<wbr>`-insertion for SCREAMING_CAMEL_CASE)
 - rust-lang#131379 (Fix utf8-bom test)
 - rust-lang#131385 (Un-vacation myself)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit e416a9c into rust-lang:master Oct 8, 2024
6 checks passed
@rustbot rustbot added this to the 1.83.0 milestone Oct 8, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 8, 2024
Rollup merge of rust-lang#131170 - madsmtm:target-info-esp32-vendor, r=workingjubilee

Fix `target_vendor` in non-IDF Xtensa ESP32 targets

`rustc`'s Xtensa ESP32 targets are the following:
- `xtensa-esp32-none-elf`
- `xtensa-esp32-espidf`
- `xtensa-esp32s2-none-elf`
- `xtensa-esp32s2-espidf`
- `xtensa-esp32s3-none-elf`
- `xtensa-esp32s3-espidf`

The ESP-IDF targets already set `target_vendor="espressif"`, however, the ESP32 is, from my understanding, produced by Espressif regardless of whether using the IDF or not, so we should set the target vendor there as well?
@madsmtm madsmtm deleted the target-info-esp32-vendor branch October 8, 2024 14:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler 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