draft

[Youssef1313]

GitHub Issue (If applicable): closes #

PR Type

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior?

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] Docs have been added/updated which fit documentation template (for bug fixes / features)
• [ ] Unit Tests and/or UI Tests for the changes have been added (for bug fixes / features) (if applicable)
• [ ] Validated PR Screenshots Compare Test Run results.
• [ ] Contains NO breaking changes
• [ ] Associated with an issue (GitHub or internal) and uses the automatic close keywords.
• [ ] Commits must be following the Conventional Commits specification.

Other information

Internal Issue (If applicable):

[gitpod-io[bot]]

[jeromelaban]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[Youssef1313]

@jeromelaban Is it safe to remove the hash part if things paas?

[Youssef1313]

@jeromelaban Can you restart the CI here please?

[jeromelaban]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[jeromelaban]

The problem here is that if there are two types with the same name in different assemblies, there may be a clash. It's not something we validate inside uno.

[Youssef1313]

@jeromelaban If they are in different assemblies, that should be different compilations too? What's the problem if the same name is used across different compilations?

[jeromelaban]

The problem here is disambiguation of the same FullName in different assemblies, but in the same compilation.

[Youssef1313]

@jeromelaban I'm not following with that. We generate code for symbols that are declared in source, shouldn't they all have the same assembly, specifically, it's compilation.Assembly. If a symbol doesn't belong to compilation.Assembly, I think we will never generate code for it.

[jeromelaban]

@jeromelaban I'm not following with that. We generate code for symbols that are declared in source, shouldn't they all have the same assembly, specifically, it's compilation.Assembly. If a symbol doesn't belong to compilation.Assembly, I think we will never generate code for it.

That's fair, I had in mind that the original use was for symbols coming from other assemblies, but this is not the case anymore. Maybe it should be renamed to GetGeneratedFileNameHint() or something to make it clear, or removed altogether and used inline.

[jeromelaban]

@Youssef1313 still needed?