In D117332#3252167, @Quuxplusone wrote:

Everything here makes sense except the decision to make s.reserve() nonequivalent to s.shrink_to_fit(). I don't see any ABI issue with that, so that part of the patch is orthogonal to the rest — and it seems to be altering behavior that is both useful and cppreference-documented. I suggest doing everything else you're doing, but not that specific one-line diff, because I don't see its upside.

Well done Bixia!

Your example is different from mine as it nests the constexpr variable inside the function rather than having it at translation-unit scope.

Trigger rebuild.

It's great that we have now the bufferization dialect to host these, right? :)

Hi, I suspect that this patch (or D117815) led to the build failure we're seeing on our builders (https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8824480583333895809):

Makes sense, thanks!

If I'm understanding correctly, moving const to the left of "MCSymbol *"' declares the object as const instead of the pointer. In this case, we get a compilation error on the following line:

enable_view<void> test

Remove const and const ref tests for enable_view. The standard expects cv-unqual types.

LGTM.

In D117569#3259255, @majnemer wrote:

In D117569#3258307, @zahiraam wrote:

In D117569#3257121, @majnemer wrote:

I have a question regarding how this work with respect to the dllimport semantics known by the linker.
IIUC, we will now allow a program like:

extern int __declspec(dllimport) dll_import_int;
constexpr int& dll_import_constexpr_ref = dll_import_int;
int& get() {
    return dll_import_constexpr_ref;
}

Here, get will load dll_import_constexpr_ref. However, what will dll_import_constexpr_ref hold? It ought to hold the contents of __imp_?dll_import_int@@3HA. However, we can't dereference __imp_?dll_import_int@@3HA to get to its contents.

@majnemer Thanks for the review.

This test case doesn't link with MSVC. It will generate this error:
Microsoft (R) Incremental Linker Version 14.29.30133.0
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test1.exe
test1.obj
test1.obj : error LNK2001: unresolved external symbol "int dll_import_int" (?dll_import_int@@3HA)
test1.exe : fatal error LNK1120: 1 unresolved externals

The symbols generated with MSVC are:
07 00000000 UNDEF notype External | ?dll_import_int@@3HA (int dll_import_int)
015 00000000 SECT6 notype Static | ?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)

Without this patch this test case errors. With this patch clang will generate these symbols:

010 00000000 UNDEF notype External | imp_?dll_import_int@@3HA (declspec(dllimport) int dll_import_int)
012 00000000 SECT5 notype External | ?dll_import_constexpr_ref@@3AEAHEA (int & dll_import_constexpr_ref)
013 00000000 UNDEF notype External | ?dll_import_int@@3HA (int dll_import_int)

and will error at link time with this error:
test1-f1f63b.o : error LNK2019: unresolved external symbol "declspec(dllimport) int dll_import_int" (imp_?dll_import_int@@3HA) referenced in function "int & __cdecl get(void)" (?get@@YAAEAHXZ)
test1-f1f63b.o : error LNK2001: unresolved external symbol "int dll_import_int" (?dll_import_int@@3HA)
a.exe : fatal error LNK1120: 2 unresolved externals

I think that's the behavior expected, right?

My interpretation is that MSVC has a bug: it is forming a reference to ?dll_import_int@@3HA and not __imp_?dll_import_int@@3HA. Could you run a more complete experiment where you have a dll which exports the symbol and you try to import it?

Also have bug up at https://github.com/llvm/llvm-project/issues/53306.

@keith This patch causes some issues when nesting/chaining RedirectingFileSystems. I have a few tests in https://reviews.llvm.org/D117730 for more details.